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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and mutation behavior. The description adds the credit cost ('1 credit per call') and intended usage, which is helpful but does not disclose what specific stats are returned or any rate limits. With annotations carrying the core safety profile, this level of added context is adequate but not exceptional.

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 with zero wordiness. It leads with the core function, then states the use case and cost. Every word earns its place, making it concise and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With only one well-documented parameter, an output schema present, and strong annotations, the description covers the essential aspects: what, when, and cost. There's no need to detail return values since the output schema handles that. For its simplicity, the description is complete and self-sufficient.

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 single parameter 'username' is fully documented in the schema with 'X username, with or without the @' (100% coverage). The description adds no additional semantic meaning beyond the schema, so the baseline of 3 applies. No param-related gaps to compensate for.

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 'follower and engagement stats for an X account', giving a specific verb-resource pairing. It distinguishes itself from sibling tools like mentions or trending by focusing on account-level metrics. The word 'smart' adds a minor marketing tone but doesn't obscure the core purpose.

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 a concrete use case: 'Use it to judge whether an account's reach is real before weighting what it posts.' This provides clear context for when to apply the tool, but it does not explicitly mention alternatives or when not to use it. A 4 is appropriate because the context is clear, but exclusions or sibling comparisons are missing.

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?

Goes well beyond the destructiveHint annotation by detailing that connections change what Auto can trade, requires user confirmation and request signing, and warns that credentials pass through the conversation and are written to the client transcript. This is actionable and important context not captured in structured 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?

The description is dense but every sentence contributes value. It could be slightly more structured for scannability, but it stays on-topic and front-loads the core purpose.

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 complexity of six parameters and nested objects, the description covers the key behaviors, constraints, and user-facing cautions. It does not detail list/disconnect outcomes, but an output schema exists and the description covers the main pitfalls.

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 baseline is 3. The description adds meaningful context for the credentials parameter (verification on connect, transcript exposure) and clarifies validate_symbol behavior, but other parameters remain adequately covered by 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 clearly identifies the tool as managing exchange accounts used for trading and enumerates the specific methods (validate_symbol, list, connect, disconnect). It distinguishes itself from sibling tools by focusing exclusively on exchange connections.

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?

Provides explicit usage guidance: use validate_symbol before building a query, use list for hyperliquid/gmx instead of connect, and confirm with the user before connecting/disconnecting due to trading impact. It also mentions request signing as a prerequisite.

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 destructiveHint annotation, the description discloses credit costs, unattended execution with automatic action firing, and the need for request signing on order actions. These are critical behavioral traits that an agent must know before invoking, and they add significant value over 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 with no filler. It front-loads the core action, then adds cost, safety, and special-case information efficiently. 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?

Given the tool's complexity (5 params, nested object, output schema), the description covers all essential context: cost, prerequisites, unattended behavior, confirmation requirement, and order signing. The output schema handles return values, so 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 description coverage is 100%, so all parameters already have detailed descriptions. The tool description does not add extra parameter-level meaning; it only references the validation workflow. Baseline 3 is appropriate since the schema does the heavy lifting and no gaps remain.

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 with specific verbs: 'Activate, cancel or delete an Auto query.' This distinguishes it from sibling tools like auto_query (which likely handles reads) by focusing on write operations. The three operation modes are explicit.

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?

Provides strong usage guidance: tells the agent to validate with auto_validate and confirm with the user before calling, and mentions the special requirement for order-placing queries. However, it doesn't explicitly contrast with auto_query for read-only scenarios, so it stops short of full alternative differentiation.

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, idempotentHint=true, and destructiveHint=false. The description adds context beyond these by stating 'before anything is activated' (pre-flight nature), 'Free' (no cost), and the requirement to show the estimated cost to the user, enriching understanding of 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?

Three concise sentences, front-loaded with the core action and purpose, with no redundant details. 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?

Given an output schema exists and the tool has moderate complexity (nested query object), the description covers purpose, usage, safety, and parameter guidance sufficiently 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% with descriptions for all parameters, so the baseline is 3. The description adds the key either/or relationship between inline query and draftId, which clarifies parameter usage beyond 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 uses a specific verb ('Check EQL syntax and get a cost estimate') and identifies the resource (EQL query) while explicitly naming the sibling tool auto_query_write, distinguishing this validation tool from others.

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 when-to-use guidance: 'Always run this before auto_query_write', and notes the mode of use ('Pass either an inline query or a draftId'), which clearly frames its role against alternatives.

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?

Annotations already mark this as read-only, idempotent, and non-destructive. The description adds valuable context about cost (1 credit per call) and the return format (metrics and link, not text), as well as mode-specific behaviors, without contradicting 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 short, front-loaded with purpose, then cost, return limitation, and mode breakdown. Every sentence carries distinct information with no 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?

Given the high complexity (15 parameters, 3 modes) and the presence of an output schema, the description provides sufficient high-level context: mode behaviors, cost, and the key limitation of not returning post text. It doesn't mention pagination, but the schema covers that.

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 cross-parameter relationships by mapping modes to required parameters (top needs ticker, search needs keywords/accountName, news needs neither), which adds meaning beyond individual field descriptions.

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 the resource (social mentions from X and Telegram) and its return contents, but lacks an explicit verb like 'get' or 'list'. It does distinguish from siblings by specifying the platforms and modes, so 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?

The description explains the three modes and their parameter requirements, giving clear context when to use each. It also states a limitation ('not the post text') that guides when not to use it. However, it does not name alternative tools.

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.