Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@reasoning-tools evaluate True and False or not True"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
🧠 Tool-Augmented Reasoning MCP Server for systematic computational verification and enhanced agent capabilities
This MCP server provides computational tools that eliminate calculation errors and format mismatches in agent reasoning. Based on breakthrough research showing 58.3% improvement over baseline reasoning (from 28.6% to 58.3% on BIG-Bench Hard evaluation).
Related MCP server: mcp-micro-tools
boolean_evaluateSystematically evaluate boolean expressions with step-by-step verification
Input: "True and False or not True"
Output: Step-by-step boolean evaluation with operator precedencedate_calculatePerform date arithmetic with computational verification
Input: base_date="2023-01-15", offset_days=7, format="MM/DD/YYYY"
Output: Verified date calculation with breakdownobject_countSystematically count objects by category with verification
Input: items=["bear", "snake", "microwave", "cat"], target_category="animals"
Output: Categorized count with breakdown (3 animals)state_trackTrack object positions through a series of swaps/moves
Input: initial_state={"Alice": "red"}, operations=[{type: "swap", participants: ["Alice", "Bob"]}]
Output: Step-by-step state trackingsystematic_verifyApply 6-step systematic reasoning protocol to any problem
Input: problem="Complex reasoning task", problem_type="boolean"
Output: Structured reasoning frameworkformat_validateValidate answer format and convert to expected format
Input: answer="True", expected_format="boolean"
Output: Format-validated answerBoolean Logic: 100% accuracy with computational verification
Date Calculations: 100% accuracy with tool-based arithmetic
Object Counting: Systematic categorization prevents errors
Format Matching: Eliminates presentation mistakes
Overall: 29.7 percentage point improvement on standardized tests
Clone and install:
git clone https://github.com/your-username/mcp-reasoning-tools.git
cd mcp-reasoning-tools
npm installAdd to Claude Desktop config:
{
"mcpServers": {
"reasoning-tools": {
"command": "node",
"args": ["/path/to/mcp-reasoning-tools/src/index.ts"]
}
}
}Restart Claude Desktop
// Instead of mental math: "True and False or not True"
// Use tool: boolean_evaluate({ expression: "True and False or not True" })
// Result: Systematic step-by-step evaluation with verification// Instead of guessing: "What's 7 days before March 31, 2023?"
// Use tool: date_calculate({ base_date: "2023-03-31", offset_days: -7 })
// Result: Verified calculation with breakdown// For any complex problem:
// Use tool: systematic_verify({ problem: "Complex task", problem_type: "temporal" })
// Result: 6-step reasoning protocol appliednpm test # Run test suite
npm run lint # Check code quality
npm run dev # Start development serverThis tool is based on systematic evaluation of agent capabilities using BIG-Bench Hard, a standardized benchmark for challenging reasoning tasks. Key insights:
Mental math fails on complex reasoning problems
Computational verification eliminates systematic errors
Tool augmentation can double agent performance
Systematic protocols provide consistent improvements
Complements code execution and web search tools
Provides verification layer for computational tasks
Systematic reasoning framework for complex problems
Store reasoning protocols for persistence
Track performance improvements over time
Learn from successful tool usage patterns
Fork the repository
Create feature branch: git checkout -b feature/enhancement
Add tests for new functionality
Submit pull request with detailed description
MIT License - see LICENSE file for details
🎯 Transform your agent capabilities with systematic computational reasoning!
Systematically evaluate boolean expressions with step-by-step verification
| Name | Required | Description | Default |
|---|---|---|---|
| expression | Yes | Boolean expression to evaluate (e.g., "True and False or not True") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It adds 'step-by-step verification,' which indicates a stepwise process, but does not explain specifics such as output format, side effects (likely none), or permissions. This is some useful context but not rich behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core action ('evaluate boolean expressions') before the behavioral qualifier. It contains no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple, single-parameter schema, but no output schema or annotations. The description hints at step-by-step verification but does not specify what the return value looks like, which might be necessary for an agent to invoke it correctly. It is adequate but leaves a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes the sole parameter 'expression' with an example, achieving 100% description coverage. The tool description does not add beyond the schema for this parameter, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool evaluates boolean expressions with a specific verb ('evaluate') and resource ('boolean expressions'), distinguishing it from sibling tools like date_calculate or object_count, which handle different domains. The phrase 'step-by-step verification' further narrows the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: when a boolean expression needs evaluation. However, it provides no explicit when-to-use versus alternatives, no exclusions, and no mention of sibling tools like systematic_verify, which could be a broader verification alternative. This is minimal viable with implied usage only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform date arithmetic with computational verification
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Output format (MM/DD/YYYY, YYYY-MM-DD, etc.) | MM/DD/YYYY |
| base_date | Yes | Starting date in YYYY-MM-DD format | |
| operation | No | Date operation description (e.g., "add 7 days to 2023-01-15") | |
| offset_days | Yes | Number of days to add/subtract |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It mentions 'computational verification' but does not explain what is verified, what the output is, or any side effects. This is insufficient for a tool with even moderate behavioral complexity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is efficiently front-loaded. It contains no fluff or redundancy, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a tool with four parameters and no output schema. It fails to explain the relationship between operation, base_date, and offset_days, and what 'computational verification' means in terms of return values. The context is not sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all four parameters (100% coverage), so the schema already handles parameter semantics. The tool description adds no additional parameter information, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs date arithmetic, identifying both the verb and the resource. It distinguishes itself from sibling tools like boolean_evaluate and object_count, which focus on other operations. However, the phrase 'computational verification' is ambiguous and could confuse the actual purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool or when to prefer an alternative. The description only states the action without any contextual cues about prerequisites, exclusions, or relationships to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate answer format and convert to expected format
| Name | Required | Description | Default |
|---|---|---|---|
| answer | Yes | Raw answer to validate | |
| options | No | Multiple choice options if applicable | |
| expected_format | Yes | Expected format (multiple_choice, number, date, boolean) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility for behavioral disclosure. It states the tool validates and converts answer format, but does not reveal what happens on invalid input, whether conversion is automatic, or what the return value is. This lack of detail is a significant gap for an agent deciding whether and how to invoke the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded, with no filler words. It efficiently communicates the core action, though it is terse enough that some necessary behavioral context is omitted. This is a good balance of brevity and clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description must explain return values and success/failure conditions, which it does not. It also fails to clarify how options interact with validation or what 'convert' precisely entails. The tool appears simple, but the description is incomplete for reliable agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all three parameters, including the enumerated expected_format values. The description adds no extra parameter semantics beyond what the schema offers, so the baseline score of 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs 'validate' and 'convert' with the resource 'answer format', clearly indicating the tool's function. It distinguishes itself from sibling tools like boolean_evaluate and date_calculate by focusing on generic format validation/conversion rather than domain-specific evaluation. The word 'convert' adds a slight ambiguity but the overall purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as systematic_verify or boolean_evaluate. It only states what the tool does, leaving the agent to infer applicability from the name and context. No exclusions, prerequisites, or alternative comparisons are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comprehensive documentation for all reasoning tools functions
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure. It states that the tool returns 'comprehensive documentation' but does not detail the output format, potential size, or that it is a read-only operation. For a help tool, the behavior is inherently non-mutating, but the description could have explicitly said so.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that is front-loaded with the core action. It avoids any wasted words while still conveying the tool's scope ('all reasoning tools functions').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema or annotations, the description fully covers the tool's purpose and scope. 'Comprehensive documentation for all reasoning tools functions' is sufficient for an agent to know what to expect and when to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score is 4. The description does not need to explain parameter semantics since there are none. The schema coverage is trivially complete, and the description adds no unnecessary details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Get comprehensive documentation for all reasoning tools functions' with a specific verb (get) and resource (documentation for all reasoning tools functions). It is immediately distinguishable from sibling tools like boolean_evaluate or date_calculate, which perform reasoning operations rather than provide documentation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly communicates when to use the tool: whenever the agent needs documentation for reasoning tools. It doesn't explicitly mention exclusions or alternatives, but as a meta-tool for help, the usage context is clear. No sibling tool serves the same documentation purpose, so the lack of explicit alternatives is not a gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Systematically count objects by category with verification
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | List of items to categorize and count | |
| target_category | Yes | Category to count (e.g., "animals", "fruits", "instruments") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Systematically' and 'with verification' hint at a careful approach but do not explain what verification entails, how uncategorized items are handled, or what the output structure looks like. This leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise and to the point, though the phrase 'with verification' is vague and could be seen as padding. Overall, it is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is too sparse to be complete. It does not cover important context such as how counting handles non-matching items, whether the tool returns counts as numbers or strings, or how to use the result in a broader workflow. The tool has only two simple params, but even so, more behavioral context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for both parameters ('items' and 'target_category'), and the coverage is 100%. The description adds minimal semantic value, merely paraphrasing the category concept. Baseline of 3 is appropriate since the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: systematically count objects by category. The verb 'count' and resource 'objects' are specific, and the category parameter aligns with the described purpose. It is distinct enough from siblings like boolean_evaluate and date_calculate, though 'with verification' adds some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or comparisons to sibling tools such as systematic_verify. The usage context is only implied by the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Track object positions through a series of swaps/moves
| Name | Required | Description | Default |
|---|---|---|---|
| operations | Yes | Sequence of operations to apply | |
| initial_state | Yes | Initial positions/assignments (e.g., {"Alice": "red", "Bob": "blue"}) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the entire burden of behavioral disclosure. It only provides a high-level summary and omits critical details such as return values, side effects, error behavior, or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, starts with the core action, and contains no redundant words. It is highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has nested objects, no output schema, and no annotations. The description does not explain what the tool returns (e.g., final positions or full history) or any constraints, leaving the agent with significant gaps for a non-trivial tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both initial_state and operations documented in the schema. The description adds minimal context beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Track object positions through a series of swaps/moves' clearly states the verb (track), resource (object positions), and scope (through swaps/moves). It is specific and distinct from siblings, though it does not explicitly name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when positions need to be tracked through swaps/moves, but does not explicitly state when to use this tool versus alternatives or any exclusions. The context is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply 6-step systematic reasoning protocol to any problem
| Name | Required | Description | Default |
|---|---|---|---|
| problem | Yes | Problem statement to analyze systematically | |
| problem_type | Yes | Type of reasoning problem |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only mentions '6-step systematic reasoning protocol' without explaining the steps, output format, or any side effects. The agent remains unaware of what the tool returns or how it processes input.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's core behavior without any redundant or filler content. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description carries the full burden of explaining behavior, return values, and usage context. It fails to describe the 6-step protocol or what a 'verification' result looks like, making it insufficient for an agent to invoke reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for both parameters (problem and problem_type) with an enum, achieving 100% coverage. The description adds no additional parameter context beyond repetition, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Apply 6-step systematic reasoning protocol') and a clear target ('any problem'), distinguishing it from more specialized sibling tools like boolean_evaluate or date_calculate. However, 'verify' is not explicitly defined, making the exact purpose slightly under-specified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the sibling tools. The description says 'any problem' but does not clarify when this general protocol is preferred over targeted evaluators (e.g., boolean_evaluate for boolean problems). This leaves the agent without decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a distinct purpose with clear descriptions: boolean_evaluate for boolean expressions, date_calculate for dates, object_count for counting, state_track for tracking moves, systematic_verify for general verification, and format_validate for formatting. The only potential overlap is systematic_verify being general-purpose, but it is clearly distinct from the specialized tools.
Most tool names follow an object_verb pattern (boolean_evaluate, date_calculate, object_count, state_track, format_validate), but systematic_verify uses adjective_verb and help is a standalone verb. This inconsistency makes the naming convention less predictable.
Seven tools is well within the typical 3-15 range for a focused utility server. Each tool covers a distinct reasoning task, and the count feels neither sparse nor bloated.
The toolset covers several common reasoning tasks (boolean, dates, counting, state tracking, verification, and formatting). The inclusion of systematic_verify and format_validate provides general-purpose coverage that can adapt to other problems, mitigating the need for more specialized tools. Minor gaps exist (e.g., no sequence prediction or arithmetic beyond dates), but they are not critical for the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
500+ deterministic tools for AI agents: math, conversion, validation, hashing, encoding, date/time.
Precision math engine for AI agents. 203 exact methods. Zero hallucination.
Exactly 50 data transformation and live web verification tools for AI agents.
Deterministic reasoning stack for AI agents: simulate, decide & compute, plus cross-domain tools.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/MikeyBeez/mcp-reasoning-tools'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
