upc_card_balance

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds genuinely new behavior: no auth session is needed, identity inputs are rejected, and history is never returned. That last point usefully sets expectations about result shape. The mild tension with openWorldHint=true (the text stresses "locally configured") is not a contradiction, just an under-explained boundary.

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, front-loaded with the action and resource, then prerequisites and exclusions. The two negative-scope sentences overlap slightly ("no WeChat or CAS session" vs. "does not accept ... cookie or headers") but each carries distinct 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 no-argument read tool this covers access requirements and the no-history constraint well. With no output schema, however, it never hints at the response shape beyond "balance in CNY" — e.g. whether a card number, status, or timestamp accompanies the amount — leaving a modest 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 description coverage is 0% for the single session_ref parameter, but the schema pins it to const "self", so the description's framing of a "locally configured user" does explain what that value means. It never names session_ref explicitly or says to omit it, so it adds only partial meaning beyond the schema.

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 pairs the specific verb "Read" with the specific resource "campus-card balance in CNY" and scopes it to "the locally configured user." No sibling tool covers card balance, so an agent can pick this one without opening any schema.

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?

It positively states the prerequisite ("requires only the local self profile; no WeChat or CAS session") and negatively scopes out inputs ("does not accept a student number, URL, cookie or headers"), which tells an agent not to try passing identity arguments. It does not name an alternative sibling to use when the local profile is absent, which keeps it 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.