Discover Tokens

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

Annotations only declare readOnlyHint and openWorldHint; the description goes well beyond by identifying it as a search endpoint, enumerating the returned fields (mint, symbol, name, decimals, asset class), and warning about impersonation and the 1000x decimals pitfall. Nothing contradicts the annotations and substantive behavioral context is added.

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?

Front-loaded and every sentence is doing work: identity first, then usage, then the mint-address warning, then the decimals caveat. The all-caps emphasis (WORDS/MINTS, DECIMALS) is slightly loud, and the decimals paragraph is adjacent rather than core, but it is short and earns its place.

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?

No output schema exists, and the description compensates by listing the returned fields. With annotations covering the read-only/open-world profile and only two parameters, the definition is nearly complete; the lone gap is that query's format expectations are shown only by example and assetClass is left to the schema.

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 50%: assetClass is documented in the schema, but query has no schema description. The description's examples ('AI tokens', 'DePIN', 'something like JUP') usefully convey that query accepts fuzzy natural-language terms — value beyond the bare string type — but it never mentions the assetClass filter or its enum values. Partial compensation, so baseline 3.

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 — 'Turn WORDS into MINTS via Jupiter (GET /assets/search)' — and makes the resource's role unambiguous. It is clearly distinguishable from siblings like get_token_price or swap, and the 'this is where any basket idea starts' framing pins the tool's scope precisely.

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 explicit when-to-use context ('Any basket idea — "AI tokens", "DePIN", "BONK"') plus hard when-not rules ('never type a mint from memory', 'always resolve a pasted one first'). It also names the failure mode (ticker collisions, impersonation) that motivates the guidance, leaving nothing to inference.

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