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

Annotations already cover the read-only, idempotent, non-destructive profile, and the description adds substantial value beyond them: the 1-credit-per-call cost, the raw-metrics-not-reputation nuance with the signal in the ratios, and the full deprecation lifecycle with a concrete removal date and migration path. This is exactly the behavioral context an agent needs to decide whether to rely on this tool.

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 description is front-loaded with purpose, then cost, usage, return interpretation, and lifecycle in logical order, and each sentence carries non-redundant information. The legacy sentence is slightly wordy — 'it still works today and keeps working until...' repeats the same idea — but the overall density-to-length ratio is strong.

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-parameter, read-only tool with a documented output schema, the description covers everything needed to call it correctly: cost, safety (via annotations), usage context, return semantics, deprecation status, and a migration alternative. Nothing an agent needs to decide or invoke 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 coverage is 100%, and the schema fully documents the single username parameter including the with-or-without-@ format, so the description need not repeat it. The description's mention of 'an X account' reinforces the parameter's role but adds no format or semantics beyond the schema, matching the baseline of 3 for high schema coverage.

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 opens with a specific verb-resource pair — 'follower and engagement stats for an X account' — and clarifies the output is raw metrics rather than a reputation score. It also differentiates from the closest sibling by directing new work to mentions with mode=search, which returns posting accounts alongside engagement metrics, so an agent can classify this tool without opening its 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?

Explicit usage context is given: 'use it to judge whether an account's reach is real before weighting what it posts.' The description also states when NOT to use it — it is legacy, removed on 28 October 2026, and not being extended — and names the exact alternative (mentions with mode=search), 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, idempotentHint, and destructiveHint. The description adds valuable context by noting the tool is 'Free' and that it 'confirm[s] the API is reachable,' going beyond the structured annotations. No contradiction exists.

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 description is two sentences: the first states the purpose, the second gives usage guidance. It is front-loaded, concise, and contains no redundant or filler content.

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?

Given the empty input schema, an existing output schema, and strong annotations, the description fully covers the tool's purpose, when to use it, and its cost ('Free'). There are no missing critical details for a zero-parameter status check.

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 has exactly zero parameters, and the schema coverage is 100% by default. There is nothing for the description to add regarding parameters, so a baseline score of 4 is appropriate.

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 uses a specific verb 'Check' and clearly names the resource: 'Elfa API key tier, credit usage and remaining requests, and confirm the API is reachable.' This distinguishes it from sibling data-related tools and leaves no ambiguity about what the tool does.

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 provides explicit usage guidance: 'Call this first when a request fails with an auth or credit error.' This is clear context for when to use the tool, but it doesn't mention when-not to use it or name alternative tools, though none are obvious given its diagnostic role.

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?

Discloses cost (1 credit plus LLM usage) and side-effect-free nature ('nothing starts running until you activate it'), which complements the readOnlyHint=true annotation. The draft-only behavior is critical for agents to know it won't execute anything and aligns with the annotation's safety profile.

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 sentences, each serving a distinct purpose: purpose, cost/side-effect, and input guidance. No filler, tautology, or redundant repetition of schema information. Front-loaded with the core functionality.

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?

Given the output schema and annotations, the description covers essential behavioral context: cost, draft-only nature, and activation requirement. It also provides enough input guidance for an agent to construct a valid request. Nothing critical 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 already covers all parameters with descriptions (100% coverage), so a baseline of 3 applies. The description adds value by specifying what to include in 'message' (what to watch, threshold, action), enriching the primary parameter's semantics. Speed and sessionId are adequately documented in 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?

Clearly states it converts plain-language monitoring requests into EQL queries, a specific verb+resource pair. The phrase 'only drafts the query' distinguishes it from activation tools like auto_query_write, removing ambiguity about its scope.

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?

Explains when to use it: for drafting a query, not running it, and explicitly directs activation to auto_query_write. Provides input guidance (what to watch, threshold, action). However, it does not explicitly contrast with sibling tools like auto_query or auto_draft, leaving some potential for confusion.

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 provide destructiveHint=true and readOnlyHint=false, but the description adds critical behavioral nuance: drafts are non-evaluating, non-firing, and free except for method=convert which activates and incurs cost. This goes well beyond the annotations and materially informs invocation decisions.

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 sentences deliver purpose, behavioral rules, and usage guidance with no filler. The most important information is front-loaded, and every sentence 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?

The tool has 9 parameters, nested objects, and an output schema; the description covers the essential decision-making points (what a draft is, when to use it, cost caveat). The rich schema handles parameter details, and the output schema covers return values, leaving only the need for a bit more explicit workflow guidance (e.g., 'build and validate first') which the schema itself hints at via query description.

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%, so all parameters have descriptions. The tool description adds a cost implication for method=convert but does not otherwise elaborate on parameter relationships or formats. With full schema coverage, a baseline of 3 is appropriate.

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 opens with 'Park an Auto query without activating it,' a specific verb+resource that clearly states the tool's core function. It further distinguishes itself from live query tools by noting 'Drafts never evaluate and never fire,' making the purpose unmistakable and distinct from siblings like auto_query.

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 gives explicit usage context: 'Use drafts when the user is still deciding.' This tells the agent when to choose drafts over live queries, though it does not explicitly name alternative tools. The cost caveat for method=convert also serves as a conditional usage warning.

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, idempotentHint, and destructiveHint, so the safety profile is known. The description adds valuable behavioral context beyond annotations: it's free, there is no push channel (requires polling), and it mentions pollAfterSeconds for rate/interval respect. This enriches understanding of how to interact with the tool.

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 description packs all necessary method semantics into three concise sentences. It front-loads the essential purpose ('Read side of Auto'), uses a clear list-like enumeration for methods, and closes with critical polling behavior. No word 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?

With 9 parameters, 6 methods, and a rich output schema, the description covers all method categories and the key interaction pattern (polling). It omits some details about pagination or filters, but those are fully documented in the schema. The overall tool behavior is sufficiently clear for an AI agent to use 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 coverage is 100% with descriptions for all 9 parameters, so the baseline is 3. The description adds value by linking methods to parameter usage (e.g., method=get polls one query, method=execution shows a specific execution, method=session requires sessionId). This helps select the right method and understand which parameters matter per method, going slightly 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 clearly identifies this as the read side of Auto and enumerates each method with its specific purpose (list browses queries, get polls one query, executions/execution show fired items, sessions/session return LLM analysis). It explicitly positions itself as read-only, distinguishing it from write/sibling tools like auto_query_write.

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 gives concrete guidance: 'Read side of Auto' implies use for reads rather than writes, and 'no push channel here, poll with method=get' explicitly tells the agent to use polling instead of expecting push. It also directs respecting pollAfterSeconds. It could be more explicit about when to use this over siblings, but the context is clear.

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?

Beyond the annotations' destructiveHint=true, the description discloses key behavior: creating costs 5 credits plus LLM usage, and an activated query runs unattended and fires without asking again. This is crucial side-effect information. Minor additional detail, such as what exactly gets destroyed on delete, is left to the schema, but the critical behavior is covered.

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 description is three sentences, each earning its place: the operation, the cost model, and the unattended-fire warning with the required user confirmation. It is front-loaded with the action and wastes no words.

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 write tool with an output schema and rich annotations, the description covers everything needed to invoke it correctly: operation set, cost, unattended behavior, validation prerequisite, and user-confirmation requirement. The conditional parameter detail (queryId for cancel/delete) is already in 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 description coverage is 100%, so the schema already documents each parameter. The description adds workflow context by telling the agent to build the query with auto_build and validate it, but it does not add parameter-specific semantics beyond what the schema provides. Baseline 3 is appropriate.

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 opens with a specific action set — 'Activate, cancel or delete an Auto query' — naming both the verb and the resource. This clearly differentiates the tool from siblings like auto_build, auto_validate, and auto_query, which construct, validate, or read rather than write.

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 gives explicit workflow guidance: build with auto_build, check with auto_validate, and confirm cost and the action with the user before calling. It also distinguishes create from cancel/delete and calls out the cost difference. It stops short of explicitly stating 'when not to use this tool,' but the prerequisites are unambiguous.

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?

The description discloses that the tool is free and provides a cost estimate, adding operational detail beyond the annotations (readOnlyHint, idempotentHint, destructiveHint). It implies a non-destructive dry-run by saying 'before anything is activated.' No contradiction with annotations; the description adds useful context without repeating 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?

The description is composed of three sentences that front-load the primary purpose and cost estimate, then provide workflow guidance and the two modes. It is reasonably concise but could be more structured (e.g., separating the symbol mode sentence). The essential information is present without excessive verbosity.

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?

Given the tool's complexity (7 parameters, parameter dependencies, and a rich output schema), the description covers the primary workflow, the symbol mode, and the integration with auto_query_write. It does not explicitly describe error handling or return format, but the output schema likely covers that. Overall, it is complete for an agent to call 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?

The description explains the relationship between parameters: 'Pass either an inline query or a draftId' and that method=symbol requires symbol and exchange. This supplements the schema's individual field descriptions, which already have 100% coverage. The description adds usage logic, especially for the method-dependent parameters, going beyond baseline.

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 clearly states the tool's function: 'Check EQL syntax and get a cost estimate before anything is activated.' It distinguishes itself from the sibling auto_query_write by noting it should run first, and describes the alternative symbol method. This provides a specific verb and resource, making the purpose 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?

Usage is explicitly guided: 'Always run this before auto_query_write' and 'show the estimated cost to the user.' It also explains when to use method=symbol (to check symbol support before building conditions). This gives concrete when-to-use instructions and contrasts with the write operation.

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?

The description discloses meaningful behavioral traits beyond the annotations: using this tool costs credits, speed and cost are linked with fast being cheaper, and sessionId enables a continued conversation. It is consistent with readOnlyHint=true and adds useful context around pricing and stateful conversation.

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 description is two sentences, front-loaded with the main purpose, and then covers cost/speed and session continuation in a compact way. Every sentence earns its place without unnecessary detail.

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?

Given the 100% schema coverage and the presence of an output schema, the description covers the essential interaction model: ask a question, choose a speed, and optionally continue a session. It doesn't enumerate all analysisType variants or alternatives, but the schema handles those details, so the description 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?

Schema coverage is 100% and each parameter already has a description. The tool description adds value by clarifying that speed directly affects cost ('fast is the cheaper option') and that sessionId carries over a previous conversation, which are not obvious from the schema alone.

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 says 'Ask Elfa for written market analysis grounded in its social data,' which names a specific verb ('ask'), a resource ('Elfa'), and a clear deliverable ('written market analysis'). It also differentiates from sibling tools by emphasizing 'grounded in its social data' and the written/market-analysis nature.

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 usage for asking market-analysis questions, and it offers useful context about cost/speed and continuing conversations via sessionId. However, it does not explicitly state when to use this tool instead of siblings like account_stats or narratives, nor does it give 'when not to use' 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?

The description adds valuable behavioral context beyond the annotations (readOnlyHint, idempotentHint, destructiveHint all true/false). It discloses the 1-credit cost, specifies that it returns engagement metrics and links rather than post text, and clarifies that news mode returns X posts from tagged news accounts, not traditional articles. This is rich, non-contradictory context.

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 description is compact and information-dense, front-loading the core purpose, then cost, return structure, and mode explanations. Every sentence earns its place, and there is no redundancy or filler. It is well-structured and easy to parse.

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?

Given the tool's complexity (15 parameters, 3 modes) and the existence of an output schema, the description covers the essential decision points: modes, cost, return limitations, and the nuanced nature of news mode. Some parameter interactions (e.g., timeWindow, searchType) are left to the schema, but that is appropriate. It is nearly complete for an agent to call 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%, so the schema already documents all parameters and their meanings. The description adds no new parameter-level semantic detail beyond what the schema provides; it only clarifies the behavior of mode=news and the general return format. This meets the baseline for full schema coverage without surpassing it.

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 clearly states the tool's function: it retrieves social mentions from X and Telegram, with three distinct modes (top, search, news) explained. It differentiates itself from sibling tools by focusing specifically on mentions, and the description names the sources and what it returns, making the purpose unmistakable.

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 provides clear usage context for each mode (top ranks by engagement, search filters by keywords/account, news returns a news-sourced feed), which effectively guides the agent on when to use which mode. However, it does not explicitly compare this tool to alternatives or state when not to use it, so it falls short of a perfect score.

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 indicate read-only, idempotent, and non-destructive behavior. The description adds valuable context: the cost of '5 credits per call' and the warning that scope=keywords 'can take over a minute to return', which are not captured in 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?

Three sentences, each earning its place: purpose, cost/alternative, and scope explanations. Front-loaded with the core purpose, and no fluff or redundancy.

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?

Despite having 9 parameters with no required fields, the description covers the key decision points: when to use qualitative analysis, the cost, the two scope behaviors, and latency expectations. The rich schema and output schema handle the remaining parameter and return details, so the description is complete for the agent's needs.

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%, so the baseline is 3. The description adds semantic nuance for the main scopes—'market extracts the narratives moving the market' and 'keywords summarises events'—which goes beyond the schema's brief 'broad sweep' and 'needs the keywords argument'. This adds meaningful context for parameter selection.

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 clearly states the tool provides 'Written narrative analysis with source links', distinguishing it from count-based tools like trending and mentions. It also differentiates between the two scopes (market and keywords), giving specific verbs and resources for each.

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?

Explicitly says 'for when counts are not enough' and 'prefer trending or mentions when metrics will do', providing clear when-to-use and when-not-to-use guidance. It also explains the distinction between market and keywords scopes, including the latency caveat for keywords.

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?

Adds a credit cost per call, which is not in the annotations, and details scope-specific return behavior (ranked by mention volume, change against previous window, contract addresses). This supplements the readOnlyHint and idempotentHint annotations with practical behavioral context.

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 description is compact: three sentences that front-load the purpose and cost, then clearly map the scope options to their outputs. No filler or redundant restatement of the tool name or schema.

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?

Given the full input schema, output schema, and annotations, the description covers the essential behavioral aspects: cost, scope variants, and output type. It lacks explicit pagination/filtering guidance, but those are already documented in the schema, so the overall package is complete enough for an agent to select and invoke the tool 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 100%, so the baseline is 3. The description enhances the scope parameter by explaining what each enum value returns (tickers vs contract addresses) and introducing the notion of 'change against the previous window', adding semantic value beyond the schema's simple enum listing.

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 clearly states the tool returns what is gaining social attention, with explicit scope variants: tokens ranked by mention volume with change, and contract addresses for Twitter/Telegram. It uses a specific verb ('returns') and identifies the resource (trending tickers/contracts), distinguishing it from sibling tools like mentions or narratives.

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 usage for surfacing trending social attention, but it does not explicitly contrast with alternatives such as mentions or narratives, nor does it state when not to use this tool. The scope explanations provide parameter-level guidance, but not tool-selection guidance.

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