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

No annotations are provided, so the description carries the full disclosure burden. It reveals non-obvious traits: the call is free ("Costs nothing"), it returns recent usage and a purchase link, and it supports a preferred bearer-token authentication pattern. It does not explicitly state side-effect status, but "check" strongly implies a read operation.

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 and front-loaded: purpose, then value (cost/returns), then auth guidance. The Chinese sentence duplicates the English purpose but is short and may serve bilingual users; it is minor redundancy rather than significant waste.

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 zero required parameters, no output schema, and one unrelated sibling, the description is complete. An agent knows what the tool returns, that it is free, how to supply the key, and the preferred auth path. No critical information needed to invoke it correctly is missing.

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 100% and the license_key parameter already has a regex pattern and description. The tool description adds value by explaining that the key is optional if already configured in the client auth header, which is essential for deciding whether to pass it. This goes beyond the schema alone.

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 and resource: "Check the remaining formatting credits for a Narracore license key." It clearly distinguishes from the only sibling, format_screenplay, by focusing on account/credit status rather than formatting operations. It also mentions the return contents (recent usage, purchase link), making the tool's purpose 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 description gives concrete operational guidance: the tool is for checking credits and usage, costs nothing, and the preferred auth method is setting the key in the MCP client header rather than passing it in chat. It does not explicitly discuss when-not-to-use or alternatives, but there is no meaningful competing sibling for this purpose, so the context is clear enough.

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