touchstone-mcp

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 implies a pure conversion, but does not state whether it is a read-only calculation, whether it depends on live pricing data, or what happens with invalid/unrecognized models. This is a significant gap for a tool with no annotation safety profile.

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

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

The description is a single front-loaded sentence with no wasted words. It is concise, though perhaps too brief to carry the explanatory load given the lack of schema descriptions and annotations.

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

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

The tool requires three parameters and has no output schema or annotations. The description does not explain how the model parameter influences the result, the nature of SIU, expected return format, or error behavior. For a conversion tool of this simplicity, the description is minimally adequate but incomplete for confident invocation.

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 schema description coverage at 0%, the description must compensate. It relates 'token counts' to the token parameters and 'model call' to the model parameter, but does not explain how model affects the conversion, what units the token counts are in, or what SIU means. The available schema provides only types and bounds, leaving key semantics undocumented.

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

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

The description states a specific action ('Convert') and resource ('model call's token counts') and identifies the output units (SIU and USD). It is distinct from the sibling tools, though the acronym 'SIU' is unexplained, which leaves some ambiguity.

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

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

No guidance is given on when to use this tool versus the siblings. The description gives no context about use cases, prerequisites, or alternatives, so the agent must guess based on the name alone.

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 of behavioral disclosure. It does not state whether this operation is read-only, whether it returns data, whether it costs anything, or what 'signed' and 'print' mean operationally. 'Free' hints at pricing but is too ambiguous to be useful.

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 short, but this is under-specification rather than conciseness. The fragment 'The signed Dated SIU print' is not a complete or informative sentence, and 'Free — citation is the business' adds no operational 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?

For a tool with no output schema, no annotations, and two undocumented parameters, the description is severely incomplete. An agent cannot correctly invoke this tool or interpret its purpose from the information given.

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% and the description provides no meaning for the 'date' and 'version' parameters. An agent has no way to know what formats are expected, what values are valid, or how these parameters affect the result.

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 'The signed Dated SIU print. Free — citation is the business.' is cryptic and does not state what the tool does. It does not mention retrieving an index, any clear action, or resource, and it fails to distinguish itself from siblings like get_quote or verify_receipt.

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?

There is no guidance on when to use this tool versus alternatives. No context, use cases, exclusions, or conditions are provided, leaving an agent unable to decide between get_index and its 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only lists returned data types and does not mention that this is a read-only lookup, any rate limits, error cases, or response format. The 'get' name implies read-only, but the description itself adds no explicit 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?

The description is extremely terse, which is efficient, but it is a noun-phrase fragment rather than a complete sentence. It conveys the gist in few words but omits important structure such as what the tool does (returns) and the parameter semantics, so it is more under-specified than properly concise.

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

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

For a tool with two required parameters and no output schema or annotations, this description is too thin. An agent lacks guidance on valid parameter values, how the returned data is structured, and how this tool relates to siblings such as get_index. The description does not provide enough context for reliable invocation.

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. It mentions 'task class' and 'model', which map to the two required parameters, but it does not explain what valid values look like, what 'task class' means, or how model names should be formatted. This is minimal value beyond the raw parameter names.

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 specifies the resource ('SIU price, exchange rate and index refs') and the scope ('for one task class and model'), so an agent can infer that get_quote returns quote-related data. It lacks an explicit verb, and 'index refs' overlaps with sibling get_index, so it does not fully distinguish itself from siblings.

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 gives no guidance on when to use get_quote versus alternatives like convert or get_index. It only states the input scope, leaving the selection logic entirely to the agent.

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, the description carries the full burden. 'Reads' implies a read-only operation, which is a useful safety signal, and 'returns a signed attestation' indicates the output behavior. However, it does not disclose failure modes, permissions, or the nature/validity guarantees of the attestation, so transparency is only partial.

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 one compact sentence with no filler and front-loads the action. It is appropriately concise for the minimal information it conveys, though the brevity contributes to the overall incompleteness.

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?

There is no output schema, no annotations, and a required nested quote object with an ambiguous schema. The description does not explain the input structure, output shape, or failure behavior, so an agent cannot reliably construct a correct call or interpret the result.

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%, and the description does not explain any of the three required parameters (chain, tx_hash, quote). The phrase 'on-chain settlement' vaguely maps to chain and tx_hash, but quote is entirely undefined, leaving an agent without the information needed to fill the nested quote object correctly.

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

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

The description uses a specific verb 'Reads' and a clear resource ('an on-chain settlement') plus an outcome ('returns a signed attestation'), so an agent understands the core function. It does not explicitly contrast with siblings like get_quote or get_index, but the distinct resource and output make the purpose reasonably clear.

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

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

There is no guidance on when to use this tool versus alternatives such as get_quote or get_index. It does not state prerequisites, workflow position, or conditions that would make verify_receipt the appropriate choice, leaving the agent to infer usage from the name alone.

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