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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world behavior. The description adds useful context beyond annotations: the call is free, it reports credit usage and remaining requests, and it explains the plan-dependent historyFrom limit affecting other tools.

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 short sentences, front-loads the core purpose, and includes only relevant plan-limit context. No sentence 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?

Given zero parameters, rich annotations, and an output schema, the description is complete enough: it states what is checked, that the call is free, that it confirms reachability, and how historyFrom relates to the plan. Return-value details can safely be delegated to the output 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?

The tool has zero parameters, so there are no parameter semantics to document. The description mentions historyFrom only as plan context for other tools, not as an input to this tool, which is appropriate for a zero-parameter status endpoint.

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 names concrete resources: API key tier, credit usage, remaining requests, and reachability. It is clearly distinguishable from sibling tools like events, market, and calls, which read data rather than report account/API status.

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 clear usage context: use this to inspect plan limits and confirm API reachability, and notes that the call is free. It does not explicitly state when not to use it or name an alternative, so it falls short of full when/when-not 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?

Adds substantial context beyond annotations: a stated cost of 1 credit plus LLM usage, the assurance that nothing executes until activation, and a coverage limitation on which X accounts can be used in tweet conditions. These are exactly the non-obvious traits an agent would otherwise get wrong, and they are consistent with readOnlyHint=true.

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?

Four short sentences, front-loaded with the purpose and the most decision-relevant constraint (draft-only, no execution), followed by cost and coverage limits. No sentence is redundant.

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 annotations and an output schema present, the description need not explain returns, and it covers cost, non-execution, and coverage limits. Minor gap: it does not mention how credit is charged on failure or how the sessionId refinement loop is expected to be used.

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, but the description earns more by explaining what the required message must contain (target, threshold, firing action) and implying the sessionId workflow ("Continue refining"). The speed parameter is left entirely to the schema, which is acceptable given its enum 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?

States a specific verb and resource: it turns a plain-language request into an EQL query draft. The sentence "This only drafts the query: nothing runs until it is activated" cleanly separates it from the execution siblings (auto_query, auto_query_write), though it does not explicitly distinguish itself from auto_validate or auto_draft.

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 input requirements ("Say what to watch, the threshold, and what should happen when it fires") and a clear usage boundary (tweet conditions only for accounts in Elfa's real-time set, not other X accounts). It stops short of naming which sibling to use for other request types, so it is clear but not fully 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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description earns extra credit by disclosing that drafts 'never evaluate and never fire' and that reads are 'Free', which is behavioral context the annotations cannot express.

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, zero filler, and the core definition of a draft is front-loaded. Each clause (read-side, method routing, draft semantics) earns its place with no repetition of schema fields.

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 output schema exists, so return values need not be described. The description supplies the one thing structured fields cannot: the domain concept of a parked, non-evaluating draft, making the tool fully usable from description plus schema plus annotations.

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 coverage at 100%, the schema already documents all six parameters, so baseline is 3. The description adds genuine meaning by explaining what each method value returns, complementing the schema's terse 'Which read to perform' enum description.

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 ('Read side of Auto drafts') and explicitly enumerates the two read modes (list vs get). It also names the resource concept precisely, distinguishing it from the write sibling auto_draft_write via the 'Read side' framing.

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?

Clearly explains which method selects which operation ('method=list browses saved drafts, method=get returns one draft'), giving an agent the routing decision. It stops short of stating when to prefer this over related siblings like auto_query or auto_build, so it is a 4 rather than a 5.

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 past the annotations by disclosing consequences: drafts never evaluate and never fire, while convert runs unattended and fires its action 'without asking again'. It also quantifies cost (convert costs the same as creating a query; upsert and delete are free), which is exactly the kind of information annotations cannot carry.

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, front-loaded with the capability and immediately followed by the per-method behavior. No filler; every clause (non-firing drafts, unattended firing, cost) 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?

For a destructive, open-world mutation with an output schema present, the description covers the critical unknowns: what each method does, what activation implies, and what it costs. Return values are handled by the output schema, so nothing essential 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%, so the schema already documents each field; the description adds value by explaining the semantics and consequences of the method parameter beyond the schema's one-line gloss. Other parameters (query, draftId, title) are left entirely to 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?

Opens with a specific verb set and resource ('Create, update, delete or activate an Auto draft') and then enumerates each of the three enum values with its distinct effect. An agent can distinguish this write tool from the read-side sibling auto_draft 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?

Explicitly routes between methods: upsert for parking a non-firing draft, delete for removal, convert for going live. It does not name the read sibling (auto_draft) as the alternative when no write is needed, so the exclusion side is only implied.

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 establish readOnly, idempotent, non-destructive, so the safety profile is covered; the description adds genuinely new behavioral context beyond them: the tool is free, there is no push channel, and polling cadence must respect pollAfterSeconds. It also discloses that method=get surfaces a failure with a recorded reason when evaluation failed. It could go further on rate limits or what polling too aggressively does, but the added context is substantive.

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 key framing ('Read side of Auto. Free.') and the polling constraint are front-loaded and compact. It is a single dense run-on sentence in the middle, but virtually every clause maps a method to its output, so little 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 annotations covering safety, a full schema, and an output schema to describe return shapes, the description's remaining job is method routing and polling behavior, both of which it handles. The main omission is guidance on which identifier parameters pair with which method beyond what the schema's 'Required for...' notes already 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?

Schema coverage is 100%, so the baseline is 3, but the description earns a bump by mapping each enum value of method to concrete behavior and return content — meaning the schema's terse 'Which read to perform' does not provide. It does not add anything for queryId, sessionId, executionId, or the filter parameters, relying entirely on the schema there.

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 framing ('Read side of Auto') and enumerates what each of the six methods returns (queries, evaluations, executions, LLM analysis), which lets an agent distinguish read operations from auto_query_write without opening the schema. It stops short of naming the write sibling explicitly, but 'Read side' carries the differentiation.

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 concrete routing guidance — use method=list to browse, method=get to poll a single query, method=executions/execution for what fired, method=sessions/session for LLM analysis — and adds a clear operational rule: there is no push channel, poll with method=get and respect pollAfterSeconds. The one gap is that it does not explicitly say to reach for auto_query_write when mutation is needed, leaving that to inference from the 'Read side' framing.

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 destructiveHint=true and openWorldHint=true, yet the description still adds real behavioral context: a 5-credit create charge, free cancel/delete, and the fact that an activated query fires its action without asking again — the key risk of this tool. The extra per-post/per-day billing for account-listing conditions is a concrete operational caveat not available in 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?

Four sentences, front-loaded with the action set, then cost and execution semantics. Every sentence carries information, though the final sentence is dense and mixes billing rules into one long clause.

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 annotations covering the safety profile and an output schema present, the description closes the remaining gaps an agent needs: credit cost, charge asymmetry across methods, and the irreversible unattended-execution behavior. Nothing essential to calling this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the method enum, queryId requirement, and query object shape are all documented there. The description's only parameter-adjacent contribution is naming x_follow_made/x_follow_overlap billing conditions inside the query object, which is marginal. Baseline 3 applies since the schema carries the load.

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?

Opens with three specific verbs against a named resource ('Activate, cancel or delete an Auto query'), so an agent immediately knows the mutation surface. It does not explicitly contrast itself with siblings like auto_query (read) or auto_build (drafting), leaving that routing to inference.

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?

Cost guidance is useful signal for choosing among methods ('Creating costs 5 credits plus LLM usage, cancel and delete are free'), and the unattended-execution warning implies caution. But there is no explicit when-to-use/when-not guidance and no named alternative — the pointer to auto_build for drafting a query lives in the schema, not the description.

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 safe-read profile (readOnlyHint, idempotent, non-destructive), and the description adds genuinely new behavior: the call is free, cost is an estimate, and per_post/per_day billing semantics accrue on top of estimatedCredits while the query runs. That is exactly the cost-model context an agent needs before committing to a query.

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 purpose and cost statement is front-loaded in the first two sentences, and the mode switch is placed last as a natural qualifier. The billing passages are lengthy and read as return-value documentation that the output schema could carry, which costs it a point.

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 an output schema, full schema coverage and safety annotations, the description is nearly complete: it covers both modes, input alternatives, and cost implications. It does not say what a failed validation returns or whether a valid draftId/query is mutually exclusive, leaving a small 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?

Schema coverage is 100%, so the schema already documents query, draftId, method, symbol and exchange. The description only reinforces the query-vs-draftId alternative and the method switch; the tweetAccounts/followAccounts text explains return fields rather than parameter meaning, so it adds little 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 opening sentence states a specific verb and resource: check EQL syntax and estimate activation cost, plus a distinct symbol-data mode. It is clearly separable from auto_build (drafting) and auto_query (execution), though it never names those siblings explicitly to route the agent.

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?

"Pass either an inline query or a draftId" and "method=symbol instead checks..." give concrete invocation context for both modes, including the price/ta condition prerequisite. It stops short of stating when to prefer this over auto_build/auto_query or that validation is a precondition to activation.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the bar is lower, yet the description adds real value by naming what is deliberately omitted (post text, recommendations) and by explaining that episodes match a position open at any point in the range rather than only at the endpoints. Pagination and cursor invalidation behavior live in the schema rather than the description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded and content-dense: the identity sentence comes first, then the level definitions, then the exclusion. There is a stray double period ('Telegram..') and the level definitions are run together in one block rather than separated, which slightly hurts scanability of a three-mode 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?

With 13 parameters, three read modes, and a full output schema, the description covers the mode semantics and the one meaningful omission from results. Remaining gaps—cursor reset behavior and range/ordering defaults—are fully covered by schema descriptions, so nothing needed to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description genuinely adds meaning to the central 'level' parameter by defining what each of calls, episodes and positioning returns, plus a cross-parameter idiom (episodes + status=open + from=now). It does not touch the remaining filters, which the schema documents adequately.

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 opening clause states the resource precisely: positions accounts take in posts on X and Telegram, decomposed into three named levels (calls/episodes/positioning). An agent understands what is being read and that it is position data, not post content. It does not name a sibling (events, mentions, top_accounts) to differentiate itself, which keeps it from 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?

It gives explicit mode-selection guidance, including the non-obvious recipe 'level=episodes with status=open and from set to now reads what every matching account holds right now', which is essentially a when-to-use rule. It also states a hard exclusion ('Not returned: post text or a recommendation'). It stops short of routing the agent to alternative sibling tools for adjacent needs.

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 read-only, idempotent, non-destructive behavior, so the description is free to add exact-match semantics, ticker non-uniqueness, and family-id unification such as WBTC and cbBTC mapping to Bitcoin. These are meaningful behavioral traits an agent would otherwise have to discover by trial and error.

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 conversion purpose, then adds only the constraints an agent needs: exact matching, ticker ambiguity, family-id sharing, and reuse. Dense but efficient; every sentence carries useful 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?

Given the output schema, the description covers the key caller-facing behavior: input forms, exact matching, ambiguity handling, and id reuse. Nothing critical is missing for correct invocation.

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 parameter documentation is already strong. The description still adds value by explaining why entityType matters: tickers are not unique, so narrowing by entity type helps disambiguate results.

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: turning many identifier forms into an entity id. It also clarifies that this is exact resolution, not search, which distinguishes it from more exploratory tools.

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 when the tool works (exact matches) and when it fails (prefixes or misspellings return nothing). It also gives practical guidance for ambiguous tickers: take the first row and check the name, or narrow with entityType, and reuse the resolved id.

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 annotations already state that this is a read-only, idempotent, open-world operation, so the safety profile is covered. The description adds meaningful behavioral context that annotations cannot: impacts is empty on most events, post text, sentiment scores, and prices are not returned, and paging is required. That prevents several likely agent mistakes.

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 purpose and the exclusions are front-loaded, and every sentence carries useful information. It is dense and somewhat run-on, and the first sentence contains a stray double period, but it is 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?

For a 21-parameter, three-level tool with an output schema, the description covers purpose, level semantics, lookup modes, and what is not returned. The remaining gaps are minor, such as which level-specific filters can safely be combined.

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, but the description adds cross-parameter semantics that the schema only documents in isolation: which arguments belong to which level, that arcs take no from, and that relevant ranking covers only the last 24 hours. These are real additions over the per-field text.

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 (crypto and equity market events derived from posts), the three granularity levels (events, storylines, arcs), and how each level relates. It also states what is not returned, so an agent can distinguish it from siblings like narratives, trending, and mentions without opening the 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?

It gives clear routing instructions: use q to search any level by topic, entityIds from the entities tool to filter by asset, or ids to fetch up to 30 held items. It does not explicitly contrast with sibling tools such as narratives or trending, which leaves some ambiguity about when this tool should be preferred.

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, openWorldHint and destructiveHint=false, so safety is covered. The description adds some useful behavior beyond that — the 30-day cap on trending_contracts and the fact that unnamed contracts are often the interesting ones — but pagination cost, latency, or data-freshness expectations are not described.

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 scope claim, then allocates one clause-group per view — every view-specific sentence carries information an agent needs. Slightly dense run-on at the end and a stray double period, but no filler.

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 params, an output schema, and rich annotations, the description covers the main risk — picking the wrong view and misreading call_book output. It could say more about how the three views relate to sibling tools, but nothing required for a correct call 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% and the schema already documents each param with its view applicability, cursor invalidation rule, limits, and defaults. The description's view narratives are helpful orientation but largely restate what the schema params already say, so the baseline 3 fits.

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?

Opens with a specific scope statement ('Whole-market views, no asset needed') and then defines each of the three view values concretely (mindshare rankings, call_book long/short lean, trending_contracts contract rankings). It differentiates from the per-asset siblings implicitly via 'no asset needed' but never names trending/narratives/top_accounts as alternatives or complements.

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 view-by-view selection guidance, including a real trap to avoid ('read crowdingPercentile rather than longShare, since the accounts lean long almost always') and a 'crypto only' constraint on trending_contracts. It stops short of saying when to reach for this tool instead of trending, narratives, or top_accounts.

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 safety (readOnly, non-destructive, open-world, non-idempotent), so the bar is lower, yet the description still adds real context: credit consumption, cost/speed tradeoff, session continuity semantics, and the fact that sources are links only and not their text. It does not restate annotation fields, which is correct.

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?

Four sentences, front-loaded with purpose and followed by cost, continuation and output notes. Each sentence carries information, though the sources sentence is slightly verbose for what it conveys.

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 an output schema, rich annotations and full parameter documentation, the description needs only to frame purpose and key behaviors, which it does. An agent knows what the tool does, what it costs, how to continue a thread, and what comes back.

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 all nine parameters are already documented, establishing a baseline of 3. The description adds only marginal meaning beyond that, mainly that sessionId should come 'from a previous reply'; the speed note largely repeats the schema's own 'cheaper and shallower' wording.

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: 'Ask Elfa for written market analysis grounded in its social data.' That is distinguishable from data-retrieval siblings like market, trending and narratives. It undersells the tool slightly by framing it as only 'market analysis' when the schema exposes six analysisTypes, but the core purpose is 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?

Gives useful in-tool guidance (continue a conversation via sessionId, choose fast for cost) but never routes the agent between this and siblings such as market, narratives or mentions. No explicit when-not-to-use or prerequisite conditions are stated.

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 read-only, idempotent, open-world, non-destructive, so safety is covered. The description adds cost per call, the return shape (engagement metrics plus link, no post text), and clarifies that 'news' is tagged X accounts rather than outlet articles – all beyond structured fields. Pagination/rate behavior is left to the schema.

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?

Five short sentences, front-loaded with what it is, then cost, then return shape, then per-mode breakdown. Each sentence carries information an agent would otherwise have to infer.

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?

A 15-parameter, three-mode tool is handled well: the mode semantics and return-content caveat are exactly what an agent needs, and the output schema covers return structure. Pagination and the search time-range constraint live only in the schema, which is acceptable but not ideal.

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 every parameter is already documented. The description usefully ties mode to its required inputs and clarifies the news feed's sourcing, but it adds little on timeWindow, verbosity, reposts, cursor, or the search range constraint beyond what the schema states.

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 the concrete resource (social mentions from X and Telegram) and enumerates the three modes with distinct semantics, which no sibling tool offers. An agent can tell this apart from trending, narratives, or market without opening the 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?

Gives clear mode-selection guidance (top needs a ticker, search filters by keyword or account, news is a feed needing neither) and notes the one-credit cost. It stops short of naming alternatives such as trending or narratives for adjacent use cases.

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 cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely new operational facts: 5 credits per call and that scope=keywords can take over a minute. Cost and latency disclosure is exactly the context annotations cannot convey.

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 compact sentences with no filler, front-loaded with the core purpose, then cost, then scope behavior. Every sentence carries 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?

Covers purpose, cost, latency, and per-scope behavior, and an output schema exists so return format needn't be explained. Only slight gap is not mentioning the time range parameters, but those are fully documented in a 100%-coverage schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% so the baseline is 3, but the description adds value by explaining what each scope actually returns: scope=market extracts market-moving narratives, scope=keywords summarises events for supplied keywords. That clarifies the semantic difference between the two enum branches beyond the schema's terse notes.

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 combination ("Written narrative analysis with source links") and contrasts its use case against count-based tools ("for when counts are not enough"). It also distinguishes its two scopes. It never names a specific sibling tool, which keeps it from a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear selection condition ("for when counts are not enough") and explains the two scope branches, including that scope=keywords requires supplied keywords. It doesn't explicitly route to alternatives like market, trending, or mentions, so it stops short of full when/when-not 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 declare read-only, idempotent, non-destructive, so safety needs no restatement; the description instead adds real caveats an agent can't get elsewhere: track is null for accounts that never opened a position, track metrics only rank accounts with ≥20 scored positions, and the coverage window is every position since late June 2026. It adds scoredEpisodes semantics too, though it says nothing about result size or paging 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?

Front-loaded with the two ranking modes, then the caveats; nearly every clause carries usable information. There is a stray double period ('callers..') and the metric advice is squeezed into one long sentence, but nothing is padding.

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 output schema exists, so return values need not be described; the schema also handles pagination via limit/cursor. What remains — what the metrics mean, null semantics, the minimum-position threshold, and the time window — is all covered.

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 100% schema coverage the baseline is 3, but the description goes beyond the enum docs by explaining why alphaScore is preferred over avgReturn and what standing actually measures. The normative guidance ('not avgReturn') is the kind of meaning the schema does not carry.

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 — X accounts ranked — and immediately splits the two ranking modes (standing vs. track record via metric). It doesn't name any sibling (entities, trending, calls) as the alternative, so the agent must infer the boundary, but the purpose itself 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?

Gives explicit selection advice within the tool: 'For the best callers use metric=alphaScore, not avgReturn, which a few big wins or a rally can top,' plus the caveat that standing measures attention, not accuracy. There is no guidance on when to use this tool versus sibling tools such as trending or entities, which keeps it below 5.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the bar is lower, and the description still adds genuinely useful context: a per-call credit cost and the fact that token results include change against the previous window. It does not mention whether results are cached, rate-limited, or how the cost scales with pageSize.

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 compact sentences with the purpose front-loaded and scope semantics grouped together; the credit cost is placed out of the way. The opening fragment 'What is gaining social attention right now' is slightly indirect but earns its place as orientation.

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 output schema exists, all seven parameters are documented in the schema, and annotations cover the safety profile, so the remaining burden on the description is small. It fills exactly the gaps that matter: what each scope returns and what the call costs.

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 does add one thing the schema does not: the concrete meaning of each of the three scope enum values, since the schema text only says 'which trending list to return.' It adds nothing about from/to versus timeWindow precedence, minMentions, or paging strategy, all of which the schema covers.

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 clearly and, crucially, spells out what each scope returns: tickers ranked by mention volume with delta vs the previous window, or trending contract addresses. It lacks a crisp verb and never distinguishes itself from sibling social tools (mentions, narratives, top_accounts), so an agent must infer the difference.

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?

Scope-by-scope output descriptions implicitly tell the agent which variant to pick, which is real selection guidance. But there is no statement of when to prefer this over mentions or narratives, 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.