Chain of Title

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds the useful context that this returns metadata (counts, date ranges, venues, licensing) rather than launch records, but says nothing about response shape, size, or freshness beyond the annotations. Adds some value, but modest against an already-covered annotation set.

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?

Two sentences, both load-bearing: the first defines the payload, the second defines the call condition. The content categories are front-loaded with no filler or restatement of the title.

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 carries the burden of describing returns, and it does so by enumerating the coverage dimensions an agent will receive. It stops short of describing format or granularity, but for a parameterless read-only metadata call this is close to complete.

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 takes zero parameters, so there is nothing for the description to disambiguate; the schema coverage signal of 100% on an empty object is consistent with that. A 0-parameter tool sits at the baseline of 4 by the stated rule.

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 names the resource (the register's coverage figures) and enumerates exactly what those figures contain: launch counts, start date, venues, and free-vs-licensed breakdown. It is clearly distinct from the sibling lookup_launch and search_ticker_or_name tools, which retrieve launches rather than register metadata. It is a noun-phrase description rather than an explicit verb+resource, which keeps it just short of a 5.

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?

"Use this to state the basis of any answer drawn from the register" gives a concrete when-to-use trigger tied to grounding answers in provenance. It does not explicitly name alternatives or state when-not to use it, so it falls short of full routing guidance.

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

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

Goes well beyond the readOnly/idempotent/destructive annotations: it enumerates what the record captures at creation, frames findings as 'observations only, never a verdict,' and warns that a not-observed result is an absence and never evidence of safety. It also states the citation requirement, which is a real usage obligation.

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-loads the purpose, then the return contents and caveats, with no filler sentences. The return-value enumeration is long but each element earns its place since no output schema exists.

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 read-only single-parameter tool with no output schema, the description covers purpose, return contents, and interpretation caveats adequately. The only gap is explicit routing against the two sibling tools, which is left implicit.

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 single mint parameter is fully documented (base58, 32-44 chars), so the schema does the heavy lifting. The description adds no format or constraint detail beyond what the schema already provides.

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 ('Look up one Solana token launch in the Chain of Title register by its mint address'), and the lookup-by-mint framing implicitly separates it from search_ticker_or_name. It never names the siblings explicitly, so the contrast is inferable rather than stated.

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?

No direct when-to-use or when-to-prefer-search_ticker_or_name guidance. The 'not observed' caveat and the citation instruction imply context, but an agent must infer that lookup requires a known mint whereas the sibling searches by ticker/name.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds real behavioral context beyond that: identity is 'free to copy', one name maps to many mints and many wallets, and the result is delivered as dated observations with a count and recent launches.

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?

Two sentences, no filler, with the core operation front-loaded and the payoff (count, wallets, recent launches) stated up front. Dense but every clause 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?

With no output schema, the description takes on the burden of describing returns (count, wallets behind it, recent launches as dated observations) and does so adequately for a two-parameter read search. Nothing essential for calling 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 description coverage is 100% with an enum on kind, so the schema already documents both parameters fully. The description's discussion of name/ticker reuse is conceptual context rather than parameter syntax or format detail, so the baseline 3 applies.

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 (search) and resource (the register of launches by ticker or name) with clear scope: 'every launch that carried a ticker symbol or a launch name'. It does not explicitly differentiate itself from the sibling lookup_launch or archive_status, so it stops short of a 5.

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 concrete usage contexts ('whether a token by some name has launched before, or how many times a ticker has been reused'), which clearly frames the intended questions. It never states when NOT to use it or names an alternative sibling, so no exclusions are provided.

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