Look up the published Wong Tai Sin stick reference and reading for a stick number from 1 to 100, in Chinese or English.
Look up an existing Wong Tai Sin stick number from 1 to 100. Returns the published reference and reading in Chinese or English. Does not draw a random stick or create a personalised reading.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | Yes | ||
| sign_number | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds value beyond them: it discloses the return content (published reference and reading) and the language dimension, plus the explicit non-random/non-personalised boundary. Auth and rate-limit behavior remain unstated, so not a 5.
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 short sentences with no filler: the core action and range come first, the return content second, the negative boundary last. Every sentence adds a distinct piece of information.
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 two-parameter read-only lookup with annotations covering the safety profile, the description supplies purpose, scope, return content, and exclusions. The absence of an output schema means the exact shape of the returned reference/reading is only summarized, which is the only material gap.
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 0%, so the description must carry the parameter burden, and it largely does: it states the sign_number range (1 to 100) and that language is Chinese or English, matching the zh/en enum. It does not name the parameter keys or clarify the enum tokens, so it compensates well but not fully.
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 a specific verb and resource ('Look up an existing Wong Tai Sin stick number'), pins the range 1-100, and clarifies the operation against near-neighbors ('does not draw a random stick or create a personalised reading'). It does not differentiate against the actual siblings (get_reference_sources, get_product_catalog, get_article), which are unrelated, so a 4 rather than a 5.
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?
Gives clear context for when to use it (retrieving an existing/published stick) and an explicit exclusion set: it is not a random draw and not a personalised reading. No alternative tool is named as a substitute for those excluded cases, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.