nsforge-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.4
Disambiguation3/5
Most tools have distinct purposes with detailed descriptions, but there are clear overlaps: symbolic_equal and verify_equality both check expression equivalence, and derivation_show/derivation_status both display session state. The large set of algebraic manipulation tools (expand, factor, collect, trigsimp, etc.) is individually distinct but adds cognitive load for selection.
Naming Consistency2/5
Tool names are mostly snake_case but follow inconsistent patterns: noun_verb prefixes (derivation_*, formula_*) are mixed with verb_noun names (calculate_limit, solve_inequality, verify_equality). Outliers like symbolic_equal and nsforge_health break the convention, making the naming predictable only within subfamilies.
Tool Count1/5
With 82 tools, this server is far beyond the typical 3-15 tool scope and falls in the extreme category for tool count. The sheer number overwhelms an agent's ability to understand and coordinate the full surface, even though the domain is broad.
Completeness4/5
The tool set covers the symbolic mathematics and derivation domain very thoroughly: session management, formula lookup, algebraic manipulation, calculus, transforms, verification, report/code generation, and task planning. Minor gaps exist (no direct ODE solver or matrix operations), but handoff tools to SymPy-MCP fill those niches, so the surface is largely complete.
Average 4.1/5 across 82 of 82 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 53 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It states that it returns the current session status but does not disclose whether the tool is read-only, requires an active session, has side effects, or how it behaves when no session exists. This leaves important behavioral traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, but the brevity is under-specification rather than conciseness. It repeats the same idea in the Returns section without adding value, and every sentence is merely a restatement of the tool's name, not informative content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description is still incomplete. It does not explain what 'current session' means, whether session_id is required to select a non-current session, or how this status differs from derivation_handoff_status. The tool lacks the contextual information needed to use it correctly in a multi-tool session management workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (session_id) with a default and 0% description coverage. The description does not mention this parameter at all, nor does it explain how it relates to the 'current session' concept. The agent is left without any semantic understanding of the parameter beyond its name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('取得' = get) and resource ('當前會話狀態' = current session status), clearly distinguishing it from session listing tools like derivation_list_sessions. However, it does not differentiate from the similar-sounding derivation_handoff_status, so it's not fully clear what makes this status distinct from that one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description does not mention context, prerequisites, or exclusions, leaving the agent to guess when this status tool is appropriate compared to other session-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It indicates the tool returns a step list with specified fields, but it does not mention whether it is read-only, how it handles non-existent sessions, or any limitations such as pagination. This is a significant gap for a retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear main statement followed by bullet points and a return type. It is slightly redundant in saying 'get all derivation steps' and 'return complete step history', but overall it is well-structured and not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool has an output schema that may document return values, the description omits any explanation of the `session_id` parameter and does not provide usage context. For a simple tool this might be acceptable, but the missing parameter semantics makes it incomplete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter `session_id` with 0% description coverage, and the description never mentions it. The description does not explain that `session_id` identifies the derivation session to retrieve steps from, so the parameter is left entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves all derivation steps and lists the details included (operation type, expressions, SymPy commands, timestamps). However, it does not explicitly differentiate from the sibling tool `derivation_get_step`, which presumably retrieves a single step, though the plural name implies it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like `derivation_get_step` or `derivation_status`. It only states what it does, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for disclosing side effects. It mentions '帶人類知識記錄' (with human knowledge records), indicating it captures notes/assumptions/limitations, but it does not disclose whether this mutates session state, replaces the current expression, or has side effects. No error behavior, prerequisites, or output format details are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose, followed by a compact parameter list. It avoids unnecessary fluff, but the parameter explanations are terse and the return section is just '微分結果' (differentiation result). Overall, it is well-structured for its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool operates on a 'current expression' and interacts with many derivation session tools, the description lacks essential context: how the current expression is set, whether this updates the session, prerequisites (e.g., session started), and the detailed return structure. The output schema is not shown, so the description alone is insufficient for safe standalone use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It lists variable, order, description, notes, assumptions, and limitations with brief explanations (e.g., '微分變數' for variable, '階數（預設 1）' for order). However, it omits session_id entirely, and the explanations are minimal, lacking format or usage details for assumptions/limitations arrays.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '對當前表達式微分' (differentiate the current expression). It also mentions the human knowledge recording aspect, which distinguishes it from pure computation tools. However, it does not explicitly contrast with sibling tools like derivation_integrate, though the verb 'differentiate' is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It mentions 'current expression' implying a session context, but does not state prerequisites (e.g., needing an active derivation session) or when to prefer differentiation over other operations. No exclusion or alternative tools are referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'by computing and comparing' and 'Returns: Verification result', without explaining whether the tool is read-only, how the comparison works, potential failure modes, or the exact return structure. This is insufficient for a verification tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-organized with Args, Returns, and Examples. It avoids redundancy and the example clarifies usage, but the parameter descriptions are minimal and repeat names without much elaboration, which is acceptable but not exceptional.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large sibling toolset and the absence of an output schema, the description is incomplete. It lacks details about the verification result format, error handling, and how this tool compares to verify_equality, verify_integral, and reverse_verify. More context is needed for an agent to select and invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, so the description is the only source of parameter meaning. It identifies 'function' as the original function, 'claimed_derivative' as the derivative to verify, and notes the default for 'variable'. This adds basic semantics, but does not specify input format (e.g., symbolic strings) beyond the example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Verify') and resource ('a derivative'), and the example illustrates the function. However, it does not explicitly distinguish from sibling verification tools like verify_integral or verify_equality, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for checking derivative claims but provides no explicit guidance on when to use it versus alternatives. There is no mention of typical scenarios, prerequisites, or exclusions, making it a purely implied usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description includes a Returns section and an example showing the output structure (success, results, count), which helps set expectations. However, with no annotations provided, it omits any statement about side effects, permissions, or rate limits, which is a gap for a tool that reads saved data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Description, Args, Returns, and Example sections, keeping each part brief. The example is informative without being verbose, earning a high score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers the basic return format and optional parameter. Still, it lacks guidance on sibling tool distinctions and category value semantics, so it is minimally adequate rather than fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds that 'category' is an optional filter, which the schema does not explain. However, it does not provide valid category values or examples, leaving the agent to guess the expected format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all saved derivation results, using a verb+resource structure. It distinguishes from search_saved by the 'list all' scope, but doesn't explicitly name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs derivation_search_saved or derivation_get_saved. The example implies it can be called with no arguments, but no exclusions or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It explicitly says 'Returns: Handoff status and suggestions', indicating a read-only informational nature. It adds context about tool capabilities and handoff advice, but does not specify session handling or edge cases; for a status tool, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a clear title line, a numbered list of three purposes, and a Returns line. It is front-loaded with the main purpose and contains no redundant or extraneous information. The formatting enhances readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status tool with an output schema, the description covers the core purpose and the three key areas it addresses. However, it omits session_id semantics and lacks explicit usage context relative to the many sibling derivation tools. The completeness is moderate, sufficient for basic understanding but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional parameter (session_id) with 0% description coverage, and the description does not mention it at all. Since the parameter is optional with a default, the omission is less critical, but the description adds no meaning beyond the schema, failing to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it shows Handoff status and available options, with a specific verb ('顯示') and resource. It further enumerates three distinct purposes: NSForge capabilities, what to hand off to SymPy-MCP, and current derivation status, which helps distinguish it from sibling status tools like derivation_status. However, '可用選項' (available options) is somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for understanding handoff between NSForge and SymPy-MCP, but it does not explicitly contrast with alternative tools or provide when-not-to-use guidance. The mention of 'what needs to be handed off' suggests a decision-support role, but exclusions or alternatives are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 lists inputs and output. It does not state whether the tool modifies any state, requires a session, or how it handles invalid inputs or optional verification. This leaves the agent without important context about side effects or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured as a docstring with a clear one-sentence purpose, a concise Args list, and a Returns line. It front-loads the primary action and contains no unnecessary words, making it appropriately sized and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers basic inputs and output format, but given the nested object parameters and numerous sibling tools, it lacks important context: no usage guidance, no detail on the report's structure, and no mention of whether verification appears in the output. It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal meaning beyond the schema's bare types: it names each parameter and gives brief hints, such as given and results being dictionaries mapping symbols to values. However, 'steps' is only vaguely described as 'Derivation steps' without specifying the expected structure of each step object. Since schema coverage is 0%, the description partially compensates but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a complete derivation report in Markdown. It uses a specific verb ('generate') and resource ('derivation report'), and the format is defined, which distinguishes it from sibling tools like generate_latex_derivation and generate_sympy_script.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 prerequisites, such as needing an active derivation session, or when not to use it. The word 'complete' hints at final reporting, but no direct comparison to siblings is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It mentions that the tool is not a calculation step and returns a 'record result', but it does not explain side effects, session requirements, persistence, or how the note integrates with the derivation. This is insufficient for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for Args, Returns, and Examples, but it includes lengthy motivational prose that is not strictly necessary. It is front-loaded with a clear purpose, yet the extra explanation makes it longer than needed for a simple note-adding tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately simple, and the description covers purpose, parameters, and examples. However, it does not explain the return value in any detail, omits session_id, and does not clarify how notes are stored or displayed. Given the absence of annotations, the description could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It provides detailed meanings for note, note_type (including all enum values and their significance), related_variables, and related_step. However, it omits session_id, which is in the schema, so it is not fully comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a note (not a calculation step) to a derivation, with a specific verb and resource. It distinguishes itself from calculation tools like derivation_record_step, but does not explicitly differentiate from the similarly-named sibling derivation_insert_note, which reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the tool is for recording human knowledge (insights, assumptions, warnings, corrections) and includes a list of use cases. It implies it should not be used for calculation steps, but does not name alternatives or provide a when-not-to-use section, so it is just shy of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It only states the return value, which is already covered by the output schema. It does not explicitly mention that the operation is read-only, nor does it discuss ordering, pagination, or potential side effects, so transparency is limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, containing only a purpose statement and a Returns note. No redundant words or unnecessary details. The structure is acceptable for such a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for a basic list operation, but it lacks context about what constitutes a 'derivation session' and whether pagination or ordering applies. The output schema likely covers the return structure, so the lack is more about usage and behavioral completeness, making it minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema has 100% coverage by definition. The description adds no parameter-specific details, but the baseline for zero-parameter tools is 4 since there is nothing to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all derivation sessions' using a specific verb and resource, and the 'all' clarifies scope. This distinguishes it from siblings like derivation_list_saved or derivation_search_saved, which focus on saved or filtered sessions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like derivation_list_saved or derivation_search_saved. The description does not mention any exclusions or conditions, leaving the agent to infer usage merely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. It explains the conversion and return format but does not disclose whether the operation has side effects, requires an active session, or has any prerequisites or error conditions. This lack of behavioral caveats is a significant gap for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose, a numbered workflow, a Returns line, and a detailed example. It is front-loaded and efficient, though the example is somewhat elaborate. Overall, it is concise and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description offers a detailed example of the return object and situates the tool in a workflow, which is helpful. However, it lacks an explanation of session_id, does not specify how the derivation result is obtained (e.g., from the session or current state), and omits edge cases. For a tool with one optional parameter and an output schema present, it is moderately complete but not fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines only session_id, and the description never mentions this parameter or explains its purpose. Since schema description coverage is 0%, the description should compensate but does not, leaving the agent to infer from the default value or context. The example arbitrarily omits arguments, adding ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: preparing derivation results for optimization solvers by converting NSForge symbolic formulas into optimizer input. It uses specific verbs ('prepare', 'convert') and a resource (optimization solver format), and distinguishes itself from sibling derivation tools through its optimization-specific purpose and concrete example.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear three-step workflow indicating when to use the tool: after NSForge derivation and before sending to an optimizer. This gives explicit context but does not mention when not to use it or name alternative tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description offers minimal behavioral disclosure. It gives examples showing it can handle polynomial and trigonometric identities, but it does not specify return format details, error handling, or limitations. The Returns section only states 'Verification result,' which is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and well-structured with sections for Args, Returns, and Examples. The purpose statement is front-loaded, and the examples are concise and informative. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two string parameters, the description covers the core purpose and provides illustrative examples. However, it lacks explicit usage guidance, behavioral details, and does not reference the output schema (whose content is unknown). It is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are empty (0% coverage), but the description's Args section defines each parameter as an expression and provides examples that clarify their string format. This partially compensates for the lack of schema detail, though it does not add extensive parameter-specific semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool verifies symbolic equality of two expressions. It uses a specific verb and resource, and it distinguishes itself from other verification tools (e.g., verify_derivative, verify_integral) by focusing on equality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides examples of when to use the tool but does not explicitly mention when not to use it or compare it to alternatives like symbolic_equal. Usage context is implied through the examples and purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states that the tool resumes a session and returns session status, but does not disclose whether this is a state-changing operation, what happens if the session does not exist or is already active, or any side effects. This lack of detail is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise, consisting of a brief purpose statement, a usage condition, and an Args/Returns list. Every sentence serves a purpose, and the key information is front-loaded. It is well-structured for an AI agent to quickly parse and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with only one parameter and an output schema, the description covers the basics: purpose, when to use, parameter, and return value. However, it lacks important context such as prerequisites (e.g., the session must exist and be paused), error conditions, and what 'resume' actually entails. This makes it minimally viable but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only says 'session_id: 會話 ID' (session ID), which adds almost no meaning beyond the parameter name and title 'Session Id'. It does not explain where to obtain the session ID, its format, or any constraints. This fails to compensate for the complete absence of schema-level parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Resume paused derivation session' (恢復暫停的推導會話). This is a specific verb+resource construction that distinguishes it from sibling tools like derivation_start (start new) and derivation_status (check status). The wording is unambiguous and directly tied to the tool's name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'If the derivation process is interrupted, you can use this tool to resume' (如果推導過程中斷，可以用這個工具恢復). This tells the agent exactly when to use the tool, which is a clear context. It does not explicitly mention alternatives, but the condition is specific enough to differentiate from starting a new session.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It adds some context, such as the 'NOT AVAILABLE IN SYMPY-MCP!' warning and the default behavior of stats_to_compute, but it does not disclose side effects, supported distribution types, or error behavior. This is a moderate disclosure level.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description starts with a clear one-sentence purpose, followed by sections for Args, Returns, and Examples. The 'NOT AVAILABLE' banner is prominent but adds valuable environment-specific context. Overall, it is well-structured and front-loaded, with only minor redundancy from repeating parameter names already in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, a nested object, no annotations, and an output schema not shown, the description provides essential usage details via the example and stats list. However, it omits supported distribution_type values and the exact structure of the parameters object, leaving room for misinterpretation. The output schema exists but is not elaborated, so completeness is moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. The Args section names all three parameters, with stats_to_compute listing specific options and default, but distribution_type ('Type of distribution') and parameters ('Distribution parameters') are vague, leaving format and allowed values unclear. The example partially clarifies the parameter format (e.g., {"mean": "mu"}) but not exhaustively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific verb-resource statement: 'Compute statistics of a distribution.' It lists the available statistics (mean, variance, std, skewness, kurtosis, entropy) and gives a concrete example, distinguishing it from sibling tools like distribution_probability (probabilities) and define_distribution (definition).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool via its purpose and example, but it does not explicitly mention when not to use it or name alternatives. The sibling list includes related tools, but no direct guidance is provided, so the usage context is clear but not strongly differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It describes inputs and output but does not explicitly state whether the operation is side-effect-free, whether it validates inputs, or how it handles edge cases. While it implies a pure generation function, this is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a well-structured docstring with Args and Returns sections, containing no unnecessary words. It is succinct and clearly organized, making it easy for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple generation tool, the description covers the essential inputs and return value. It does not include examples or edge-case behavior, but the tool's purpose is straightforward and the output schema likely provides additional structure. The description is adequate given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining each parameter: title is the derivation title, steps is a list of {description, latex} objects, and final_result is the final result in LaTeX. This adds meaningful semantic context beyond the raw schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: generating LaTeX documentation for a derivation. It uses a specific verb (Generate) and resource (LaTeX documentation for a derivation), and distinguishes itself from related generation tools by specifying the output format (LaTeX). The Args and Returns sections further clarify the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 generate_derivation_report or generate_sympy_script. It only states what it does, without any contextual or exclusionary information to help an agent choose it over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does meaningful work: it discloses deterministic execution of earlier rungs, the reification into Python code, and detailed timeout behavior including process isolation and kill semantics. However, it does not mention potential side effects or persistence, which remains ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a concise overview, Args, and Returns sections. It front-loads the core purpose and uses efficient language. The jargon-heavy opening paragraph is a minor readability cost, but every sentence contributes to understanding the tool's behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main workflow, timeout behavior, and key outputs, but leaves gaps: the structure of the DTS spec is delegated to task_plan, the 'phases' return field is unexplained, and error handling for non-timeout failures is not addressed. An output schema exists, which may cover return details, but the core spec ambiguity remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It thoroughly explains timeout_s, including its behavior and return value on timeout. However, spec is only described as 'A DTS dict (see task_plan)' with no structural detail, leaving the main parameter under-specified without cross-referencing another tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool runs the DTS through the reification ladder, explaining the concept, symbol, derivation, and algorithm rungs. This distinguishes it from sibling derivation_* tools which handle individual steps, though the jargon 'DTS' and 'reification ladder' may be somewhat opaque without prior context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the full-pipeline runner and references task_plan for creating the spec, but it does not explicitly state when to use this tool versus alternatives, nor does it mention when not to use it. The guidance is primarily contextual rather than directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full burden. It describes the return structure in detail (formula expression, derivation steps, etc.) and provides an example of a success response. However, it does not mention error handling or behavior when the result_id does not exist, which is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with Args, Returns, and Example sections. It is front-loaded with the main purpose and uses bullet points for return fields. The example is helpful, but the description is slightly longer than necessary, with some repetition of fields already implied by the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple get-by-ID tool with an output schema. The description explains the return fields and provides an example, which covers most of the needed context. It lacks guidance on usage context and edge cases, but for a retrieval tool, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It provides a one-line explanation of result_id as '推導結果 ID' (derivation result ID) and the example shows a string. This adds minimal meaning beyond the parameter name itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with the verb '取得' (retrieve) and the resource '已存檔的推導結果詳情' (saved derivation result details). It explicitly lists the contents of the result, distinguishing it from sibling tools like derivation_list_saved or derivation_search_saved that list or search saved derivations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives. The example and parameter imply usage when you have a specific result_id and need full details. Sibling tools like derivation_list_saved and derivation_search_saved serve alternative purposes, but the description doesn't mention them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the only source of behavioral info. It explains the output contents (LaTeX, step count, session name/status) and includes an example return object. However, it does not disclose preconditions (e.g., active session) or error behavior, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with an introductory sentence, an important warning, a bulleted list of features, an Args section, Returns, and an Example. It is slightly verbose but every section adds value, except the session_id omission is not a structure issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers purpose, usage, most parameters, and output format via the example. It falls short on explaining the session_id parameter and does not address error scenarios or prerequisites. Overall, it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description documents the 'format' parameter with its four values and 'show_steps' with its meaning, but completely omits 'session_id'. Since schema description coverage is 0%, this omission means one of three parameters is entirely unexplained, which is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: displaying the current derivation state and formula, with an explicit comparison to SymPy-MCP's print_latex_expression. The warning that agents must call it after every derivation operation further distinguishes it as the primary display tool among many derivation siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states 'Agent must call this tool after every derivation operation to show results to the user', which provides a clear usage context. It does not explicitly mention exclusions or alternative tools, but the guidance is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. It mentions the method (differentiating the result) but the return type is only described as 'Verification result' – vague. It does not state whether it returns a boolean, how symbolic equivalence is checked, or potential failure modes. With no annotations, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a structured docstring with clear sections (Args, Returns, Examples). It front-loads the purpose in the first line and avoids unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only three parameters, and the description covers the purpose, example usage, and parameter semantics. An output schema exists, so return details are not required. However, it could be slightly more explicit about the output type, despite the example implying a boolean.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an Args section that describes each parameter: integrand, claimed_integral, and variable with its default. Since the schema provides only titles and no descriptions, this compensates completely, giving clear semantics for all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Verify an integral by differentiating the result', which is a specific verb+resource. The example ('x**2' -> 'x**3/3' -> True) reinforces this. It also differentiates from related tools like verify_derivative by explicitly mentioning integration and differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like verify_derivative or verify_equality. The description provides an example but no context about typical use cases, exclusions, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses a key behavioral constraint: it cannot change calculation results, and fields like expression/operation type require rollback. However, it does not clarify overwrite vs. merge behavior, validation of step_number, or error handling, leaving some ambiguity for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: it starts with a prominent warning, lists updatable and non-updatable fields, provides an Args section with default behavior, a Returns line, and an example. The decorative lines and repetition are somewhat verbose but aid readability and emphasis. Overall, it is clear and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple metadata update tool, the description covers most essential aspects: what can be updated, what cannot, and the meaning of None. However, it misses session_id, which may be required to identify the derivation session in context, and the Returns description is vague ('更新結果'). Since an output schema exists, return values may be documented elsewhere, but the session_id gap remains a completeness issue.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It adequately explains step_number (1-based), and states that None means 'don't update' for description, notes, assumptions, and limitations. However, it omits session_id entirely, which is a parameter in the schema, and does not explain the array types for assumptions/limitations (though these are evident from the schema). This is a notable gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '更新步驟的元資料' (update step metadata). It explicitly lists the updatable fields (description, notes, assumptions, limitations) and specifies what is not updatable (expression, operation type), which distinguishes it from rollback and other derivation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use this tool: only for updating descriptive fields, and that changing expressions or operation types requires 'rollback' instead. This provides an explicit exclusion and names the alternative tool. However, it does not mention other potentially overlapping siblings like derivation_add_note or derivation_insert_note, so it is not fully comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains that refinement depends on variable properties via examples and even discloses non-availability in certain contexts. However, it does not describe failure modes, edge cases, or behavior when assumptions are insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized with a short summary, args, returns, and examples. The large 'NOT AVAILABLE' warning box is prominent but contributes little to the operational understanding and adds noise. Otherwise, it is concise and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with an output schema, the description offers examples and return expectations. It lacks details on handling empty assumptions or conflicts, but these are minor gaps given the simplicity of the tool. The output schema already covers return structure, so the description needn't elaborate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only types and no descriptions, so the examples are crucial. They clearly illustrate that `expression` is a string and `assumptions` is a dict mapping symbols to lists of properties (e.g., 'positive'). This adds significant meaning beyond the schema, though it doesn't enumerate all possible assumption values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool simplifies expressions using assumptions, with specific examples like sqrt(x**2) → x. It differentiates from generic simplification tools by highlighting the assumptions parameter, but does not explicitly name alternative tools or mention when to prefer this over other simplification functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is implied: apply assumptions to simplify expression. Examples show the input format, but there is no explicit guidance on when to choose this tool over siblings like derivation_simplify, or when assumptions are not needed. The 'NOT AVAILABLE IN SYMPY-MCP' warning is more of a limitation note than a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It explains the return format ('Simplified expression with LaTeX'), method behavior (matching/groebner/combined), and gives examples, but it doesn't mention edge cases, potential failures, or whether the operation is read-only. It is reasonably transparent but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overlong and contains a large 'PHASE 1' banner that is irrelevant to tool usage. The Args section repeats schema structure, and the examples, while useful, take up space. The description is not front-loaded and includes marketing-style noise, so it fails conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the noise, the description is functionally complete: it provides use cases, parameter semantics, return format, and multiple examples. Since an output schema exists, the return values are already structured. The main gap is the lack of error-handling or edge-case notes, but the core information for a simplification tool is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by explaining each parameter: 'expression', 'deep', 'recursive', and especially 'method' with its three enum-like options. It also clarifies defaults, which the schema only shows as raw values. This adds substantial meaning beyond the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it simplifies trigonometric expressions using identities, with concrete use cases and examples. It distinguishes itself from sibling simplification tools (powsimp, radsimp, combsimp) by focusing specifically on trig identities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear use cases (Pythagorean identity, tan expansion, oscillation analysis) but never explicitly states when not to use this tool or suggests alternatives. It implies usage through examples but lacks exclusion criteria or comparison to other simplification tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the operation and gives examples of expected outputs, but it does not disclose edge cases, behavior for non-rational inputs, or error handling. The odd 'PHASE 1' banner adds confusion without clarifying behavior. Overall, it is minimally adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args/Returns/Examples, but it includes a large decorative banner and redundant phrasing ('Cancel common factors in rational expression' followed by 'Reduces rational functions to lowest terms by canceling common factors'). The banner and repetition add noise without contributing value, making it less concise than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and this is a simple single-parameter tool, the description covers purpose, use cases, parameters, and return format with examples. It is reasonably complete, though the lack of edge-case or error information and the confusing banner prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so effectively with an 'Args' section specifying 'expression: Rational expression to cancel' and multiple examples demonstrating valid expressions and expected results. This fully clarifies the single parameter's meaning and usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Cancel common factors in rational expression' and 'Reduces rational functions to lowest terms by canceling common factors.' This clearly distinguishes it from sibling simplification tools like factor_expression or simplify, and the examples reinforce the specific operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists use cases ('Simplify PK models', 'Remove singularities', etc.) which give context, but it does not explicitly say when to use this tool versus alternatives, nor does it mention when not to use it. No exclusions or alternative tool names are provided, so guidance is only implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the return type (symbolic or numeric) and condition syntax, adding some behavioral context beyond the empty annotations. However, it does not state whether a distribution must be defined first, what happens with invalid conditions, or other side effects/constraints. The 'NOT AVAILABLE' banner is ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with Args/Returns/Examples, but includes a large decorative warning banner that adds no operational value and occupies space. The warning is not front-loaded critical info, making the description less concise than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core behavior: input format, output type, and examples, which is mostly sufficient for a probability calculator. However, with no annotations and an empty schema, edge cases, setup requirements, and error behavior are omitted, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions for any parameter (0% coverage). The description fully compensates by explaining distribution_type, parameters as a dictionary, and condition with explicit string format and multiple examples, adding meaningful semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Calculate probability P(condition)' and provides distribution_types and condition examples. This clearly specifies the verb (calculate) and resource (probability for a distribution), distinguishing it from siblings like distribution_stats or define_distribution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Examples imply usage but no explicit when-to-use guidance or alternatives are given. The warning 'NOT AVAILABLE IN SYMPY-MCP!' is a limitation note but does not clarify when to choose this tool over others. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that no repo access is required and implies a read-only health operation, but it doesn't explicitly state safety guarantees, authentication needs, or behavior on failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the key output ('Liveness + inventory'), and each sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has an output schema, and the description covers purpose, content, and the no-repo-access prerequisite. It doesn't explain return types, but the output schema handles that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema is fully covered. The description doesn't need to explain parameters; the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a liveness check and returns inventory (server name, version, tool count, engine versions). It says an agent calls it first and notes 'no repo access required,' distinguishing it from repo-dependent sibling tools, though it doesn't 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage timing: 'calls this first to confirm the server is up and learn what it is talking to.' It also implies it's a prerequisite for further connection, but it doesn't specify when not to use it or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose a key behavioral trait—that the session is saved and resumable—but lacks detail on side effects like whether the derivation state is cleared or marked as aborted, or any permissions required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences plus a generic returns line. Every sentence serves a purpose: stating the action, the persistence behavior, and a return placeholder. No waste or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with an output schema, the description covers the core purpose and the key persistence fact, but it fails to explain the session_id parameter or its default behavior. This omission means the agent may not know how to correctly invoke the tool, making it incomplete despite the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (session_id) with a default value but no description, and the tool description also omits any explanation of how this parameter is used or what the default represents. With 0% schema coverage, the agent receives no guidance on passing this parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action as '放棄當前推導' (abandon current derivation), with a specific verb and resource. It is distinct from related siblings like 'resume', 'complete', and 'rollback'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes that the session remains on disk and can be resumed later with derivation_resume, giving clear usage context and an explicit alternative tool. This helps the agent decide when to use this tool versus resume.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions '帶人類知識記錄' (with human knowledge recording) and includes notes/assumptions/limitations parameters, hinting at step recording. However, it does not disclose side effects on the current expression, session requirements, or return behavior beyond '積分結果' (integration result).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a structured docstring with a one-line summary and an Args/Returns list. It is succinct and front-loaded, though it contains a minor extra blank line. Every sentence is purposeful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters and an output schema, the description covers most parameters but fails to mention session_id or the requirement for an active derivation session. The return value is summarized, but the output schema likely provides details. The omission of session context is a notable gap for an AI agent navigating the derivation workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description compensates by defining variable as the integration variable, lower/upper as optional bounds for definite integrals, and the human knowledge fields (description, notes, assumptions, limitations). It omits session_id, which appears in the schema but is undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: '對當前表達式積分' (integrate the current expression), which clearly states the tool's function. This also distinguishes it from sibling tools like derivation_differentiate (differentiate) and derivation_simplify (simplify).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful context by noting that lower and upper are optional and needed for definite integrals, implying when to use them. However, it does not explicitly state when to prefer this tool over alternatives such as derivation_differentiate or derivation_simplify, so usage is mostly inferred from the verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the sole source of behavioral info. It discloses that it records human knowledge (notes, assumptions, limitations) and returns a simplification result, but it does not clarify whether this mutates the derivation session or if an active session is required. This is a notable gap for a derivation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with Args and Returns sections, listing parameters and method choices without excessive verbosity. It could be slightly tighter, but it remains acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a moderately complex set of parameters and an output schema. The description covers the main parameters and return value, but lacks information about session_id and whether this operation modifies the derivation state, which is important context given the sibling derivation tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates by explaining the method options in detail and providing Chinese descriptions for notes, assumptions, and limitations. However, it omits any explanation of the session_id parameter, which is left ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool simplifies the current expression and records human knowledge, distinguishing it from derivation_integrate and derivation_differentiate. The list of specific simplification methods makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides method options with 'auto' as default, giving context for when to use each simplification approach. However, it does not explicitly differentiate from sibling derivation tools or expression-level simplification tools, lacking explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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. It does state that the tool operates on the 'current expression' and that the result 'may have multiple solutions', which adds some behavioral context. However, it does not mention side effects such as recording a derivation step, modifying session state, or requiring an active session, leaving important behavioral traits undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, parameter list, returns, and an example. It is slightly longer than necessary but every section contributes useful information, and the example is valuable for understanding the tool. The front-loaded summary clearly states the core action first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, part of a derivation workflow) and the existence of an output schema, the description is reasonably complete. It covers all parameters, the return type (multiple solutions), and provides an illustrative example. However, it omits prerequisites such as requiring an active derivation session or previously loaded formula, which are important contextual details for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no parameter descriptions (0% coverage). The description compensates fully by listing every parameter with a one-line meaning (variable, description, notes, assumptions, limitations) and includes a concrete example showing how to use variable, notes, and assumptions. This gives the agent clear semantic grounding for each argument.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Solve the current expression as a function of the specified variable.' This is a specific verb+resource combination that distinguishes it from sibling operations like integrate, differentiate, or simplify. The explicit mention of recording human knowledge (notes, assumptions) further differentiates it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an example workflow (load formula then solve for a variable) which implies the intended use case, but it does not explicitly state when to use this tool versus alternatives like substitute or simplify. No exclusions or alternative tool names are given, so guidance remains implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses a significant behavioral limitation—cannot modify the expression itself—and lists the updatable metadata fields. However, it does not explain how null values are handled (e.g., whether they leave fields unchanged or clear them), nor whether list fields like tags are replaced or merged. These are important update semantics that remain unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for purpose, args, returns, and example. It is appropriately sized for an 11-parameter tool. The argument list is somewhat duplicative of the schema, but since schema coverage is 0%, it earns its place. The example is valuable and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex with 11 parameters and no annotations, but an output schema exists. The description gives a good overview and example, yet misses critical update semantics: whether passing null means 'no change' and whether list-valued parameters replace or append to existing lists. These gaps could lead to incorrect usage, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 0%, so the description must compensate, and it does. All 11 parameters are listed with Chinese semantic labels (e.g., '新名稱', '新描述', '驗證狀態'), adding meaning beyond bare names and types. The example usage further clarifies how parameters are used together. The labels are terse but sufficient to convey purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates metadata of saved derivations, with a specific verb '更新' and resource '已存檔推導的元資料'. It explicitly distinguishes itself from related tools by noting it cannot modify the derivation expression itself, which differentiates it from derivation_update_step and other derivation manipulation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on what the tool does and explicitly states a key exclusion: '不能修改推導表達式本身' (cannot modify the expression). This tells the agent when not to use this tool, implying re-derivation is needed instead. However, it does not name specific alternative sibling tools, so it falls short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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. It does well by explaining the conversion process, that expressions are 'validated', and by detailing the return structure (sympy_expr, symbols, latex, is_equation) with examples. It does not, however, discuss potential failure modes or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized, with a clear top-line summary followed by Args, Returns, and Examples. Every section earns its place, and the content is front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a moderate complexity with 3 parameters and an output schema, and the description covers the purpose, all parameters, the return format, and provides two concrete examples. This is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions for its properties, so the description must compensate. It does so by explaining each parameter in the Args section, providing examples for expression and symbol_hints, and clarifying that description is optional. This adds significant meaning beyond the raw schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: parsing a mathematical expression into a SymPy-computable form, and it mentions extracting symbols. However, it does not explicitly differentiate itself from sibling tools like validate_expression or extract_symbols, which may perform overlapping functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides examples and parameter details, implying it is used for converting human-readable formulas to SymPy. However, it does not explicitly state when to use this tool instead of alternatives, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden for behavioral disclosure. It clearly specifies the return shape ('success', 'spec', 'total', 'steps') and notes provenance information, but it does not state whether the operation has side effects, requires state, or is purely computational. This is a moderate transparency gap for a planning tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized, with a one-sentence purpose followed by a concise justification of provenance. The Args/Returns structure is clear and front-loaded, and every sentence adds value without repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description adequately covers the input structure and explains the high-level output. It adds context about the 'reification ladder' and provenance, making the tool's role clear. Minor gaps remain in explaining what a 'step' looks like and the exact meaning of 'spec' in the return, but the output schema likely covers some of this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only declares an object with additionalProperties, providing no field-level detail. The description compensates by listing the expected DTS keys ('name, goal, given, unknowns, assumptions, base_formulas, modifications, acceptance, metadata'), which gives meaningful guidance beyond the schema. However, it does not elaborate on each key's meaning or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool's purpose with a specific verb ('Reify') and resource ('Derivation Task Spec (DTS)') transformed into an 'ordered plan of tool calls.' It also distinguishes itself from sibling execution tools by emphasizing 'Each planned step names the tool that would produce it (provenance),' highlighting its unique planning role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is used to convert a DTS into a plan before executing tool calls, but it does not explicitly state when to prefer it over alternatives or provide exclusions. The context signals show sibling tools are mostly derivation/formula execution and planning tools, yet no direct comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the returned content in bullet points and provides a concrete example showing a success response, making the tool's behavior predictable. It does not discuss error cases or side effects, but 'get' implies read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the purpose, and uses clear headings (Args, Returns, Example) along with bullets. Every line adds value with no unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality and includes an example, but it lacks context on session_id and how the step relates to a derivation session. Given no annotations and the existence of many session-related sibling tools, this is a gap that could confuse an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to step_number by specifying it is 1-based, and the example indicates session_id is optional. However, session_id is not explained at all, and with 0% schema coverage, this is a notable gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '取得單一步驟的詳細資訊' (retrieve detailed information for a single step) and enumerates the specific content fields returned (operation type, input/output expressions, SymPy commands, human knowledge). This distinguishes it from sibling tools like derivation_get_steps, which retrieve multiple steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says '用於檢視特定步驟的完整記錄' (used to view the complete record of a specific step), providing explicit context for when the tool is appropriate. It does not mention alternatives or exclusions, but the singular scope is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It discloses that the tool loads into the 'current session' and supports various input formats, which is helpful. However, it does not mention side effects such as whether an active session is required, what happens if the formula_id already exists, or the exact return value beyond 'load result'. This is a moderate gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: it opens with a clear one-line purpose, then lists supported formats, parameters with examples, and returns. Every section adds value, and the three examples are practical and educational. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is rich for input formats and parameter semantics but lacks important context: it does not state that a session must exist or that the session_id parameter can be used to target a specific session. The return value description is also vague ('load result'), though an output schema may cover that. Overall, it is adequate but incomplete for a 7-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. Most parameters (formula, source, source_detail, name, description) are meaningfully explained, with the dict example showing detailed variable structure. However, session_id is entirely omitted from the description, which is a notable gap given it is a schema parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool loads a formula into the current session, with a specific verb ('load') and resource ('formula'). It further distinguishes itself from sibling tools by detailing supported input formats (SymPy, LaTeX, dict) and provides concrete examples, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use this tool (loading formulas into a derivation session) and shows multiple usage scenarios via examples. However, it does not explicitly exclude alternatives or name when to use other tools like formula_search or derivation_get_saved, so it lacks explicit exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses that LaTeX is auto-generated if not provided, that set_as_current controls whether this step becomes the current expression, and that it maintains a complete derivation history. However, it does not explain session handling, error conditions, or what happens if no active session exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, workflow, args, returns, example). The workflow section is somewhat repetitive, but the formatting and section headers make it easy to scan, and each part adds context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides a complete picture: purpose, usage workflow, parameter explanations, and an example. The output schema exists, so return details are not necessary. However, the missing session_id parameter and lack of explicit prerequisites or failure conditions prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the Args section explains 7 of 8 parameters in detail, including defaults and examples. It omits session_id entirely, which is a notable gap since that parameter could be important for multi-session workflows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool records a derivation step, and explicitly frames it as the bridge between SymPy-MCP and NSForge. This distinguishes it from sibling tools like derivation_add_note or derivation_get_steps by emphasizing its role in the derivation workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a concrete 5-step workflow showing exactly when to use this tool after SymPy-MCP calculations, and when to use derivation_complete. The source parameter also clarifies usage contexts (sympy_mcp, manual, literature), but it does not explicitly name alternatives for exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It clearly indicates a read operation ('取得') and shows the return structure, but it does not explicitly state that it is read-only, has no side effects, or requires no special permissions. For a simple stats retrieval, this is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a one-line purpose, a bulleted return summary, and an example. Every element earns its place, and the example illustrates the exact output format without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, clear output schema), the description fully covers what it does and what it returns. The example and return values make it self-contained. No gaps are apparent for the intended use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema coverage is 100% and the baseline for parameter semantics is 4. The description adds value by explaining the output structure, which is more relevant than parameters here. No additional parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '取得推導庫統計資訊' (get derivation repository statistics), a specific verb and resource. It further clarifies what statistics are returned (total, verified, unverified, category stats) and gives an example, distinguishing it from session-level tools like derivation_status or derivation_list_sessions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one needs a repository-level overview, but it does not explicitly state when to use this over alternatives. No exclusions or alternative recommendations are provided, so guidance is merely implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses that sessions are automatically persisted to prevent interruption ('會話會自動持久化，防止中斷') and that the tool returns session information. However, it does not disclose potential side effects, permission requirements, or what happens if the session already exists. The provided behavior is somewhat minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args, Returns, and Example sections, making it easy to scan. It is concise and each section serves a purpose. The bilingual mix (Chinese description, English example) is slightly awkward but does not detract from clarity. It could potentially be shortened, but overall it is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no annotations but an output schema exists, the description sufficiently covers the tool's purpose, parameters, return value (via example), and a key behavioral trait (persistence). It is complete for a simple creation tool, though it lacks explicit error conditions or prerequisites. The example return object partially compensates for the unspecified output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so by explaining each parameter in Chinese: 'name: 推導名稱' (derivation name), 'description: 推導描述' (derivation description), 'author: 作者' (author), and provides a concrete example with expected output. This adds meaningful semantic context beyond the bare schema, though it could be more detailed about data formats or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '開始新的推導會話' (start a new derivation session) and identifies itself as '這是一切推導的起點' (the starting point for all derivations). This specific verb+resource combination, along with the explicit '起點' framing, distinguishes it from sibling tools like derivation_resume or derivation_complete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is the entry point for all derivations ('這是所有推導的起點'), implying it should be used before any other derivation tools. It also notes that sessions auto-persist to prevent interruption, which is a relevant consideration. However, it does not explicitly mention alternatives or when not to use it (e.g., use derivation_resume for existing sessions).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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. It mentions that every step can incorporate human knowledge and that the result includes 'recorded knowledge', implying persistence of a step. However, it does not state whether the operation mutates session state, whether it is reversible, or any side effects beyond the return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for explanation, callout, Args, Returns, and Example. The banner about human knowledge is visually prominent but somewhat gimmicky; otherwise, every sentence earns its place. Not overly long for an 8-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers the operation, parameters, and return value sufficiently, and the example adds practical guidance. It does not explain session prerequisites or the precise return schema details, but an output schema exists and the description gives the essential context for invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero descriptions, so the description's Args section adds substantial meaning to 7 of the 8 parameters (e.g., variable, replacement, in_formula, notes, assumptions, limitations). It omits session_id entirely, which is a minor gap, but the provided example showcases all documented parameters in a realistic use case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool replaces variables in a formula with another expression, which is a specific verb+resource operation. It also mentions 'with human knowledge recording' and 'key operation for combining formulas', which positions it distinctly from sibling operations like simplify or integrate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear context: 'This is the key operation for combining formulas', which tells the user when it is appropriate to use. It does not explicitly mention alternatives or when not to use it, but the context is clear enough for a derivation workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return structure and gives an example, but it does not explicitly state that the tool is read-only, how it handles invalid expressions, or other side effects. It adds some behavioral context but not comprehensive detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args, Returns, and an Example section, and each part contributes value. It is concise with no filler, though there is a minor typo in the example ('ssggested_unit') that could cause minor confusion but does not detract from overall structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 parameters, no annotations), the description is sufficiently complete. It covers the function, inputs, output structure, and includes an illustrative example. This provides an agent enough information to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions for parameters (0% coverage), but the description compensates by explaining 'expression' as a mathematical expression and 'context' with examples like 'mechanics' and 'thermodynamics.' It also shows how context influences suggested units, adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Extract symbols from an expression with inferred metadata.' This is a specific verb+resource that distinguishes it from sibling tools like parse_expression or validate_expression. The example further clarifies the output, showing symbol names, types, units, and descriptions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through its purpose and example, but it does not explicitly state when to use this tool versus alternatives. It gives a context parameter with examples but no exclusions or when-not-to-use guidance. The usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the reverse-operation method and provides examples, but it doesn't disclose the exact return type, potential edge cases (e.g., integration constants affecting verification), or failure behavior. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with a clear initial statement, bulleted mappings, an Args list, a Returns line, and two examples. It is slightly lengthy but every section adds value; the examples are particularly useful for disambiguating the parameter order and semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and the presence of an output schema, the description covers the core purpose, parameters, and usage patterns with examples. It stops short of specifying the exact return format or limitations, but the provided information is sufficient for an agent to understand how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section gives one-line meanings for each parameter, and the examples illustrate how result_expr, original_expr, and operation are used. The description also enumerates valid operation values ('differentiate', 'integrate', 'solve'), which is essential given the schema has no enum. Coverage is 0%, so this compensation is strong, though variable could use more detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Verify a result by applying the reverse operation.' It then clarifies the scope by listing the three reverse mappings (derivative→integrate, integral→differentiate, solve→substitute). This clearly distinguishes it from sibling verification tools like verify_derivative or verify_equality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool through the operation mappings and examples. It implies usage scenarios (verifying a derivative, integral, or solution) but does not explicitly name alternatives or state when not to use it, leaving a small gap in guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries disclosure fully. It adds value by stating the tool returns the intersection of all solutions, provides a caveat about SymPy-MCP availability, and shows example outputs. It does not disclose edge cases like no solution, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (use cases, args, returns, examples). The NOT AVAILABLE banner draws attention appropriately. It is longer than minimal but every section contributes; no fluff beyond the banner, which is functional.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even with an output schema present, the description includes return semantics and complete examples. It covers purpose, usage context, environmental restriction, parameter meaning, and expected results. The only gap is not explicitly connecting to alternative tools, but for a two-parameter solver this is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section provides high-level descriptions ('List of inequalities', 'Variable to solve for') that mostly restate the parameter names and schema types (array/string). The examples add meaningful format hints (e.g., 'x > 0'), but coverage is thin for 0% schema description coverage. It does not explain SymPy syntax details or constraints on variable naming.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Solve a system of inequalities (find the intersection)' which is a specific verb-resource pair and clearly distinguishes from its sibling 'solve_inequality' (which handles single inequalities). The use cases and examples reinforce this purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Use cases' section explicitly lists three scenarios (valid parameter ranges, feasibility regions, stability conditions), giving clear context. The prominent 'NOT AVAILABLE IN SYMPY-MCP!' banner is a strong environmental exclusion. However, it does not explicitly contrast with the single-inequality variant or mention when not to use it beyond the environment limitation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the transparency burden. It discloses that it uses SymPy units and shows concrete return-value examples. Since this is a read-only analysis tool, the lack of side-effect notes is acceptable, though failure modes are not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses a compact docstring structure with Args, Returns, and Examples. Every section adds value, and the examples are directly usable. There is no redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter analysis tool with an output schema available, the description is largely complete. It defines both parameters, gives example inputs/outputs, and notes the underlying library. Minor gaps such as error handling or supported expression grammar are acceptable given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining both parameters. 'units_map' has a clear format with an example, and 'expression' is described as the expression to check. The examples illustrate valid inputs, though expression syntax could be more explicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Check dimensional consistency of an expression') and names the implementation (sympy.physics.units). It is distinct from sibling tools like validate_expression or solve_inequality, and the examples further clarify the expected output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the purpose and examples, but there is no explicit guidance about when to use this tool versus alternatives, and no exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
無 annotations，描述需承擔行為揭露責任。描述詳述回傳結構與範例，但未明確聲明唯讀性質、錯誤處理或 ID 不存在時的行為，遺漏部分安全與失敗語意。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
描述包含多個段落與範例，結構清楚且所有內容皆與使用相關，例如 Args、Returns、Example 分段。但篇幅稍長，部分範例可精簡，整體仍適中。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
整體涵蓋目的、參數、回傳結構與使用範例，對一個查詢工具而言已充分；但缺乏錯誤情境與副作用說明，加上無 annotations，未達非常完整的程度。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
schema 未提供任何描述，而描述中對 formula_id 與 source 的格式、來源選項、預設值均詳細說明，並提供各來源的具體範例，大幅補充參數語意，遠超出 schema 所能表達。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
描述以明確動詞「獲取」指出工具功能為依 ID 取得公式完整資訊，並列出含 LaTeX、SymPy 等內容，與兄弟工具（如 formula_search）形成區別。即使使用中文，仍清楚傳達工具用途與範圍。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
提供明確使用情境：當已有公式 ID 時可呼叫，並說明不同來源的 ID 格式與預設值。雖未直接寫出與替代工具的取捨，但從語境可推斷此工具適用於已知 ID 的查詢，無需額外搜尋。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It clearly states that the tool generates a script (not executes it), and that the script is standalone and runnable, indicating a read-only generation operation. It also lists supported operation types. It doesn't disclose potential failure modes, but for a generation tool, the core behavior is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a one-line summary, detailed parameter breakdown, return description, and a clear example. Every sentence adds value, and the formatting (Args/Returns/Example) makes it easy to scan. The length is appropriate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the vague input schema (only arrays of objects) and no annotations, the description provides the necessary context to invoke the tool correctly, including parameter formats, allowed operations, and the return type. The example reinforces the expected usage. The description is sufficiently complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description completely compensates by defining the structure of the 'expressions' list (name, expr, description) and the 'operations' list with supported op values (simplify, solve, diff, integrate) and 'input' field. The example further clarifies how parameters are used, adding significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates a standalone SymPy script for a computation, with a specific verb and resource. It explains the script is complete and runnable. However, it doesn't explicitly differentiate from sibling tools like derivation_export_for_sympy or generate_python_function, though the 'standalone' phrasing offers some distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by describing the task (generating a script for a computation) and provides a concrete example, but it never explicitly states when to use this tool versus alternatives or any exclusions. No alternative tools are mentioned, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses the return type ('Spatial/time-domain function f(x)') and provides worked examples with expected outputs, but it does not discuss assumptions, convergence conditions, or failure modes when the inverse transform does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized into Use cases, Args, Returns, and Examples sections, with the core definition front-loaded. Some decorative content like the 'PHASE 2' banner and 'PK' note is non-essential, but the structure makes the longer length acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a symbolic transform tool with an output schema, the description covers input semantics, defaults, use cases, return type, and gives concrete expected outputs. It lacks explicit normalization-convention details and limitations, but is sufficiently complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the Args block is essential and fully compensates. It explains that expression is the frequency-domain expression F(k), freq_var is the frequency variable (default 'k'), and space_var is the space/time variable (default 'x'), adding semantic meaning not available in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise mathematical definition: 'Inverse Fourier transform: F(k) → f(x).' and states it 'Transforms frequency domain back to spatial/time domain.' This uses a specific verb and resource, clearly distinguishing it from forward Fourier and Laplace transform siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists four concrete use cases (reconstruct signal from spectrum, inverse filter design, synthesize periodic patterns, diffusion problem solutions) that signal when to use the tool. It does not explicitly name alternatives or exclusions, but the forward/inverse distinction and sibling tool names provide adequate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It adds useful context (runtime mirror of docs/agent/capabilities.json) and implies a read-only retrieval, but never explicitly states it performs no writes or requires no special authorization. For a manifest tool this is adequate but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused sentences, front-loaded with the essential purpose. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the tool's content and its role in discovery and verification, and the output schema covers return details. It is slightly vague about what gates/north star mean, but that's not essential for calling the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description requires no parameter elaboration since there is nothing to configure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Return') and a specific resource ('full capability manifest') with enumerated contents (tools, gates, commands, north star). This clearly distinguishes it from sibling tools focused on derivation, formulas, and health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the tool is 'how an agent discovers every tool and how to verify a change', providing contextual usage guidance. It does not explicitly name alternatives or exclusions, so it earns a 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and provides useful disclosure: it checks syntax and symbol consistency, optionally performs dimensional analysis, and returns a validation result with valid/issues/warnings. Examples illustrate behavior for both valid and invalid expressions. However, it does not clarify how check_dimensions and units_map interact (e.g., whether units_map implicitly triggers dimension checking), leaving a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured with clear sections (Args, Returns, Examples), and every sentence adds value. Two examples illustrate both successful and failing cases without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main use case, parameters, return values, and examples. However, there is an ambiguity: the second example uses units_map without explicitly setting check_dimensions=True, yet reports a dimension mismatch, leaving the user unsure about when dimensional checking actually triggers. Output schema exists but the description still explains returns, so this is only a partial gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds thorough meaning: the Args section documents each parameter with its type and purpose, and examples show expected format (e.g., units_map as a dict mapping symbols to units, expected_symbols as a list). This fully compensates for the schema's lack of descriptive detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates mathematical expressions, specifying it checks syntax, symbol consistency, and optionally dimensional consistency. This distinguishes it from sibling tools like parse_expression or check_dimensions by covering multiple validation aspects in one tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a general validation use case but does not explicitly state when to prefer this tool over alternatives such as parse_expression or check_dimensions. It gives no exclusions or comparisons, so usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explains direction semantics, return format ('Limit result with LaTeX'), and provides examples of one-sided limits. However, it does not explicitly state that this is a read-only operation, that it may fail on unsupported expressions, or any other behavioral caveats beyond the note about SymPy-MCP availability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for use cases, args, returns, and examples, but the large 'NOT AVAILABLE IN SYMPY-MCP!' banner is a distraction and adds noise. The core content is concise and front-loaded, but the banner makes it feel less polished.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a symbolic math tool, the description is complete: it covers purpose, parameters, return format, and provides three concrete examples including one-sided limits. The output schema is already indicated by the examples and 'Returns' line, so no further return-value explanation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so thoroughly with an 'Args:' section that explains each parameter (expression, variable, point, direction) including allowed values for direction and examples. This fully addresses the otherwise bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Calculate the limit of an expression' with specific use cases that distinguish it from sibling tools like calculate_series and calculate_summation. The verb 'calculate' and resource 'limit' are specific, and the examples further clarify the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear use cases (steady-state analysis, boundary behavior, asymptotic behavior, L'Hôpital's rule) which indicate when to use the tool. However, it does not explicitly mention alternatives or list exclusions, so it falls slightly short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return format ('Series expansion with LaTeX') and includes a notable unavailability warning for SymPy-MCP. However, it does not mention whether the operation is read-only, potential limitations, or error behavior, which would be helpful for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Use cases, Args, Returns, Examples) and front-loads the purpose. It is slightly verbose due to decorative separators and the prominent unavailability warning, but every substantive part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity with 5 parameters and an output schema, the description is highly complete. It covers all inputs, provides examples, states the output type, and includes an availability caveat. The output schema covers return structure, so the description does not need to explain it further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by detailing every parameter, including defaults and explanations for series_type values. The Args section adds meaning beyond the raw schema, and examples illustrate usage effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Calculate series expansion of an expression' with a clear verb and resource. It distinguishes from sibling tools like calculate_limit and calculate_summation by focusing specifically on series expansions, and provides concrete examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a 'Use cases' section listing four specific scenarios (e.g., linearization, perturbation methods), giving a clear sense of when to apply the tool. However, it does not explicitly mention alternative tools or exclusions when other calculus operations would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses return format ('Collected expression with LaTeX'), default values for evaluate/exact, and demonstrates handling of single/multiple variables and exponential terms. Lacks explicit error behavior, but adequate for a pure computation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The main purpose is front-loaded, but the description includes decorative box-drawing, emojis, and an irrelevant version note ('PHASE 1 - NOT IN SYMPY-MCP...') that add noise. Examples are useful but the formatting reduces clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers functionality, parameters, return format, and provides multiple examples including edge cases (exp-term collection). Output schema exists but the description still explains the result structure. No error handling mentioned, but sufficient for expected use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has zero descriptions for its 4 parameters. The description's Args section explains each parameter and examples illustrate types (string, list, expression term). This fully compensates for the schema coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool's function ('Collect terms by specified variable(s)') and describes grouping by powers, with use cases and examples. This distinguishes it from sibling tools like expand_expression or factor_expression.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases (polynomial standard form, coefficient extraction, numerical evaluation) and demonstrates usage with multiple variable types. Does not explicitly exclude alternatives, but context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the output structure (variables, current expression, suggested actions) and provides a concrete example of the return value. However, it does not explicitly state whether the tool is read-only or any side effects on the derivation session, though 'export' implies non-mutating.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with headers, a use-case list, and an example, making it scannable. The decorative formatting (═══ lines, emoji) adds visual noise but doesn't detract significantly. It is slightly longer than necessary but each section adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides purpose, usage guidance, output description, and a complete example, which covers the essential context for an agent. It doesn't elaborate on session_id handling or failure modes, but given the tool's simple export responsibility and the presence of an output schema, the description is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains that the tool outputs all defined variables and the current expression, which maps to include_variables and include_current_expression, but it never mentions the session_id parameter or how it affects behavior. The example shows the output format but doesn't clarify the parameters' roles comprehensively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear statement: '導出當前推導狀態給 SymPy-MCP' (Export current derivation state to SymPy-MCP), which specifies the verb and resource. The 'HANDOFF 機制' header further distinguishes this from siblings by positioning it as the bridge to SymPy-MCP when NSForge cannot handle an operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The '使用時機' (usage timing) section explicitly lists four use cases: solving ODE/PDE, matrix operations, complex SymPy operations, and when NSForge tools return errors. This provides clear context and implicitly contrasts with the sibling NSForge tools, giving an agent concrete guidance on when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool records a new step, updates the current expression, and records assumptions/limitations. It also mentions LaTeX is auto-generated if not provided. However, it does not mention session requirements or the precise return/error behavior, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with headings, bullets, an Args list, and an example. It front-loads the purpose and is scannable despite some decorative formatting and a slightly redundant handoff explanation. Efficient for the amount of detail conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters and no annotations, the description covers usage timing, parameter semantics, side effects, and includes an example. It lacks details about session prerequisites and a precise return format, but overall it is largely complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates with an Args section explaining expression, operation_performed, sympy_tool_used, latex (optional, auto-generated), notes, assumptions_used, and limitations. It misses session_id entirely, which is a schema parameter, though the schema's default may reduce the impact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool imports SymPy-MCP results back into NSForge, records them as a new step, updates the current expression, and logs assumptions/limitations. It distinguishes itself from sibling tools like derivation_export_for_sympy by explicitly naming the external source (SymPy-MCP) and the handoff purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit '使用時機' (when to use) section listing three concrete scenarios: after SymPy-MCP completes complex calculations, when wanting to continue with NSForge's step-by-step recording, and when needing to add human knowledge to results. It lacks explicit exclusions or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it does well by disclosing that the operation is non-mutating ('不改變計算流程') and that subsequent steps are automatically renumbered. It also includes a concrete return example, showing the result shape. It does not cover session_id behavior or error edge cases, so transparency is strong but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for purpose, Args, Returns, and Example, and the core purpose appears in the first line. Decorative ASCII lines and emojis add minor visual noise but do not obscure or repeat essential information; the length is justified by the need to explain multiple parameters and provide an example.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is largely complete for a note-insertion tool: it explains the purpose, the non-mutating nature, the renumbering side effect, key parameters (except session_id), and provides an example return value. Since an output schema exists, not detailing return fields is acceptable. The main missing piece is explicit differentiation from similar tools like derivation_add_note, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since the schema has 0% description coverage, the Args section adds essential meaning for most parameters: after_step is explained with the 0-start special case, note content is described, note_type includes all enum values, and related_variables is defined. However, session_id is entirely omitted from the description, which is a notable gap given it is a parameter in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: inserting an explanation at a specified position in a derivation. It further clarifies this is for supplementing notes mid-derivation without changing the calculation flow, which distinguishes it from note-adding or step-modifying siblings like derivation_add_note. The positional and renumbering details make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly frames the tool as being 'used to supplement explanation' and notes it does not alter the calculation process, giving a clear context for when to use it. However, it does not directly refer to alternative tools or state when not to use this tool, so it stops short of providing full exclusion or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It does reveal the return structure (success flag and categories per source), but it does not explicitly state side effects, error handling, or that the operation is read-only. The verb 'list' implies non-mutating behavior, but the description could be more explicit about safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with clear sections for purpose, arguments, and return value. Every sentence contributes value, and the front-loaded purpose statement makes the tool's function immediately clear. No unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with one optional parameter, the description covers the parameter options and the full return structure. It lacks error-case documentation, but the tool's simplicity and the detailed Returns section make it sufficiently complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no description for the 'source' parameter (0% coverage). The description fully compensates by enumerating all valid values ('all', 'wikidata', 'biomodels', 'scipy') and their defaults, which adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists available formula categories (列出可用的公式分類) and retrieves categories supported by each data source for more precise searching. This is a specific verb+resource pairing that distinguishes it from sibling tools like formula_search, which searches formulas rather than listing categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating the purpose is '用於更精確的搜尋' (for more precise searching), implying it should be used to obtain categories before searching. However, it does not explicitly name alternatives or state when not to use it, so it lacks exclusions that would earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden. It discloses the return type ('Returns: 藥動學模型列表') and the external source (BioModels), but it does not mention any potential side effects, error conditions, or network behavior. For a search tool, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear header, Args, Returns, and Example sections. Every line provides useful information without redundancy. It is appropriately sized for a simple search tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, parameters, return type, and examples. Since an output schema exists, it doesn't need to detail return fields. It lacks only explicit guidance on alternatives or potential edge cases, but overall it is complete for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates fully by explaining each parameter: query as search keyword with examples, drug as optional drug name, and limit as maximum returns. The Examples section further illustrates parameter usage, adding clear semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '搜尋藥動學 (PK) 模型' (search pharmacokinetic models) and specifies the source '專門從 BioModels 搜尋藥動學相關模型' (specifically search PK-related models from BioModels). This distinguishes it from generic formula search tools like formula_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the tool via examples (query='absorption', drug='warfarin') and specifies it is specialized for PK models from BioModels. However, it does not explicitly mention alternatives or exclusions, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosure. It provides examples of equivalence behavior (e.g., trigonometric identity) and states that it returns whether expressions are equivalent, but it does not mention limitations, edge cases, or whether the check is purely read-only. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured with a clear purpose, usage note, Args section, Returns section, and two illustrative examples. Every sentence earns its place and the text is front-loaded with the core behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter comparison tool with an output schema, the description covers what the tool does, when to use it, parameter semantics via examples, and return type. The guidance about verify.py tools adds important context about alternatives, making the description complete enough for an AI agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions for expr1/expr2 (0% coverage), so the description's Args block and examples must compensate. It adds only 'First expression' and 'Second expression,' which barely expands on parameter names, though the examples clarify the expected string format. This is minimal but sufficient for two obvious parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Check if two expressions are symbolically equivalent' with a specific verb and resource. It also distinguishes itself from more thorough verification tools by labeling itself as useful for 'quick verification' and directing users to verify.py tools for deeper checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says it is 'Useful for quick verification of derivation steps' and contrasts with 'For more thorough verification, use verify.py tools.' This gives clear when-to-use and when-not-to-use guidance, even though sibling tools are not individually named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description carries the full burden. It discloses the return format ('Combined expression with LaTeX'), the effect of the deep parameter ('Apply to subexpressions'), and shows multiple input/output examples. It lacks explicit discussion of failure modes (e.g., non-rational input), but for a pure rewriting operation this is largely acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with sections (summary, use cases, args, returns, examples), but it includes promotional text about 'PHASE 1 - NOT IN SYMPY-MCP OR NSFORGE v0.2.3!' and version comparisons that are irrelevant to tool usage. This extra noise detracts from an otherwise efficient layout.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two simple parameters and an output schema (not shown but indicated), the description provides thorough guidance: purpose, use cases, parameter semantics, return description, and four illustrative examples. It lacks only edge-case behavior (e.g., handling of already-combined expressions), but that is a minor gap given its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only bare titles and no descriptions, but the description compensates fully: 'expression: Sum of rational expressions' and 'deep: Apply to subexpressions (default: False)' give precise meanings. The examples also map concrete argument values to expected outputs, making parameter usage unambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Combine rational expressions over a common denominator,' using a specific verb and resource. It also provides distinct examples (e.g., '1/x + 1/y' → '(x + y)/(x*y)') that differentiate it from similar simplification tools like cancel or apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
A dedicated 'Use cases' section lists concrete scenarios (combine clearance terms, total bioavailability, multiple dosing routes, fraction addition), giving clear context on when to use the tool. It does not explicitly mention when not to use it or alternative tools, but the examples and phrasing sufficiently imply usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explicitly describes the transformation performed and the return format ('Partial fraction decomposition with LaTeX'), with multiple examples showing the expected output structure. While it doesn't explicitly state that the operation is non-mutating or read-only, the nature of a computational math tool makes this implicit, and the description provides sufficient behavioral clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for Args, Returns, and Examples, but it is longer than necessary and includes an unusual 'PHASE 1' header that may distract or confuse. Most content is valuable, especially the examples, but the header and repetitive formatting could be trimmed without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides a thorough context for a relatively simple tool: it explains the mathematical operation, lists practical use cases, documents all parameters, clarifies the return format (with LaTeX), and gives multiple examples covering simple, complex, and compartment-model scenarios. The presence of an output schema reduces the need to detail return values, but the description still covers the essentials comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It defines all three parameters clearly ('expression: Rational function to decompose', 'variable: Variable for decomposition (auto-detect if None)', 'full: Return full decomposition'), and the examples illustrate parameter usage. The explanations are brief but adequate, helping the agent understand each parameter's role beyond the schema's type/default info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs 'partial fraction decomposition' with a specific verb ('decomposes') and resource ('rational functions'). It distinguishes itself from sibling tools like factor_expression or expand_expression by its unique mathematical focus, reinforced by examples and the 'CRITICAL FOR' use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by listing critical use cases (inverse Laplace, integration, compartment models, transfer function decomposition) but does not explicitly mention when not to use the tool or name alternatives. It implies appropriate usage but lacks explicit exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clarifies the operation is a simplification (non-mutating function), specifies the return format (simplified expression with LaTeX), and gives identity examples that illustrate the transformation behavior. It does not discuss error handling or edge cases, but for a pure symbolic simplification tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized into purpose, use cases, args, returns, and examples, making it easy to scan. The banner and ASCII decoration add visual noise but do not obscure the essential information. It is longer than necessary but every functional section earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a single parameter, an output schema exists, and the description covers what the tool does, when to use it, valid input examples, and return format. For a task of this complexity, the description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description's 'Args: expression' line adds little beyond the field name. However, the examples provide concrete syntax for valid expressions (factorial(n)/factorial(n-3), binomial(n,k), rf(x,3)), which significantly compensates for the sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb+resource: 'Simplify combinatorial expressions (factorials, binomials).' It enumerates exactly what constructs are simplified and provides concrete examples that distinguish it from sibling simplification tools like trigsimp_expression or powsimp_expression.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases (Taylor series, probability, statistics, series expansions) that signal appropriate contexts. However, it does not explicitly name alternatives or state when NOT to use it, so it falls short of the highest standard.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description discloses it uses sympy.stats, warns that it's not available in SymPy-MCP, and states the return type (PDF/PMF). It does not fully detail side effects or error behavior, but for a pure definition tool it provides adequate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with headers for use cases, supported distributions, args, returns, and examples. It is longer than necessary, but every section adds value and the main purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 params, nested object), the description provides complete usage context, supported distributions, and examples. The output schema exists, so return details are not strictly required, but the description still mentions PDF/PMF. Minor gap: no explanation of how the returned definition can be used with sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description compensates with a thorough Args section, supported distribution names, and examples showing how to pass parameters as strings (e.g., {"mean": "mu", "std": "sigma"}). This goes well beyond the schema's generic additionalProperties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Define a probability distribution,' which clearly states the action and resource. It lists supported distribution types and use cases, distinguishing it from sibling tools like distribution_stats and distribution_probability which analyze rather than define.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases (model measurement uncertainty, population variability, error propagation, Monte Carlo preparation), giving context for when to use the tool. However, it doesn't mention alternatives or exclusions relative to sibling distribution tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses auto-save behavior ('自動存檔'), the auto_save parameter defaulting to True, and the return payload including save path. It does not mention whether completion is irreversible or blocks further step recording, but the state change is implied by 'mark as complete'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a Chinese summary, followed by well-organized Args, Returns, and Example sections. Every part adds value, including the detailed example, and there is no redundancy or unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 8-parameter schema with 0% coverage and the presence of an output schema, the description provides strong context about what to submit and what to expect in return. It explains the auto-save behavior and return fields. However, it doesn't mention session_id or how this tool relates to other finalization/abort siblings, leaving minor contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by defining most parameters in the Args section (description, clinical_context, assumptions, limitations, references, tags, auto_save). It omits session_id, which appears in the schema, leaving one parameter undocumented. The example further clarifies usage, but the gap prevents a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '完成推導並自動存檔' (complete derivation and auto-save) and '標記推導為完成' (mark derivation as complete). It explicitly says it returns the complete derivation record, which distinguishes it from step-level tools like derivation_record_step or derivation_abort.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that this is the completion step for a derivation and instructs the agent to provide descriptive knowledge (physical/clinical meaning, usage timing). However, it does not explicitly state when not to use this tool or contrast it with alternatives like derivation_abort, so exclusions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full safety burden. It discloses the critical limitation (only the last step can be deleted) and implies destructiveness via 'deleting'. However, it does not explicitly state that deletion is irreversible or that an active session is required, though the example hints at the return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is focused and well-structured. The warning box highlights the constraint, the Args/Returns/Example sections are concise and clear, and there is no filler. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete-step tool, the description provides the essential constraint and an example return. The existing output schema covers return format details. However, the lack of any mention of session_id, even though it is an input parameter, prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains step_number as 'must be the last step', adding critical meaning beyond the schema. However, session_id is completely undocumented in both the description and schema, leaving half the parameters underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '刪除單一步驟' (delete a single step), a specific verb+resource pairing. It further distinguishes itself from siblings by stating '只能刪除最後一步' (can only delete the last step) and referencing derivation_rollback for intermediate steps, making the tool's unique role clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (deleting the last step), and when not to (deleting intermediate steps), naming the exact alternative tool (derivation_rollback). This provides unambiguous selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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. It reveals the key algorithmic heuristic (higher score when a candidate defines a symbol in current_expression and matches the goal) and notes the output is ordered best-first. It stops short of edge-case behavior (e.g., empty candidate list), but for a ranking tool this is solid transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose, then uses a clear Args/Returns structure. It is moderately sized but every sentence contributes useful information—the retrieval context, scoring rule, and return shape. Slightly dense but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 params, no annotations, but an output schema), the description is complete enough: it explains the input sources, the ranking rationale, and the output format. It lacks details about possible values for 'kind' or handling of empty inputs, but these are marginal for an agent's invocation decision.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no parameter descriptions (0% coverage), so the description must compensate. It defines all three parameters in the Args section, including the nested structure of 'candidates' with optional fields like 'expression', 'kind', 'provides', and explains their role as formulas/modifications/operations. This goes well beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb 'Rank' and a clear resource 'candidate next steps for a derivation', and immediately states the ranking criterion 'by relevance'. This distinguishes it from sibling tools that actually perform steps (e.g., derivation_substitute) or retrieve formulas (formula_search), making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the user to supply candidates retrieved from open sources like formula_search, and explains the scoring logic, which clarifies when to use this tool. It does not explicitly name alternative tools to avoid using, but the context ('retrieval-augmented' versus actually applying steps) is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It says it returns a numeric result and mentions precision, but does not disclose error behavior, what happens if variables are missing, or whether it has side effects. It is adequate but lacks depth beyond the core function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat long but well-organized with clear sections, a workflow reminder, examples, and no filler. The length is justified by the need to clarify the correct context and parameter usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema and the description covers workflow, arguments, and return values with examples. It is complete for a straightforward evaluation tool, though it could mention edge cases like division by zero or invalid syntax.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero descriptions, but the tool's description includes an Args section explaining each parameter (expression, values, precision) and provides two examples showing exactly how to pass values as a mapping. This fully compensates for the schema gap and adds practical meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool as 'Evaluate expression numerically' with a specific verb and resource. It explicitly contrasts with symbolic work, distinguishing it from sibling symbolic tools like derivation_simplify and solve_inequality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit workflow: 'USE AFTER SYMBOLIC WORK', with numbered steps telling the agent to use SymPy-MCP first, then print_latex_expression, and finally this tool. It also states the tool is for 'final numeric values', making when-to-use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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. It states determinism ('Always expands products and powers'), defines return format ('Expanded expression with LaTeX'), and provides multiple examples that illustrate output transformations. It does not discuss error handling or edge cases, but for a math expansion tool, the behavior is well characterized.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured, using headers (Use cases, Args, Returns, Examples) and code blocks. It front-loads the core purpose and deterministic note before diving into details. The examples are extensive and valuable, though some (like the PK model and Michaelis-Menten) might be considered redundant; still, the organization keeps it readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, an output schema, and many sibling tools, the description covers purpose, parameters, return format, and usage examples comprehensively. It also gives a comparative hint with simplify. However, it does not address potential limitations (e.g., unsupported expression types) or error conditions, which would make it more complete for an agent to handle edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description's 'Args' section meticulously explains each of the 9 parameters, including the meaning of boolean flags (e.g., 'deep: Expand recursively', 'mul: Expand products') and the optional modulus for modular arithmetic. This fully compensates for the schema's lack of descriptions and adds semantic depth beyond the parameter names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Expand algebraic expression') and further clarifies deterministic behavior ('Always expands products and powers unlike simplify()'), which clearly distinguishes it from sibling tools like simplify, factor, and collect. The use cases provide concrete examples of expansion types (polynomial, power, exponential, logarithmic), leaving no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an explicit 'Use cases' section listing common scenarios (polynomial products, powers, coefficient extraction, logarithms) and contrasts with simplify(), giving clear contextual guidance. However, it does not explicitly mention when not to use this tool or name specific alternatives beyond simplify, leaving some nuance unaddressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the deterministic behavior, the return format ('Factored expression with LaTeX'), and demonstrates output shape through examples. It does not mention error handling, performance, or assumptions about variable domains, but for a pure factorization tool, these are minor gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat verbose with a banner and multiple examples, but the core purpose is front-loaded. Every example adds value by illustrating different use cases. The structure is logical (purpose, use cases, args, returns, examples), though it could be trimmed slightly without losing substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and presence of 60+ siblings, the description adequately covers when and how to use the tool, parameter semantics, and return format. The examples and use cases are sufficient for an agent to select this tool over alternatives. The lack of explicit output schema details is mitigated by the examples.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explicitly defines all three parameters: expression ('Expression to factorize'), deep ('Factor recursively into subexpressions, default: False'), and modulus ('Modular arithmetic for finite fields'). This adds meaningful semantics beyond the bare schema types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific statement: 'Factorize algebraic expression.' It further distinguishes itself from siblings by noting 'DETERMINISTIC: Always attempts factorization (unlike `simplify()`)' and provides concrete use cases that set it apart from tools like expand_expression or simplify.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists specific use cases (find roots, simplify rational functions, characteristic equations, stability analysis) and explicitly contrasts with simplify(). While it does not say 'do not use when...', the context implies when factorization is appropriate, and the comparison to simplify() gives a clear alternative. This is slightly above basic guidance but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the data source (SciPy CODATA 2018), return format (values, units, uncertainty), and available categories, which covers essential behavioral aspects for a read-only retrieval tool. It does not mention edge cases like empty results, but this is minor for this simple tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a short purpose statement, Args, Returns, and Example sections. It is slightly verbose but every section provides useful information, making it easy for an agent to quickly grasp the tool's behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description covers purpose, parameters, returns, and examples. There are no annotations, but the description provides enough detail for an agent to select and invoke the tool correctly, though it could mention default behavior when no arguments are provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates. It explains 'category' with enumerated values (fundamental, electromagnetic, atomic, conversion) and 'query' as an optional search keyword. Examples further clarify parameter usage, adding significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('列出' / list) and identifies the resource ('物理常數' / physical constants from SciPy CODATA 2018). It clearly distinguishes this tool from the sibling formula-related tools by focusing on constants lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on how to use the tool via category explanations and examples. It does not explicitly mention when not to use it or compare with alternatives, but the scope is well-defined, and the examples demonstrate typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since there are no annotations, the description must convey safety and operational semantics. It discloses return values (True, False, or None if unknown), the underlying sympy.assumptions module, and includes examples. The confusing 'NOT AVAILABLE IN SYMPY-MCP!' warning could be clarified, but overall it provides substantial behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with headers, bullet points, and examples, but contains an eye-catching banner and decorative box that adds noise. It is appropriately sized for the tool's complexity, though the banner could be simplified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema and moderate complexity. The description covers parameters, usage scenarios, available queries, and examples, which is sufficient for an AI agent to invoke it correctly. However, the availability warning is cryptic and might confuse the agent about whether the tool can be used.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by listing all query enum values, specifying the assumptions format with an example, and demonstrating parameter usage in two examples. This goes beyond the schema's bare property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Query') and resource ('properties of an expression based on assumptions'). It further enumerates use cases and available query types, making it distinct from sibling tools like evaluate_numeric or symbolic_equal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases (check if expression is always positive, verify domain validity, check for singularities) that clarify when to use the tool. However, it does not mention alternatives or explicitly state when not to use it, so it falls at 'clear context, no exclusions'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behaviors: rationalizes denominators, attempts simplification of nested radicals, and returns LaTeX output. It also explains the effect of 'symbolic' and 'max_terms' parameters. It does not discuss failure modes or edge cases, but for a pure math simplification tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with clear sections (Args, Returns, Examples) and front-loaded with the primary purpose. The banner and emojis add visual noise but do not obscure content. It is longer than strictly necessary, but every section contributes to usability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description is thorough: it explains the return format ('Simplified expression with LaTeX'), gives four illustrative examples including edge cases like nested radicals, and enumerates all parameters. Given the output schema exists, the description fully covers what the agent needs to know to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explicitly explains all three parameters: 'expression: Expression to simplify', 'symbolic: Allow symbolic radicals', and 'max_terms: Maximum terms in denominator for rationalization'. This adds meaningful semantics beyond the schema's type/default information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Simplify radicals (square roots, cube roots, etc.)' and 'Rationalizes denominators and simplifies radical expressions,' using a specific verb (simplify/rationalize) and resource (radical expressions). It clearly distinguishes itself from sibling simplification tools (e.g., trigsimp_expression, powsimp_expression) by focusing on radicals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete use cases (rationalize denominators, simplify nested radicals, half-life calculations, geometric mean) and examples that indicate when to use the tool. However, it does not explicitly mention alternatives or when not to use it, but the use cases are clear enough to infer applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the input formats and gives an example output ('verified: True'), but does not detail return structure (beyond the example), error behavior, or limitations. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise, well-structured docstring with Args, Returns, and Examples sections. Every sentence adds value, and the example clarifies usage clearly. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool, the description covers all parameters, gives an example, and mentions the return type. Although an output schema exists (not shown), the description's 'Returns: Verification result' plus example is sufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only parameter names and types (0% description coverage). The description compensates fully by explaining each parameter: equation format ('lhs = rhs' or 'expr'), solution meaning, and variable default. This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Verify that a value satisfies an equation.' It uses the specific verb 'verify' and identifies the resource (a solution against an equation). This distinguishes it from sibling tools like verify_derivative, verify_integral, and verify_equality, which target different verification scenarios.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when you have an equation and a claimed solution to check. It does not explicitly name alternatives or exclusions, but the context is sufficient to avoid obvious misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses return format (LaTeX result, plus condition for infinite series), and examples illustrate expected outputs including the convergence condition. It does not explicitly state read-only behavior or potential errors, but for a calculation tool this is largely implicit. The 'NOT AVAILABLE IN SYMPY-MCP!' warning is confusing but not misleading about the tool's core behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Use cases, Args, Returns, Examples). However, the prominent 'NOT AVAILABLE IN SYMPY-MCP!' banner is extraneous and could confuse agents, and the use cases are somewhat verbose. The core description is efficient, but the banner reduces conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is comprehensive for a calculation tool: it lists use cases, defines all four parameters, explains the return format, and provides three worked examples with expected results. Even though an output schema exists, the description adds valuable context about conditions and conventions (e.g., using 'oo' for infinity), making it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides parameter names with no descriptions. The description includes a dedicated Args section explaining each parameter ('expression: The summand (term being summed)', etc.), plus examples that show how to pass expressions like 'r**n' and 'oo' for infinity. This adds substantial meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Calculate symbolic summation', which is a specific verb+resource statement. It clearly distinguishes from siblings like calculate_limit and calculate_series by focusing on summation. Use cases (finite sums, infinite series, partition functions, PMFs) further clarify its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear list of use cases (finite sums, infinite series, partition functions, probability mass functions), which tells the agent when to use this tool. It does not explicitly mention alternatives or when not to use it, but the use cases imply a targeted scope and the sibling tools are distinct enough to avoid confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the destructive behavior (deletes steps after the target, or all steps if to_step=0), the return value structure, and includes a concrete example showing the expected output. This exceeds typical transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and uses clear sections (Args, Returns, Example). It includes decorative elements and an emphatic tagline that add slightly to verbosity, but overall every section contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the rollback action, parameter semantics, return values, and a worked example, making it sufficient for an agent to select and invoke correctly. Gaps include session_id handling and error cases, but these are minor given the output schema and example.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description thoroughly explains the to_step parameter (1-based, retained, 0 clears all) adding significant meaning beyond the bare integer schema. However, session_id is not mentioned at all, leaving it ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '回滾到指定步驟' (rollback to a specified step) and explains it retains the specified step and deletes subsequent steps, distinguishing it from sibling tools like derivation_delete_step or derivation_get_step. The core purpose is immediately clear and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides context for when to use: rolling back to a step to try a different derivation path, and explains the 0 value clears all steps. However, it doesn't explicitly name alternatives or exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return structure (a JSON object with kinetic_laws array and fields like reaction_id, math, parameters) and an example, which is significant. It does not address error handling or edge cases, but for a read-only retrieval tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, args, returns, and example. The Returns block is detailed but directly useful for understanding the output. It is slightly longer than necessary but every section serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single parameter and a full example of the return structure, the description provides everything an agent needs to invoke the tool correctly. The output schema existence is supported by the detailed Returns example, making the description complete for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only the parameter name 'model_id' with no description (0% coverage). The description fully compensates by specifying 'BioModels 模型 ID（如 "BIOMD0000000012"）' with a concrete example format, adding essential meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb+resource: '獲取 BioModels 模型的動力學公式' (retrieve kinetic laws from BioModels models) and elaborates with '從 SBML 模型中提取所有動力學方程式' (extract all kinetic equations from SBML models). This distinguishes it from sibling tools like formula_get or derivation tools by focusing on SBML kinetic laws.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: to get kinetic laws from a BioModels model. It does not explicitly mention alternatives or exclusions, but the purpose is unambiguous. The example call reinforces the usage pattern, so it earns a 4 rather than 3.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It communicates the transform direction, return format via examples (e.g., 'sqrt(pi)*exp(-pi**2*k**2)'), and parameter defaults. However, it does not disclose potential edge cases like unsupported inputs or unevaluated results, which would be valuable additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for args, returns, and examples, but includes some non-essential content such as the 'PHASE 2' banner and a lengthy list of use cases. It is efficient overall, though not as lean as a two-sentence description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a transform tool, providing enough context through examples, use cases, and parameter docs. Even though an output schema exists, the examples clarify the exact return format, and the tool's behavior is fully specified for typical use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by listing each argument (expression, space_var, freq_var) with its meaning and defaults. This goes beyond the schema's minimal type/title information, making parameter semantics completely clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fourier transform: f(x) → F(k)' and 'Transforms spatial/time function to frequency domain,' using a specific verb and resource. This distinguishes it from sibling tools like inverse_fourier_transform_expression and laplace_transform_expression.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases (periodic dosing, spectral analysis, signal processing, diffusion problems) and an example for PK analysis, giving clear context for when to apply the tool. It does not explicitly mention alternatives or exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It provides return format ('Time-domain function f(t)') and examples showing Heaviside(t) output, plus a multi-step workflow. It does not disclose potential failure modes or assumptions, but the transform behavior is well illustrated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with explicit sections and front-loaded with the core purpose. However, the 'PHASE 2' banner and emoji decorations add noise, and the 'CRITICAL FOR' list could be tightened. Still, every functional section (Args, Returns, Examples) earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, practical use cases, parameters, return value, examples including PK modeling, and a cross-tool workflow with apart_expression. With an output schema present and this rich textual context, the tool is fully contextualized.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the Args section describes each parameter: expression (frequency-domain function), freq_var (default 's'), time_var (default 't'). Examples also demonstrate positional usage, fully compensating for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Inverse Laplace transform: F(s) → f(t)' and 'Transforms s-domain (Laplace) back to time-domain,' clearly identifying the operation and resource. It distinguishes itself from the sibling laplace_transform_expression by explicitly naming the inverse direction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'CRITICAL FOR' section lists concrete application contexts (time response, PK models, impulse/step response, converting algebraic solutions). It also includes a workflow reference to apart_expression. However, it does not explicitly state when not to use this tool or compare it with inverse_fourier_transform_expression.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It describes the output format ('result' and 'convergence') and gives multiple examples illustrating behavior. However, it does not explicitly state that the operation is non-mutating or discuss error handling for invalid expressions, leaving some minor gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with headings (Args, Returns, Examples) and front-loaded with the core definition. It is somewhat lengthy due to the 'PHASE 2' banner and multiple PK-specific examples, but the additional content is relevant and organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is comprehensive: it states the mathematical purpose, critical applications, parameter semantics, return format, and several examples. Although an output schema exists, the description supplements it with convergence-condition details and domain-specific context (PK/compartment modeling), making it fully usable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an 'Args' section that explains expression, time_var, and freq_var, including their roles and defaults. Since schema description coverage is 0%, this fully compensates and adds meaning beyond the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Laplace transform: f(t) → F(s)' and explicitly states 'Transforms time-domain functions to s-domain (Laplace domain).' This clearly specifies the operation and distinguishes it from inverse or Fourier transforms also present in the sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists critical use cases: ODE solving, stability analysis, transfer functions, and compartment model analysis. This provides clear context for when to use the tool, though it does not explicitly mention when not to use it or point to alternatives like inverse_laplace_transform_expression.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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. It explains the effects of 'deep', 'combine', and especially 'force' (which overrides validity assumptions), and states the return format. This goes beyond the bare schema and gives useful context for the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear sections for purpose, use cases, arguments, return value, and examples. The 'PHASE 1' banner adds minor noise but does not detract significantly. It is slightly long but every section contributes useful information for the intended complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the detailed parameter explanations, the description is complete for an agent to correctly invoke the tool. It includes example calls and results, covers all parameters, and describes the return format. No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema lacks parameter descriptions (0% coverage), so the description fully compensates by explaining each parameter: 'expression', 'deep', 'combine' with its allowed values ('all', 'base', 'exp'), and 'force'. It also provides defaults and examples, making parameter usage unambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Simplify powers and exponentials,' a specific verb+resource statement. It further clarifies by listing concrete use cases like combining exponentials and simplifying powers, which distinguishes it from sibling simplification tools such as trigsimp_expression or radsimp_expression.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases for when to apply the tool, such as combining powers, simplifying nested powers, and handling exponentials. However, it does not explicitly mention when not to use it or compare it to alternative simplification tools, so it lacks formal exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It includes an availability warning, return format details, and worked examples. It does not mention error handling or side effects, but for a solving tool this is acceptable given the examples.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for use cases, parameters, return format, and examples. The large banner warning adds some visual noise but also provides important availability context. Overall, every section earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the presence of an output schema, and the provided examples, the description is complete. It covers purpose, parameters, return format, and usage scenarios, making it self-sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the 'Args' section thoroughly explains each parameter (inequality, variable, domain) with formatting details and example usage. This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Solve a single inequality' and lists specific use cases (parameter ranges, stability conditions, etc.), making the tool's purpose clear and distinguishing it from the sibling tool solve_inequality_system which handles systems.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear use cases and implicitly limits scope to a single inequality. However, it does not explicitly mention alternatives like solve_inequality_system nor give when-not-to-use guidance, though the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It explicitly warns that deletion is irreversible, specifies what gets destroyed (records and YAML files), and explains the confirm safety mechanism. This is thorough behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with a warning, args, returns, and example. Each sentence adds essential information without redundancy, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive delete operation with no annotations, the description covers the essential behavioral contract: irreversibility, affected resources, safety flag, and example invocation. The presence of an output schema (per context) means generic return description is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides only parameter names/types with no descriptions (0% coverage). The description adds meaning: result_id is the derivation result ID, and confirm must be True to delete, acting as a safety check. The example clarifies parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes saved derivation results, specifying both derivation records and YAML files. It distinguishes itself from sibling tools like derivation_delete_step by targeting saved results rather than steps or sessions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this to permanently delete saved results, and requires confirm=True to execute. However, it does not explicitly mention alternatives or when not to use, leaving comparison to sibling delete tools implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly indicates a read-only search operation and provides a return format example. It does not disclose limitations like pagination or sort order, but these are relatively minor for a simple search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with purpose, Args, Returns, and Example, conveying all necessary information in a compact, easy-to-parse format. Every section adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter search tool with no annotations, the description covers the operation, the parameter, the result shape, and an example. It is complete enough for an agent to select and invoke correctly, especially given an output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only type and required flag for 'query', but the description adds the semantic meaning '搜尋關鍵字' (search keyword), fully clarifying the parameter's purpose. This compensates for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches saved derivation results by keyword across name, description, and tags, using a specific verb '搜尋' and resource. This distinguishes it from sibling tools like derivation_list_saved (which lists all saved) and formula_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on what is searched (name, description, tags), giving the agent an understanding of when to use it. However, it does not explicitly name alternatives or provide exclusions, so a small deduction is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses the direct non-RAG retrieval method, source options, and return schema, which is valuable context. It omits error handling and rate limits, but for a search tool the key behaviors are well-covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with a one-line summary, Args section, Returns schema, and examples. Every part earns its place without redundancy or unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no annotations, the description covers query syntax, source selection, domain filtering, output format, and usage examples. It even includes the response schema. Minor omissions like error handling or pagination are not critical for this search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It thoroughly explains each parameter: query format with examples, source enumeration, domain domain values, and limit behavior. Returns and examples further clarify parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches formulas across multiple authoritative sources, positioning it as the core scientific computing tool. It distinguishes itself from siblings like formula_get by emphasizing cross-source search and direct exact retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool is the core search mechanism and provides realistic examples across formula types and domains. However, it doesn't explicitly mention when not to use it or name alternatives, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full weight. It discloses key behaviors: runs every candidate through the full loop, returns all with acceptance results and provenance, ranks by rule, and documents the timeout behavior (separate process, kill on overrun, returns success False/timed_out True). It stops short of stating side effects or permission needs, but the coverage is strong for a non-annotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly written with a clear summary, args, and returns structure. It packs essential distinctions (ranking logic, timeout behavior, task_run comparison) without redundancy. Every sentence contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with an output schema, the description explains the return shape ('{"success", "concept", "candidates": [...]} ranked best-first') and the ranking semantics. It also directs the user to task_plan for spec definition. It is complete enough for an agent to select and invoke without ambiguity, though some details of 'DTS' are delegated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Context signals show 0% schema description coverage, so parameter meaning depends entirely on the description. It defines spec as 'A DTS dict (see task_plan); alternatives are the branches' and explains timeout_s as a wall-clock cap with process isolation and kill behavior. This adds meaningful semantics beyond the bare type/required info in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Explore a branching derivation tree from a DTS.' It clearly identifies the tool's function and distinguishes it from the sibling task_run by noting that task_explore surfaces all candidates ranked best-first, while task_run self-corrects to the first passing branch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance via the contrast with task_run: 'Unlike task_run (which self-corrects to the first passing branch), this surfaces the whole space of verified answers.' This tells the agent when to choose this tool (when all candidate branches are needed) over the named alternative. No other exclusions needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It reveals that the generated code uses SymPy for computation, is assembled from verified steps, and is not agent-generated, providing important context about its reliability. However, it does not discuss potential failure modes or behaviors when prerequisites are unmet, so it falls slightly short of full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured effectively with headers, a warning banner, and a clear example. It is lengthy due to the necessary detail (args, workflow, example), but every section serves a purpose. The only minor issue is slight redundancy in restating the verification requirement in multiple ways.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers prerequisites, workflow, parameters, and provides a full example. Since an output schema exists, the description need not detail return values beyond 'Generated Python code'. The description is sufficiently complete to guide correct use without ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), but the description fully compensates with a detailed 'Args' section for all five parameters, explaining their expected structure, and provides a comprehensive example that demonstrates each parameter with concrete values. This gives the agent complete guidance for parameter construction.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generate a Python function from VERIFIED derivation steps.' This identifies a specific verb (generate), resource (Python function), and context (verified derivation steps), which distinctly differentiates it from sibling tools like generate_latex_derivation, generate_sympy_script, and generate_derivation_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly outlines the correct workflow in numbered steps, starting with a PREREQUISITE warning that expressions must be verified with SymPy-MCP first. It specifies when to use this tool (after user confirmation) and contrasts it with agent-generated code, making the usage context and alternatives clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![nsforge-mcp MCP server](https://glama.ai/mcp/servers/u9401066/nsforge-mcp/badges/card.svg)](https://glama.ai/mcp/servers/u9401066/nsforge-mcp)

Score Badge

Copy to your README.md:

[![nsforge-mcp MCP server](https://glama.ai/mcp/servers/u9401066/nsforge-mcp/badges/score.svg)](https://glama.ai/mcp/servers/u9401066/nsforge-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/u9401066/nsforge-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server