Price a month of a usage you already know: simultaneous connections at peak, slices of 1000 bars, and symbols followed live continuously. Answers the smallest plan covering it and the CHF total before VAT. For the plans themselves, use get_offer.
| Name | Required | Description | Default |
|---|---|---|---|
| slices_per_month | Yes | ||
| continuous_symbols | No | ||
| simultaneous_connections | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses meaningful outcome behavior (returns the smallest covering plan and the CHF total before VAT), but says nothing about permissions, rate limits, or whether the quote is authoritative/binding. Partial coverage only.
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?
Three tight sentences, front-loaded with the verb and the priced inputs, then the output, then the sibling routing. No filler and nothing buried.
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?
An output schema exists so return-value enumeration isn't required, and the description still adds the two key result facts (smallest covering plan, CHF before VAT). With no annotations it could say more about side effects or freshness, but for a pure calculation tool it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does: it maps all three parameters to domain meaning ('simultaneous connections at peak', 'slices of 1000 bars', 'symbols followed live continuously'), clarifying units and semantics the bare integer schema leaves ambiguous.
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 opens with a specific verb+resource ('Price a month of a usage') and enumerates exactly what is being priced, distinguishing it from the sibling get_offer by naming that alternative explicitly. An agent can tell this pricing tool apart from the catalog tool without opening any schema.
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?
It frames the precondition ('a usage you already know') and routes the agent to get_offer 'for the plans themselves', which is a clear alternative with a selecting condition. It stops short of an explicit when-not/exclusion statement, but the context is unambiguous.
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.