Token Command Center

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds only the alert taxonomy; it says nothing about freshness window, ordering, whether alerts are deduplicated or acknowledged, or how severity thresholds are applied.

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?

It is a single tight fragment with no filler, and the category list is front-loaded. However, the terseness stems from under-specification rather than disciplined editing — a fragment without a verb leaves the operation implicit.

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 three undocumented parameters, no output schema, and no explanation of what an alert record contains, the definition leaves an agent unable to invoke the tool correctly beyond calling it with no arguments. More detail on filters and the recency window is needed.

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?

All three parameters (limit, token, severity) have 0% schema description coverage and the description explains none of them. There is no hint that severity filters alert types, that token scopes alerts to one asset, or what limit defaults to.

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 (threshold alerts) and enumerates the four alert categories, which lets an agent distinguish it from siblings like tc_brief, tc_calendar, and tc_status. It omits an explicit verb, but the noun phrase clearly implies retrieval of recent alerts.

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?

There is no when-to-use guidance, no statement of what 'recent' means, and no mention of alternatives. An agent cannot tell whether tc_alerts or tc_brief/tc_status should be consulted for a given monitoring question.

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 cover the safety profile (readOnlyHint=true, openWorldHint=false). The description adds genuinely useful non-annotation context: the payload size (~1.5 KB), the fact it is a consolidated snapshot, and the exact content sections, including a plain-text variant. No auth, rate-limit, or freshness mechanics are described, but for a no-arg read-only brief the added detail is solid.

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 compact sentences, front-loaded with the 'whole Book in about 1.5 KB' hook, then the content list, then the usage cue. Every clause carries information; the only minor slack is the trailing 'plus a plain-text version'.

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 zero parameters and no output schema, the description must describe the return payload itself, and it does so by enumerating the sections. It is complete enough for an agent to decide to call it, though it could say more about how current the 'freshness' data is.

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; baseline 4 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?

The description names the resource precisely ('the whole Book') and enumerates the specific sections returned (freshness/caveats, verdict and lens mix, 30-day movers, health, alerts), which distinguishes it from narrow siblings like tc_moves or tc_alerts. It doesn't explicitly name those siblings as alternatives, but the aggregate-vs-single-topic distinction is inferable.

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 for market-wide questions' gives one positive usage condition, which is a reasonable routing hint toward this tool over per-token siblings. However, it offers no when-not-to-use guidance and does not name an alternative tool for narrower questions.

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 readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely useful behavior beyond that: result cap of 20, soonest-first ordering, the 30-day default horizon with a 180 max, and the fact that free text is analyst notes rather than raw data.

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 tight sentences with zero filler, front-loading what the tool returns before covering the optional filters and the nature of the text field.

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 does the work of describing the return shape: capped at 20, sorted soonest-first, text field is analyst notes. Only minor ambiguity remains (what 'the Book' encompasses, how the horizon interacts with the cap).

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 only 50% (the days parameter has no schema description), and the description compensates by stating that days is an optional horizon defaulting to 30 with a max of 180, plus that token is an optional slug filter. That meaningfully exceeds what the schema alone conveys.

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 resource (upcoming dated catalysts) and enumerates the event types (unlocks, emission steps, votes, launches), which lets an agent recognize the tool's domain quickly. It does not, however, explicitly distinguish itself from plausible siblings like tc_alerts or tc_moves, 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?

The description implies the usage context (get upcoming dated events, optionally narrowed by token and horizon) and gives the horizon default of 30 days, but it never states when to prefer this over tc_alerts or other event-like siblings, nor any exclusions.

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 readOnlyHint=true and openWorldHint=false, so the safety profile is covered structurally. The description adds nothing beyond that — no statement about whether counts are global or scoped, no freshness or aggregation semantics, no hints on how categories are derived.

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?

It is a single fragment with no wasted words, but this is under-specification rather than conciseness. It reads as a label rather than a usable description, so it neither bloats nor adequately informs.

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, no parameters, and no annotations beyond safety hints, the description is the only place semantics could live — yet it says nothing about what a 'category' is, what token scope is covered, or how results are shaped. For a zero-arg reporting tool the risk is lower, but the agent still cannot predict the response.

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 the baseline is 4. The description correctly implies no input is required to retrieve category-level counts.

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 fragment 'Token counts per category' identifies the resource (token counts) and a grouping dimension (category), which is more than a pure tautology. However it has no verb, no scope statement, and nothing that distinguishes it from siblings like tc_ledger, tc_series, or tc_status, which are all similarly terse.

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?

There is no when-to-use guidance, no statement of prerequisites, and no reference to any alternative tool. With 15 sibling tools that all touch tokens, the agent gets no help deciding when this one is the right call.

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 readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds some behavioral value by disclosing the frozen-price and old-scorecard flags it surfaces, but says nothing about pagination, rate limits, or missing-data behavior.

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?

Essentially one dense sentence, front-loaded with the comparison scope before the field list, with no filler. The long middle enumeration of fields makes it heavier than necessary but nothing is wasted.

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, so the description carries the return-shape burden; it lists the compared fields but does not explain output structure, the fields filter parameter, or the note that tokens accepts 1 item in schema while text says 2-6.

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 0%, so the description must compensate. It does for 'tokens' — 'slugs or unambiguous symbols' plus the 2-6 range clarifies input format beyond the bare string array — but the 'fields' parameter is never mentioned, so its 27-value enum and 18-item cap are undocumented.

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 concrete verb and resource — comparing 2-6 tokens 'side by side' — and enumerates the dimensions compared (price, valuation, revenue change, holders revenue, net-flow yield, P/S, unlocks, health, verdict, lens, flags). An agent can tell it produces a multi-token comparison, though it never explicitly contrasts itself with single-token siblings like tc_get_token or tc_screen.

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 via 'side by side' and the 2-6 token count; there is no explicit statement of when to pick this over tc_get_token, tc_screen, or tc_brief, and no exclusions or prerequisites are given.

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 readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely new behavioral context — the output is long and therefore 'clipped' (truncated) — which tells the agent to expect partial content, a trait not present in the structured fields.

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 short sentences with the resource front-loaded and the alternative immediately after. The 'clipped' note is slightly cryptic and the phrasing is terse, but there is no wasted text.

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, so the description carries return-value burden; it does gesture at the return (markdown scorecard, newest) and its truncation. Combined with annotations covering the safety profile, an agent has enough to call it, though the slug semantics remain unexplained.

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 0% and the sole parameter (slug) is undocumented in the schema. The description only says 'for a slug,' giving no format, source, or how to obtain it, so it fails to compensate for the coverage gap.

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 resource and format: the newest markdown scorecard for a slug. It names the sibling it overlaps with (tc_get_token), which helps an agent separate the two, though it never states plainly that this is a read/fetch tool.

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 an explicit routing rule: prefer tc_get_token unless the user asks for the write-up. The condition that selects this tool over the alternative is stated directly, 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.

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely useful behavioral context the annotations don't: approximate payload size (~8 KB) and a full inventory of the return contents, which signals this is the heavyweight variant. It stops short of stating auth needs or failure modes, so not a 5.

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, front-loaded with the resource and payload size, then the routing rule. The middle enumeration is long but each item is a distinct return field, so it earns its place; slightly dense but not padded.

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 carries the burden of describing return values and does so thoroughly — pillars, provenance-tagged stat grid, ARR windows, history depth, alerts, conflicts. Combined with the digest routing rule, an agent has everything needed to select and invoke it correctly.

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% and the single slug parameter is documented in-schema with an example ('geodnet'). The description adds no format, resolution, or validation detail beyond what the schema already provides, 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 resource ('one token's full scorecard') and enumerates exactly what it returns (pillar scores, stat grid, ARR change, history, alerts, conflicts). The phrase 'full scorecard' paired with the explicit contrast to tc_get_token_digest lets an agent distinguish it from its closest sibling immediately.

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 final sentence gives an explicit selection rule: 'Use only when tc_get_token_digest lacks what the user asked for.' This names the alternative tool and the condition that selects this one, 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.

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: a payload size budget ('about 1 KB') that signals a compact response, plus the full content inventory, letting the agent predict cost and coverage before calling.

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 core identity ('One token in about 1 KB') then lists contents in one dense clause, closing with the routing directive. Every element earns its place, though the content enumeration is long for a single sentence.

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 carries the burden of describing return values, and it does so thoroughly by naming each field group. It is complete for selection and invocation, with only minor gaps around response format and any staleness/refresh semantics.

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?

Only one parameter (slug) with 100% schema description coverage, so the schema already carries the semantics. The description's phrase 'One token' confirms the single-token scope but adds no format, aliasing, or resolution detail 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?

States a specific verb and resource ('get' a 'token digest') and enumerates exactly what the payload contains: price, valuation, revenue/flows, changes, health score pillars, unlocks, lens, quality counts. It explicitly distinguishes itself from the sibling tc_get_token, so an agent can choose between them without opening either 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?

Names a concrete alternative with a preference directive ('Prefer this over tc_get_token'), which is clear routing guidance. It does not state the reciprocal condition — when an agent would want tc_get_token, tc_get_report, or tc_compare instead — so it stops short of full when/when-not coverage.

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 readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful scope context — that only tallies are exposed and individual calls are withheld — which prevents the agent from expecting per-call records. It says nothing about refresh cadence, coverage window, or whether counts are final versus provisional, so it is solid but not rich.

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. The contents are front-loaded and the limiting clause ('counts only') comes last where it acts as a caveat rather than burying the payload. Every clause carries 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?

With no parameters and no output schema, the description must convey the return shape, and it does by enumerating the tallies. For a simple parameterless read tool this is close to sufficient; a note on how current the tallies are would make it fully self-contained.

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 and the schema is an empty object with additionalProperties false, so there is nothing for the description to explain. Baseline 4 applies: no parameter semantics are required.

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?

Names a specific resource (prediction ledger tallies) and enumerates exactly what it contains: open and graded call counts, next grading date, calls by side. A verb is absent but the read-only aggregate nature is unambiguous. It does not name a sibling like tc_get_report or tc_status to sharpen the boundary, 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?

Usage is only implied: an agent infers this is the tool for aggregate counts rather than per-call data. 'Counts only; individual calls are not published' usefully closes one path, but there is no explicit when-to-use statement and no named alternative among the sixteen siblings that also serve reporting-style data.

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 declare readOnlyHint=true and openWorldHint=false, which the description correctly does not contradict. However, it adds essentially nothing beyond that: no mention of pagination limits, default page size, sort direction default, or what a 'scored token' or tier/verdict means in behavioral terms.

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 short sentences, front-loaded with the action and immediately followed by the sort options. Efficient, though the sort list duplicates the schema enum rather than adding 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?

An 8-parameter list tool with 25% schema coverage, no output schema, and no description of pagination behavior or filter semantics. The description omits far more than it includes for an agent to invoke it correctly.

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 only 25%, so the description must compensate, but it only restates the sort enum already in the schema. Tier, category, limit (max 100), offset, descending, verdict, and query semantics are left undocumented or ambiguous (e.g., is sort ascending by default? what is tier?).

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+resource ('Page through scored tokens') with scope qualifier 'optional filters' and enumerates the sort axis. It is distinguishable from sibling tc_search_tokens in that paging/listing is the core action, though the boundary with tc_screen is not addressed.

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 context is implied by 'optional filters' and the sort list, but it never says when to choose this over tc_screen, tc_search_tokens, or tc_get_token, nor what the filters actually filter on. No exclusions or alternatives are named.

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 cover the safety profile (readOnlyHint=true, openWorldHint=false), yet the description adds substantive behavioral context: the ranking methodology for each mode, the output cardinality cap (up to 8 up and 8 down), and the meaning of the base_effect row flag. That is real disclosure beyond the structured fields.

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 dense sentences with the headline purpose front-loaded, followed by the two mode definitions and the output/edge-case notes. No filler; every clause conveys information the agent needs.

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 single optional enum parameter with no output schema, the description is nearly complete: it explains both modes, the row count limits, and the base_effect caveat. The only missing piece is what happens when kind is not supplied.

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 0%, so the description must carry the enum semantics, and it does: it defines kind=movers as a 30-day revenue-change vs price-change divergence rank and kind=momentum as a 14-day composite of revenue, net-flow yield and health changes. It omits the default behavior when kind is omitted (the parameter is not required), a minor gap.

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 states a specific resource ('Biggest movers') and then precisely defines the two ranked views the tool produces, so an agent knows exactly what it returns. It does not name or contrast any sibling tool, which keeps it just short of a 5, but the purpose is unambiguous.

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 explains what each kind value means and when each ranking is appropriate (30-day revenue vs price divergence for movers, 14-day composite for momentum), which is useful selection guidance for the one parameter. However, it gives no guidance on when to call this tool versus siblings like tc_screen, tc_compare or tc_series, and no prerequisites.

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 readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the exact vs ambiguous=true return contract and the explicit instruction never to guess between colliding symbols. It omits any note on the limit parameter's effect or failure behavior for unknown queries.

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 core transformation, then the ambiguity contract, then the usage trigger. No filler and each sentence adds 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?

With no output schema, the description correctly takes on the burden of describing return values (single slug vs ambiguous flag with candidates). It is nearly complete for a 2-param read-only resolver, with only the limit parameter left unexplained.

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 carry parameter meaning. It does explain what the query accepts (symbol, $cashtag, name, slug), which is genuinely additive over a bare string, but the limit parameter (1-10) is never mentioned anywhere.

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 (resolve/turn into) and resource (Token Command Center slugs) and enumerates accepted input forms (symbol, $cashtag, name, slug). This clearly separates it from siblings like tc_get_token or tc_search_tokens, which retrieve rather than normalize identifiers.

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?

"Call before a digest when the user names a token" gives a concrete trigger tied to a named sibling workflow (tc_get_token_digest). It also tells the agent what to do on ambiguity (don't guess, surface all candidates), but it never names an alternative tool for cases where resolution fails.

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 cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description adds real behavior: ranged filters exclude tokens with no value rather than treating them as zero, health is a 0-100 score set when the scorecard is written, and verdict encodes value accrual classes. It does not discuss ranking/pagination behavior, so it is strong rather than exhaustive.

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 and the return shape, then organizes the rest into 'Filters:' and 'Fields:' blocks so the dense content is navigable. The field glossary is long, but because there is no output schema each entry adds meaning that the bare enum in the schema does not.

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 13-parameter, no-required-argument screening tool with nested min/max objects and no output schema, the description covers filter usage, field meanings, and the null-handling rule. The main residual gap is ranking and result-window behavior, which the limit/order/sort parameters imply but the text does not state.

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?

With schema description coverage at only 23% and 13 parameters, the description carries the load by explaining the min/max range object with a worked example, the value sets for lens and verdict, comma-separated flow_model, and how each field is measured. It omits explicit semantics for sort, order, and limit, which remain inferable only from 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?

States a specific verb and resource ('Screen the whole Book') plus the return shape ('compact ranked rows'), and the parenthetical '(all scored tokens)' scopes it against the listing/search siblings. An agent can tell this is the full-book screener rather than a single-token lookup or a text search.

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 filter mechanics — enumerated lens/verdict values, comma-separated flow_model, stale, query substring, and a min/max range example — so the agent knows how to drive the screen. It never states when to prefer this over tc_list_tokens or tc_search_tokens, so it stops short of explicit alternative routing.

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 readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds nothing beyond that: no note on result ordering, match behavior, or how the limit interacts with result count. It does not contradict the annotations.

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?

A single front-loaded sentence with no filler, and the purpose plus the workflow hook are stated first. It is appropriately sized for a two-parameter lookup tool.

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 simple read-only search with annotations covering safety, the description is nearly adequate, but the undocumented limit semantics and unspecified match behavior leave the agent guessing on output size and precision.

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 carry the load; it partially does by clarifying that 'query' accepts a symbol or a name. The 'limit' parameter (1-50) is not explained anywhere, and the match semantics (exact vs partial) remain unstated.

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 states a specific verb and resource ('Find slugs by symbol or name') and names the downstream tool it feeds (tc_get_token_digest), which separates it from list-style siblings like tc_list_tokens. It is clear, though it doesn't explicitly contrast with tc_list_tokens or tc_get_token.

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 implies usage as a prerequisite lookup before tc_get_token_digest, which is useful workflow context. However, it gives no when-not guidance and doesn't explain why an agent would search here versus calling tc_list_tokens directly.

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?

With annotations only covering readOnlyHint/openWorldHint, the description carries real behavioral load: at most 60 points returned, weekly interval default, summary-first payload shape, snapshot start date, and the critical null-vs-flat semantics for frozen price feeds. This is exactly the kind of disclosure annotations cannot provide.

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 resource and the summary-first return contract before the long metric enumeration, and every clause does work. The single dense paragraph with stacked parentheticals is slightly hard to scan but not wasteful.

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 no output schema and sparse schema descriptions, the description supplies the return structure (summary stats then points), point-count and interval defaults, and null handling — enough for an agent to call it and interpret results correctly.

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 only 25%, so the description must compensate, and it does partially: it explains the metric families, provenance of daily_*/price_llama, and that interval defaults to weekly. It leaves range values (30d/90d/1y/all) and the maxItems=6 cap on metrics unexplained.

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+resource ('one token's history as chartable series') and names the data source (TCC daily snapshots), which cleanly separates it from point-in-time siblings like tc_get_token. It never names a sibling explicitly, so the differentiation 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?

Gives clear usage direction: 'answer trend questions from it' via the summary block, and notes the metric provenance split so the agent knows which series are deep vs snapshot-limited. It stops short of stating when NOT to use it (e.g., for a current single value, use tc_get_token).

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 readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that the payload reports freshness, size, and source-agreement, plus that generated_at should be quoted, but with no output schema it does not describe the stat structure or freshness semantics in depth.

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 tight, front-loaded sentences: the first names the payload, the second gives the action directive. No filler, and the most important instruction ('Call first') is prominent.

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 zero-param, zero-annotation-ambiguity status tool with no output schema, the description covers what stats come back and the key field to surface. It stops short of explaining what 'source-agreement' or 'freshness' numerically mean, a minor 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?

The tool takes zero parameters, so there is nothing for the description to document and the baseline of 4 applies. The absence of arguments is consistent with a parameterless status call.

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 resource and the data it returns: 'Freshness, size and source-agreement stats of the token universe.' An agent can tell this is a status/metadata tool distinct from retrieval siblings like tc_get_token or tc_list_tokens, though it doesn't explicitly name what sets it apart from tc_brief or tc_ledger.

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?

'Call first' is explicit sequencing guidance that tells the agent when to invoke this relative to other tools, and 'quote generated_at' directs downstream use of the output. There is no explicit when-not or named alternative, but the usage context is clear.

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