Unofficial Tesoro High School MCP

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

Annotations already communicate readOnly, idempotent, and non-destructive behavior. The description adds useful unknown-id behavior ('typed miss with no document fields'), which helps the agent avoid fabricating results for missing documents.

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 short, front-loaded sentences. The action, resource, parameter role, and edge-case behavior are all present with zero filler. Every sentence 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?

For a simple one-parameter, read-only fetch, the description combined with annotations covers the core semantics and the not-found path. It is not a perfect 5 because this does not mention search_school as a fallback when the id is unknown and gives no indication of the return shape.

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. The phrase 'by id' clarifies that the string parameter is the document identifier, but it does not explain where valid ids come from or what format they follow. This is adequate but leaves meaningful gaps.

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 'Fetch one Tesoro document by id', combining a specific verb, a clear resource, and the key selector (id). This clearly communicates a single-document lookup and distinguishes it from a search-style tool purely by semantics.

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 explicit guidance about when to choose get_document vs search_school. It implies exact-id lookup but does not say 'use search_school when you lack an id' or provide any exclusion conditions.

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?

Annotations already mark this read-only, idempotent, and non-destructive. The description adds valuable behavioral detail beyond those: it explains server-side processing and returns snippets with provenance, and defines the empty-array result, which is useful for interpreting outcomes.

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 concise, purposeful sentences, each adding distinct value: the scope, the input guidance, and the output semantics. There is no filler or redundancy.

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 there is no output schema, the description adequately explains the return value and its interpretation. The main gap is the undocumented limit parameter and the lack of explicit guidance about when get_document should be used instead, but the core invocation is well covered.

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 description adds strong meaning for the required work parameter: it should receive the parent's question verbatim and will be processed server-side. However, the optional work parameter is never explained, and with 0% schema description coverage, the description does not fully compensate for the omitted semantics of 'limit'.

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 tool 'searches Tesoro public documents', giving a specific verb and resource. It does not explicitly contrast with the sibling tool get_document, so it misses the top score, but the intent is unmistakable.

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 instruction to 'pass the parent's question verbatim' is a direct, actionable usage guideline, and clarifying that stopword removal, ranking, and typo correction happen server-side tells the agent not to preprocess the query. It does not explicitly mention when to prefer this over get_document, 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.