calculator_describeThe inputs this calculator takes (with units, ranges and defaults), the outputs it returns, and the assumptions and tables behind it.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry behavioral/safety information. It discloses the content returned (inputs, outputs, assumptions, tables), which implies a read-only informational call. It does not explicitly state side-effect-free behavior or the output format, but for a describe 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
One tight sentence that front-loads all key content areas. No filler or repetition of the schema.
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 zero parameters and no output schema, the description names the return dimensions (inputs, outputs, assumptions, tables) sufficiently for an agent to judge relevance. It could explicitly note that no calculation is performed and that the result is informational, but sibling naming makes this inferable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema carries no semantics; baseline is 4. The description compensates by specifying that the tool will describe parameter units, ranges, and defaults for the calculator, adding conceptual meaning beyond the empty 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?
The description clearly identifies a documentation/describe purpose: it will relay the calculator's inputs (with units, ranges, and defaults), outputs, and underlying assumptions and tables. The title reinforces this. It does not explicitly contrast with sibling `calculate`, but the describe-vs-calculate distinction is evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is the reference for understanding the calculator, so an agent would call it before or instead of `calculate` when needing semantics. However, it never states when to prefer this over siblings or gives exclusions, leaving the decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a distinct role: calculate runs the calculator, calculator_describe documents it, while enquiry_describe explains the enquiry flow, enquiry_fields provides the schema, and submit_enquiry performs the submission. There is no meaningful overlap or ambiguity between them.
Names are readable and mostly follow a noun-oriented pattern for descriptive tools (calculator_describe, enquiry_describe, enquiry_fields) with action verbs for operations (calculate, submit_enquiry). The main inconsistency is that calculate is a bare verb while calculator_describe reverses the verb-noun order, but this is minor and not confusing.
Five tools is well-scoped for this server's purpose: two calculator-related tools and three enquiry-related tools. Each tool has a clear place and none feel redundant or missing.
The surface fully covers the calculator and enquiry workflow: the calculator can be executed and its assumptions inspected, and the enquiry flow includes process documentation, field schema, and a validated two-step submission with consent. No obvious dead ends or missing operations are apparent.