This key: plan, per-second/per-minute/per-day limits, SSE entitlement and usage so far today. Costs no API quota. Use it to explain a 429 or a 401 to the user, and to tell them which limits they are actually on — the demo bucket is shared across every demo caller, so it can be spent by someone else. Not a billing or payment-history endpoint.
| 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?
Annotations include readOnlyHint=true, but the description adds critical behavioral context: it costs no API quota, the demo bucket is shared across callers so usage can be affected by others, and it provides usage so far today. These details are not captured by the annotation and are essential for correct interpretation of results.
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 compact, with two sentences, but the first sentence is telegraphic and slightly awkward ('This key: plan...'). Still, it is front-loaded with the core purpose and contains no wasted words. It could be more elegantly phrased, but it is efficiently structured.
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 no parameters, no output schema, and a single readOnly annotation, the description provides comprehensive context: what it returns, when to use it, behavioral caveats (shared demo bucket), and what it is not. An agent can fully understand the tool's purpose and limitations without additional information.
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 there is nothing for the description to explain. Per the rubric, the baseline is 4 for 0 parameters. The description adds no param-related details, which is appropriate since there are none.
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 exactly what the tool returns: plan, per-second/per-minute/per-day limits, SSE entitlement, and usage so far today. This is a specific resource (plan limits) and distinguishes it from sibling tools like get_live_odds or list_sports which deal with odds and sports data. The mention of 'Costs no API quota' further clarifies its nature.
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 explicitly says when to use it: to explain 429 or 401 errors to the user and to tell them which limits they are on. It also provides a negative use case ('Not a billing or payment-history endpoint'), giving clear exclusions. This goes beyond implied usage and provides actionable guidance.
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.