MCPCalc

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. While it mentions outputs (results + prefilled URL), it omits critical behavioral context: whether it creates/modifies sessions, side effects, error handling, or the nature of the prefilled URL given the session-rich tool ecosystem.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence structure is appropriately sized and front-loaded with the core action. However, extreme brevity sacrifices necessary contextual details about the tool ecosystem and session behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complex calculator system evidenced by session management siblings and nested input objects, the description is incomplete. It lacks session behavior details and, with no output schema present, only minimally hints at return values.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 100% coverage. Description mentions 'prefilled URL' (output behavior) but adds no specific parameter semantics beyond what the schema already provides for 'calculator', 'inputs', or 'strict'. Baseline 3 appropriate given full schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States that it runs a calculation and returns results with a prefilled URL, but fails to distinguish from siblings 'calculate_cas' and 'calculate_cas_headless', leaving ambiguity about which calculate tool to use for specific scenarios.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides no guidance on when to use this tool versus calculate_cas variants, whether it requires an existing session (given siblings like create_session/push_session_action), or how it relates to generate_prefilled_url.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, description carries full burden and successfully discloses key behavioral traits: server-side execution, mode limitation (MCP-only numeric), and critical fallback behavior (returns GUI handoff link for unsupported expressions). Does not mention auth requirements or idempotency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two efficient sentences with zero waste. First sentence front-loads purpose and scope; second sentence adds critical behavioral constraint (GUI handoff). Appropriately sized for tool complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Complete given rich input schema (100% coverage) and tool complexity. Adequately describes fallback behavior despite lacking output schema. Could explicitly mention successful return format or differentiate from 'calculate_cas_headless'.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 100% description coverage, establishing baseline 3. Description reinforces the 'one or more' capability mapping to expression/expressions parameters but adds no syntax details or mutual exclusivity constraints beyond what schema already documents.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States specific action (Evaluate), resource (headless CAS expressions), and scope (server-side, MCP-only numeric mode). Distinguishes from generic 'calculate' via CAS specificity and numeric mode restriction, though relationship to sibling 'calculate_cas_headless' remains ambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides implied usage context via 'MCP-only numeric mode' and describes fallback behavior (GUI handoff for unsupported expressions), but lacks explicit guidance on when to choose this over siblings like 'calculate' or 'calculate_cas_headless', or when to use single vs batch expressions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses the critical fallback behavior (returns GUI handoff details for unsupported features) and 'headless' nature, but omits other behavioral traits like error handling, return value structure, or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with zero waste. Front-loaded with alias relationship and headless nature, followed by specific behavioral constraint. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for an alias tool: explains alias relationship, headless nature, and fallback behavior. However, with no annotations and no output schema, it should ideally describe the return value structure or evaluation guarantees.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, providing full documentation for 'strict', 'expression', and 'expressions'. Description adds domain context ('CAS') but does not elaborate syntax, examples, or relationships between the mutually exclusive parameters beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly identifies itself as an alias of calculate_cas and specifies it is a 'Headless MCP-only CAS evaluator,' distinguishing it from siblings via the 'headless' and 'MCP-only' constraints. The GUI handoff clause further differentiates behavior.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage context with 'MCP-only' and hints at limitations via 'unsupported features' triggering GUI handoff, but lacks explicit guidance on when to prefer this over calculate_cas (the sibling) or vice versa.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries the full burden of behavioral disclosure. It mentions the optional snapshot persistence, which is valuable, but fails to clarify how this optionality is controlled (no corresponding parameter in schema) or what the snapshot contains. Missing: cleanup behavior, reversibility, error cases (invalid session_id), and return values.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The single sentence is efficiently structured and front-loaded. However, the phrase 'optionally persist' creates ambiguity given the lack of a persistence-related parameter in the schema, slightly undermining clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

As a stateful session management operation with side effects (snapshot persistence), the description is insufficient. It lacks disclosure of return values, error conditions, and lifecycle implications. With no output schema or annotations to provide this context, the description should elaborate further.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage ('Session UUID'), the schema adequately documents the single parameter. The description adds no additional semantic context for session_id (e.g., format constraints, source from create_session), warranting the baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description provides a clear verb ('Close') and resource ('session'), and adds specific behavioral detail about persisting a snapshot. However, it does not explicitly differentiate this from session lifecycle operations like create_session or clarify the relationship between closing and retrieving state via get_session_state.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance is provided on when to invoke this tool versus leaving a session open, whether sessions auto-expire, or prerequisites (e.g., should state be retrieved first?). The description only implies usage through the verb 'Close' without contextual constraints.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must carry full behavioral disclosure. It successfully mentions the return value (session URL), compensating partially for the missing output schema. However, it omits critical behavioral details: session expiration, idempotency of creation, error handling for invalid calculator slugs, and side effects (resource consumption).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single efficient sentence (12 words) with no redundancy. The information is front-loaded with the imperative action. It packs essential details (creation, resource type, calculator scope, return value) into a compact form, though the density slightly limits explanatory power.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of session lifecycle siblings (close_session, push_session_action, get_session_state) and the lack of output schema, the description adequately covers the immediate return value (URL) but misses opportunity to contextualize the session creation within the broader workflow (e.g., that sessions persist state for multi-step calculations or require cleanup).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 100% description coverage ('Calculator slug' and 'Optional session metadata'), establishing a baseline of 3. The description adds minimal semantic value beyond the schema—it implies the calculator parameter accepts any calculator but doesn't clarify what metadata fields are acceptable or provide examples/composition guidance for the nested metadata object.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Create'), resource ('interactive session'), and specific output ('return the session URL'). It implicitly distinguishes from siblings like 'calculate' (one-off vs. session-based) and 'close_session' (create vs. close), though it could more explicitly clarify the stateful nature compared to immediate calculation tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides minimal usage guidance. While 'for any calculator' indicates scope, it lacks explicit guidance on when to prefer this over 'calculate' or 'calculate_cas_headless', and fails to mention prerequisites such as needing a valid calculator slug (likely from list_calculators) or that the session requires subsequent management via sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full disclosure burden. It clarifies the tool does NOT execute calculation, but fails to specify return format, session creation behavior (relevant given session-related siblings), idempotency, or error handling for invalid calculator slugs. Minimal 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single 7-word sentence. Front-loaded with verb. Zero redundant information. Perfect information density for the constraints.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Missing output description (critical since no output schema exists). Should clarify relationship to session lifecycle given sibling tools (create_session, close_session) and whether the URL is persistent or temporary. Inadequate for a tool with nested objects and complex ecosystem interactions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 100% coverage (baseline 3). Description adds valuable semantic context: 'prefilled' explains the purpose of the 'inputs' parameter (pre-population values), and 'URL' clarifies the output type. 'Without running calculation' further contextualizes that inputs are stored, not computed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States specific action (Generate) and resource (prefilled URL) with effective scope qualifier 'without running calculation' that distinguishes it from the calculate/calculate_cas siblings. However, omits what the URL is used for (sharing, accessing later, etc.).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'without running calculation' provides implicit contrast with calculation siblings, but lacks explicit when-to-use guidance, prerequisites (e.g., valid calculator slug), or named alternatives. No mention of when to prefer this over direct calculation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, yet description fails to disclose side effects (read-only implied by 'Get' but not explicit), return format (JSON Schema object?), caching behavior, or error conditions (e.g., invalid calculator slug). Full burden falls on description which provides minimal behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, efficient without redundancy. Front-loaded with action verb. However, given zero annotations and no output schema, extreme breveness leaves significant gaps; a second sentence detailing returns would improve utility without sacrificing clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for simple single-parameter tool with complete schema coverage, but fails to compensate for missing output schema—it should describe the return value structure (likely JSON Schema definition) and relationship to calculate workflow. Minimum viable but incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% ('Calculator slug' documented). Description mentions 'specific calculator' which aligns with parameter but adds no semantic depth about slug format, valid characters, case sensitivity, or how to obtain valid values (presumably from list_calculators). Baseline 3 appropriate when schema carries full load.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clear verb 'Get' and resource 'input schema' with scope 'for a specific calculator'. Distinguishes from calculation siblings (calculate, calculate_cas) by specifying this retrieves metadata rather than performing computation. Minor deduction for not clarifying what 'input schema' contains (parameters, types, constraints?).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to invoke this tool versus siblings. Given calculate requires parameters, this should indicate it's for discovery/introspection before calculation, or when parameter requirements are unknown. No mention of prerequisite tools or workflow position.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, description carries full disclosure burden. It successfully enumerates the three data structures returned, but omits behavioral details like side effects, error conditions for invalid sessions, or idempotency. Just meets minimum viable 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single dense sentence (14 words) with zero waste. Front-loaded with verb, immediately lists retrieved components, ends with scope constraint. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Strong for a 1-parameter tool lacking output schema: compensates by detailing the three specific data structures returned. Would benefit from noting error behavior if session inactive, but adequately covers core retrieval contract.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 100% coverage ('Session UUID'), establishing baseline 3. Description adds minimal semantic value via 'active session' constraint implying the session_id must reference a currently open session, but does not elaborate on UUID format or validation rules.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Excellent specificity: uses active verb 'Retrieve', names the exact resource components (field values, computation transcript, pending message queue), and clearly distinguishes from calculation-focused siblings (calculate*, push_session_action) by emphasizing state observation vs action/execution.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides implied usage context through 'for an active session' (indicating prerequisite), but lacks explicit when-to-use guidance versus alternatives like create_session or close_session. No explicit exclusions or alternatives named.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full disclosure burden. While 'List' implies read-only safety, it omits return format (IDs? names? objects?), pagination behavior, and whether results are cached or real-time—critical gaps for a discovery tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single efficient sentence with no redundancy. Front-loaded with active verb. Appropriately compact, though extreme brevity contributes to informational gaps in other dimensions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Lacks output schema, yet description fails to specify what the list contains (calculator IDs, names, metadata?) or return structure. For a discovery tool with zero annotations, the description is insufficient to predict invocation results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (category parameter fully documented with examples). Description adds 'optionally' to reinforce optionality but provides no additional semantic detail beyond the schema (e.g., valid category values sourced from where).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States specific verb (List) and resource (calculators) with scope (optionally filtered). Implies distinction from siblings like 'calculate' (execution) and 'get_calculator_schema' (single schema retrieval), though could explicitly clarify it returns identifiers/names for discovery.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides no guidance on when to use this versus 'get_calculator_schema' or which calculators require session creation first. No mention of prerequisites or filtering strategy.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It successfully discloses the message queue mechanism, implying asynchronous processing. However, it lacks critical behavioral details: whether actions are processed atomically, what happens on partial failure, potential side effects on session state, or whether this operation is idempotent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Every word earns its place in this single, front-loaded sentence. The parenthetical examples efficiently illustrate scope without verbosity. No redundancy or structural waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's extreme complexity (29 action types spanning CAS, spreadsheets, proof systems, and RPN), the description is minimal but acceptable because the schema carries the descriptive load with 100% coverage. It appropriately focuses on the transport mechanism (message queue) rather than duplicating the exhaustive action type documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, establishing a baseline of 3. The description adds value by providing concrete examples (set fields, submit computation, trigger plot) that illustrate the polymorphic 'actions' array items, and it clarifies the 'session' destination as a message queue—context not fully captured by the schema's 'SessionAction' terminology.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb (Push), resource (actions), and destination (session's message queue). It distinguishes this from sibling 'calculate' tools by implying asynchronous queue-based execution rather than immediate computation. However, it could explicitly clarify that this operates on interactive calculator sessions vs. headless calculations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

While it lists example actions (set fields, submit computation, trigger plot), it provides no explicit guidance on when to choose this over 'calculate', 'calculate_cas', or direct API calls. It omits prerequisites (requires active session_id from create_session) and offers no decision framework for selecting among the 29 possible action types in the enum.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.