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

With no annotations at all, the description carries the full burden, and it does disclose two genuinely useful behaviors: a free tier metered by a daily per-caller quota, and that payment/authorization goes in MCP HTTP headers (X-Payment / X-Payment-Tx / Bearer fg_…) rather than in parameters. However, it repeatedly labels the offering 'free' while simultaneously describing an authenticated paid flow, which leaves the agent unsure whether a call will succeed without payment; it also says nothing about what happens when the quota is exhausted.

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 text is three overlapping blocks (free-tier field list, then zh vendor-asset line, then en vendor-asset line, then a payment note) that repeat the same argument list twice in two languages. The most important routing fact — that this is the free summary card — is buried under the quoted user phrasing and the vendor-asset framing rather than front-loaded.

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?

There is no output schema, so the description usefully enumerates the returned fields, which is the strongest part of the definition. But with zero annotation coverage and undocumented parameters, a reader still lacks the protocol identifier format, the meaning/default of days, and a clear free-vs-paid boundary — gaps that matter for a tool sitting directly beside protocol_dossier.

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, and it largely does not. It only restates the names ('参数 protocol / days 可选'; 'Args: protocol, days') and even implies both are optional, whereas the schema marks protocol as required. Nothing explains whether protocol takes a name, slug, or address, nor what window 'days' controls for the 7d change figure.

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 does name the concrete outputs of the free tier (protocol name, slug, category, current TVL, 7d change, chain count, risk flags), which gives a real sense of the resource. But it muddles the picture by re-describing the paid 'protocol multidimensional profile (TVL/fees/hack history)' asset in the same breath, and by using the trigger phrase 'give me a dossier' for a tool whose sibling is literally protocol-profile.protocol_dossier. An agent cannot tell cleanly whether this or protocol_dossier is the dossier.

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?

Usage is only implied: the Chinese phrase '看个大概够用了' (good enough for a rough overview) signals this is the lightweight tier, and the free/per-caller daily quota hints at a cost boundary. There is no explicit 'use protocol_dossier instead when you need X' routing, and no stated prerequisites beyond the quota note, so the agent must infer the split from the sibling list.

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