arkolith

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

Description adds value beyond the readOnlyHint annotation by explicitly stating it is free and never deducts credits. No contradictions.

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?

Description is extremely concise, two sentences, front-loaded with key info (FREE, 0 credits). Every word is necessary.

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, no output schema, and annotations already covering read-only, the description is fully complete, including mention of the top-up URL.

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?

There are no parameters, so the description cannot add parameter semantics. Baseline for zero parameters is 4.

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 the API key's credit balance, USD value, and top-up URL. It also emphasizes it is free and that checking balance never costs credits, distinguishing it from other 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?

The description advises calling this tool for self-monitoring before and after spending. While it doesn't explicitly say when not to use it, the guidance is clear and sufficient for this simple tool.

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 set readOnlyHint=true. Description adds value: price-free, point-in-time, traced to 13F, backward-looking ~45 days, not investment advice. No contradictions.

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 key purpose, detailed but efficient. Each sentence adds value; no redundancy. Slightly long but justified by complexity.

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 no output schema, description mentions output elements (net flows, breadth, rotation rank). With 4 parameters and high schema coverage, it is fairly complete. Lacks explicit return type but adequate.

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 covers 100% of 4 parameters. Description adds meaning: explains weight_by options (fund_quality vs equal), period format, direction filter. Adds context beyond 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 states it aggregates 13F position changes into per-sector capital flows, answering 'where smart money is rotating'. Uses specific verbs and distinguishes from siblings as a unique flagship signal.

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 context for when to use (e.g., 'is smart money rotating out of tech into energy/utilities?') and what it replaces (static quarterly PDF). No explicit when-not-to-use, but clarity is high.

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 estimated dates are sponsor-self-reported and can slip, that the feed is from public-domain ClinicalTrials.gov v2, and that it returns specific fields. Annotations already indicate readOnlyHint=true, so the description adds context beyond that. It does not cover rate limits or pagination, but the behavioral traits are well explained.

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 a single dense paragraph that efficiently communicates purpose, filters, output, and caveats. It is front-loaded with the key concept. While it could be broken into sections for improved readability, it contains no unnecessary 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?

Given the presence of 7 parameters with full schema coverage and readOnlyHint annotation, the description covers the tool's scope, filtering, output fields, and caveats. It does not describe error handling or response format, but the output fields are enumerated. This is sufficient for a read-only search tool.

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 adds significant value beyond the parameter schema. It provides defaults (limit 25, phase 'PHASE2|PHASE3', status 'RECRUITING|ACTIVE_NOT_RECRUITING', within_days 365), explains the nct_id bypass behavior, and clarifies that sponsor is a lead sponsor company name. This enhances the usability of each parameter.

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 purpose: finding upcoming clinical-trial readout catalysts for industry-sponsored Phase 2/3 drug trials. It uses specific verbs and resources (e.g., 'Upcoming clinical-trial readout catalysts') and distinguishes itself from sibling tools like fda.approvals and fda.recalls by focusing on trial readout dates rather than approvals or recalls.

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 when to use the tool (for upcoming readout catalysts) and provides filtering options (sponsor, condition, phase, date window). It includes a caveat about estimated dates slipping and recommends checking press releases for more accurate timing. However, it does not explicitly mention when not to use it or suggest alternatives for different trial data 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 indicate read-only; description adds that it returns one row per filing with PDF link, and clarifies it's an index not parsed trades.

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

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

Two concise sentences with no redundancy, front-loaded with key 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?

No output schema but description explains return format (rows with PDF link), clarifies what it is not, and references sibling tool.

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 provides 100% coverage; description adds specific meaning to filingType (e.g., 'P' = Periodic Transaction Report).

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?

Description specifies verb 'List', resource 'US House financial-disclosure filing INDEX', scope 'for a year', and distinguishes from sibling tool 'congress.trades' for parsed trades.

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 explains filingType 'P' meaning, states this returns index not parsed trades, and directs to congress.trades for parsed line-items.

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

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

Annotations declare 'readOnlyHint: true', and description adds scope ('US House live; Senate being added') and relationship to 'congress.trades'. There is no contradiction. Description adds context beyond annotations, but doesn't detail what 'filing index' means or how results are structured.

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?

Description is a single sentence with one parenthetical note, conveying purpose, scope, and a pointer to sibling tool. It is concise, though the dash-separated additional info could be clearer in structure, but remains efficient.

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

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

For a simple search tool with 2 parameters, read-only hints, and no output schema, the description sufficiently covers the primary use case. It mentions the filing year and links to related tool for trades. Some details about result format or range of years are omitted, but overall adequate.

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 has 100% coverage with descriptions for both 'name' and 'year'. The description rephrases 'by name' and 'in a year', adding marginal context that the tool finds representatives with disclosures in that year. No additional parameter-level details beyond schema, so baseline score 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?

Description specifies verb 'Find' and resource 'US House representatives who filed financial disclosures in a year', making the tool's purpose clear. It distinguishes from siblings like 'congress.trades' (parsed trades) and 'congress.disclosures.list' by focusing on member search by name and year.

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 implicitly guides usage by stating 'parsed trades available via congress.trades', suggesting when to use that alternative. However, it lacks explicit guidance on when to use this vs. 'congress.disclosures.list' or other related tools, and does not mention when not to use this tool.

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 readOnlyHint=true; the description adds valuable context about data recency (House live, Senate pending) and the link to source PDFs, 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?

Two succinct sentences plus an instruction, all front-loaded with the tool's purpose, no wasted 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?

Given no output schema and simple parameters, the description covers the key data returned (buy/sell, amount range, dates, owner, source PDF), the current coverage, and the query method, making it sufficiently 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%, but the description adds crucial guidance that 'ticker' and 'member' are alternatives ('Pass `ticker` OR `member`'), which is not clear from the individual schema 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 explicitly states it provides 'Parsed STOCK Act transaction line-items: actual congressional stock trades by ticker or by member' with specific fields, making the purpose clear and distinct from sibling tools like congress.disclosures.list.

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 clear instructions to 'Pass `ticker` OR `member`' and notes that US House data is live while Senate is being added, but lacks explicit guidance on when not to use or alternatives among siblings.

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 significant behavioral context beyond the readOnlyHint annotation. It discloses the data source (public-domain SEC EDGAR 13F), the row contents (name, manager, book size, holdings count, etc.), the simulated copy-return track record, and the intended use as a ranking tool. No contradiction with 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 concise (5 sentences), front-loaded with the core purpose, and every sentence adds value: it defines the output, mentions key fields, links to other tools, and explains sorting. No unnecessary 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?

Without an output schema, the description fully explains what each row contains (name, manager, AUM, holdings count, quarter, followers, track record, slug, CIK). It also indicates where to get more details (copy.target.get, fund.holdings) and that data is from public EDGAR. The tool's purpose and output are adequately 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?

Schema description coverage is 100%, so the baseline is 3. The description repeats the sort enum values and limit range, adding minimal new meaning. It clarifies the default sort (aum) but otherwise provides no additional semantics 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 states the tool ranks institutional managers (13F funds) worth copying, using a specific verb 'rank' and resource 'institutional managers'. It distinguishes itself from sibling tools like 'copy.target.get' and 'fund.holdings' by mentioning the slug and CIK fields and positioning itself as the 'who should I copy?' entry point.

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 context for when to use this tool, calling it the 'agent-native entry point' for copying decisions, and explains the sort options (aum, active, followers, return). However, it does not explicitly state when not to use it or name alternatives for specific use cases, though sibling tools are referenced.

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, so the description is consistent. It adds value by explaining that data comes from public-domain SEC EDGAR, and it details what the output contains, which helps the agent understand the tool's behavior beyond the annotation.

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 no wasted words. It front-loads the purpose and output, then adds usage guidance and data source. Every sentence adds value.

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 one parameter and read-only annotation, the description thoroughly covers input source, output fields, and usage pairing. No output schema exists, but the description explains return values clearly.

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 input schema already describes the slug parameter (100% coverage). The description adds context that the slug comes from copy.leaderboard, providing guidance on how to obtain it. This additional information helps the agent use the parameter correctly.

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 verb 'Get' and the resource 'one copy target (13F fund)', specifies the input (slug from copy.leaderboard), and details the output (latest disclosed book, holdings with changes, book size, quarter, filing history). It distinguishes from sibling tools by mentioning copy.leaderboard for slug and watchlist tools for follow-up.

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 when to use it (to get a specific copy target's latest book) and where to get the slug (from copy.leaderboard). It suggests pairing with watchlist tools. It does not explicitly state when not to use, but the context is sufficient for an agent.

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 keyword-correlation limitation and confirms read-only nature (consistent with annotations). Could mention rate limits or authentication needs, but annotations already cover readOnlyHint.

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

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

Two sentences, front-loaded with purpose, followed by a caution. No redundant or extra 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 no output schema, the description effectively conveys input and the key limitation. Could be slightly more thorough on output format, but adequate for an agent.

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?

Both parameters have schema descriptions; description adds value by explaining 'limit' per platform and providing example keywords for 'query'. Schema coverage is 100%.

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 the tool compares implied probabilities from Polymarket and Kalshi for a keyword to surface mispricing/arb. Distinct from sibling tools like predictionmarket.list or signal.confluence.

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 context on when to use (keyword-based cross-market comparison) and a critical caution about unverified matches. Does not explicitly mention alternatives or when not to use.

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 significant behavioral context beyond the readOnlyHint annotation: describes streaming behavior, cursor mechanism, and polling pattern. No contradiction with 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, front-loaded with main purpose, then usage details, then use case. No redundant information; 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?

For a polling tool with no output schema, description provides enough context: mentions next_cursor, filtering options, and intended use case (watch loop). Annotations cover safety, so no gaps remain.

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

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

All four parameters are fully described in the schema. Description adds meaningful context: explains 'since' as a monotonic cursor from prior response, form filter examples, and tickers filter. Goes beyond schema 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?

Clearly states it's a live SEC filing-event stream. Uses specific verb 'poll' and resource description. Differentiates from siblings like insider.transactions by emphasizing 'live' and 'watch loop' use case.

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 instructs to poll with 'since' cursor and schedule calls for watch loop. Implies continuous monitoring usage but does not explicitly mention when not to use or 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 (readOnlyHint: true). The description adds valuable behavioral context: it is a confirmation/archive feed with lag, CDER-only scope, and public-domain source. No contradiction with 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 relatively compact given the amount of information conveyed. It front-loads the key actions and caveats, but could be slightly more streamlined without losing clarity.

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 number of parameters (8) and no output schema, the description covers main use cases, return values (regulatory actions, sponsor resolution), and important limitations (lag, CDER-only). Adequately complete for an experienced user.

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 parameters are already well-documented. The description adds general context but does not elaborate on parameter specifics beyond mentioning action types. 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 clearly states the tool returns FDA drug approval/rejection actions for a sponsor or drug, lists specific action types (AP, CR, TA), and mentions key flags (NME, priority review). This distinguishes it from the sibling fda.recalls, which deals with recalls.

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 clear context: backward-looking, lags press releases, CDER-only (excludes biologics). Explicitly states what it is not (real-time) and notes limitations, but does not explicitly compare to alternatives like clinicaltrials.search.

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 honestly discloses data freshness limitations (weekly updates, no status revisions) and the return of resolved ticker (null for private firms). These details add value beyond the readOnlyHint annotation, ensuring the agent understands potential staleness.

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 a single, well-structured paragraph that front-loads the core purpose, then explains classifications, filters, returns, and caveats. Every sentence adds value with no redundancy or fluff.

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 no output schema, the description adequately explains return fields. Parameter descriptions are complete in schema. The caveat covers freshness. Might lack pagination details, but for a filterable recall list, this is 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?

Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining Class I severity and that the output includes ticker, going beyond schema descriptions. It also summarizes filter options, reinforcing their purpose.

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 it covers FDA drug recalls, explains the classification system (Class I, II, III), lists available filters (firm, drug, classification, recency), and specifies the return fields including ticker. This distinguishes it from sibling tool fda.approvals, making its 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?

The description provides usage context with the caveat about weekly updates and data staleness, advising against real-time alerting. It does not explicitly contrast with alternatives, but the sibling list includes fda.approvals, so the domain difference is implied. The caveat effectively guides when to use this tool.

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 indicate readOnlyHint=false, and description states it's free and shapes future builds, implying a write operation. No contradiction; description adds context but doesn't detail side effects like storage or confirmation.

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

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

Two sentences with zero waste. First sentence states purpose and cost; second provides usage context. Highly efficient for a simple input 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?

Given the simplicity (3 params, no output schema), description adequately covers the use case. It could mention what happens after submission (e.g., no response), but overall is complete for a feedback tool.

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 has 100% coverage with descriptions for all 3 parameters. Description aligns with parameter purposes but adds no new details beyond the schema. Baseline 3 applies as schema does the heavy lifting.

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?

Description clearly identifies the verb ('submit feedback'), the resource (the Arkolith team), and the specific use cases (data requests, bug reports, ideas). It distinguishes from siblings as no other feedback tool exists.

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 states when to use ('whenever a dataset you needed wasn't available or a result looked off'). Provides clear context but does not explicitly exclude any scenarios or mention 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?

Annotations already include readOnlyHint=true, description adds context about data source ('Public-domain SEC EDGAR data'). No additional behavioral traits disclosed, but the tool is straightforward and read-only.

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?

Single sentence with a dash for additional detail, front-loaded with core purpose. Every word 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?

Tool has one parameter and no output schema. Description sufficiently states return value (top positions, CUSIP, QoQ change). No missing information for an agent to invoke 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% with cik described as 'SEC Central Index Key (zero-padded)'. Description only mentions 'by SEC CIK', adding minimal value beyond schema. Baseline score 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?

Description clearly states the tool returns latest 13F equity holdings for a fund by CIK, with top positions, CUSIP, and quarter-over-quarter change. It distinguishes from siblings like fund.holdings.as_of and fund.holdings.diff by specifying 'latest reported'.

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?

Description implies usage by stating 'Latest reported' and 'public-domain SEC EDGAR data', but does not explicitly state when to use this vs alternatives like fund.holdings.as_of for specific dates. No explicit exclusions or alternative tool naming.

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 key behavioral details beyond the readOnlyHint annotation: it explains the look-back logic (most recent filing with filedAt <= as_of) and explicitly states no look-ahead, which is critical for backtesting. No contradiction with 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 a single, well-structured sentence that front-loads the core concept ('point-in-time holdings') and efficiently conveys the key behavioral rule and use case.

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 schema covers parameters and annotations indicate read-only, the description provides all necessary behavioral context for a tool that retrieves historical point-in-time data. No output schema is needed as the purpose is clear.

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%, providing clear descriptions for both parameters. The description reinforces the meaning of as_of with additional context about the filedAt constraint, adding value 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 states the tool returns point-in-time holdings as known on a given date using the most recent filing with filedAt <= as_of. It distinguishes from siblings like fund.holdings (current) and fund.holdings.diff by emphasizing backtesting use.

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 explicitly says 'built for backtesting' and 'no look-ahead', which strongly implies it is for historical analysis. It does not explicitly name alternatives or state when not to use it, but the context is clear enough.

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

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

Annotations declare readOnlyHint=true, and the description adds behavioral context by specifying the exact types of changes (new, adds, reduces, exits). This goes beyond what annotations provide, though it does not mention any potential rate limits or authentication requirements.

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 a single concise sentence that efficiently conveys the tool's purpose and output. Every word is necessary, and there is no redundant 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?

For a simple tool with one parameter and no output schema, the description is fairly complete. It clearly explains the output (change set) and scope (most recent filing). However, it could be improved by mentioning the format of the output or any limitations, but given the tool's simplicity, it is adequate.

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 input schema has 100% description coverage for the single parameter 'cik', explaining it as 'SEC Central Index Key'. The description does not add additional meaning or constraints beyond what the schema already provides, so the baseline score 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 clearly states that the tool provides a quarter-over-quarter change set for a fund's most recent 13F filing, listing new positions, adds, reduces, and exits. It uses specific language ('new positions, adds, reduces, and exits') that distinguishes it from sibling tools like 'fund.holdings' or 'fund.holdings.as_of'.

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 analyzing changes in holdings but does not explicitly state when to use this tool over alternatives like 'fund.holdings' or 'fund.holdings.as_of'. No 'when not to use' guidance is provided, leaving the agent to infer from the tool name and sibling context.

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

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

Annotations declare readOnlyHint=true, which is consistent. The description adds that data is from public-domain SEC EDGAR, providing context beyond the annotation, but doesn't disclose additional behavioral traits like rate limits or pagination.

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 concise, front-loads the purpose, and uses only a few sentences to convey all necessary information without 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 low complexity (1 parameter, no output schema), the description is complete. It explains the return values and how the CIK connects to other tools.

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 covers the single parameter (limit) with 100% description coverage. The tool description does not add additional semantic information 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 states it lists institutional managers filing SEC 13F reports ranked by AUM, specifies the returned fields, and distinguishes itself as the starting point for fund tracking by referencing related tools like fund.holdings.

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 advises 'Start here to find which funds to track,' implying this is the entry point. While it doesn't explicitly exclude alternatives, it provides clear context for use.

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 readOnlyHint=true. The description adds that the tool returns shares and USD value per quarter, but does not disclose any further behavioral traits (e.g., rate limits, data freshness).

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

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

A single, well-structured sentence that conveys the essential information without waste.

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 description lacks details on the return structure or pagination. Without an output schema, the agent cannot determine the format of the time-series data (e.g., array of objects with date/value fields).

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 clear descriptions for cik, cusip, and ticker. The description redundantly mentions 'by ticker or CUSIP' but adds little 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 states the specific verb ('Time-series'), resource ('single security position'), and scope ('across a fund's filings — shares and USD value per quarter'). It clearly distinguishes from sibling tools like fund.holdings (current) and fund.holdings.diff (differences).

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 historical position data but does not explicitly contrast with alternatives like fund.holdings or fund.holdings.as_of. No when-not-to-use guidance is provided.

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 substantial behavioral context beyond the readOnlyHint annotation, explaining the nature of the score (price-free conviction proxy), the output (component breakdown and top new/added positions), and clarifying it is not investment advice.

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 somewhat lengthy but each sentence adds value, covering purpose, methodology, output, and limitations in a logical order. It is well-structured and front-loaded with the core function.

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?

Without an output schema, the description compensates by detailing what is returned (fund rankings, component breakdown, top new positions). It also covers exclusions, sort options, and default period behavior, making it complete for an agent to invoke 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, and the tool description enriches understanding by explaining the meaning of sort options and the period format, as well as default behaviors (e.g., omitting period for latest quarter).

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 ranks institutional funds by a price-free quality score, specifying the resource and the metric. It distinguishes itself from other tools by emphasizing it is not a performance tracker and excludes certain filers.

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 context on when to use the tool (to identify concentrated conviction managers) and what it excludes, but does not explicitly mention when alternatives like 'fund.list' or 'fund.holdings' would be more appropriate.

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 have readOnlyHint=true, which description does not contradict. Description adds behavioral context: explains confluence meaning, rotation context, and disclaimers. No side effects or rate limits mentioned, but adequate given 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?

Description is slightly long but front-loaded with key action and every sentence adds value. Could be trimmed, but overall efficient.

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 no output schema, description adequately explains return values (verdict and rotation context). Complete for a simple query tool, leaving no major gaps.

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 clear parameter descriptions. The description repeats the lookback window info but adds context about it being for corroboration. Baseline 3 is appropriate as description adds minimal value beyond 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 states the tool's purpose: for one ticker, it returns cross-source confluence verdict (13F, Form 4, STOCK Act) and capital-rotation context. It distinguishes itself from siblings like signal.confluence and capital_rotation by combining them into one output.

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 specifies it's for a single ticker and includes a caveat that Congress is a corroborating leg, never sole basis. It doesn't explicitly mention when to use vs alternatives, but the context of sibling tools implies its unique 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?

Annotations already declare readOnlyHint=true, so the description does not need to reiterate safety. The description adds that the tool returns ranked tickers, but does not disclose additional behavioral traits like pagination or rate limits. Given annotation coverage, the description provides minimal extra transparency.

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 no wasted words. It front-loads the core function ('Market-wide insider cluster scan') and efficiently explains the output.

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 description adequately covers what the tool does, what it returns, and the filtering criteria (days, side, limit, min_insiders). It lacks mention of pagination or error handling, but for a scan tool with optional parameters, this is mostly 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 description coverage is 100%, so the schema already documents all four parameters. The description does not add any further meaning or usage hints for the parameters beyond what the schema provides. 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 clearly states the tool performs a market-wide insider cluster scan, returning tickers ranked by distinct-insider count and total value. It uses specific verbs ('scan', 'returns') and distinguishes from sibling tools like 'insider.company' by specifying market-wide 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?

The description implies usage for detecting high-conviction insider signals across the entire market, which differentiates it from per-company tools. However, it does not explicitly state when not to use or name alternative tools, so it misses full marks.

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 the tool is read-only (readOnlyHint=true). The description adds behavioral details: it focuses on open-market transactions, provides buy vs sell value/shares, and distinct counts. No contradictions.

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 core function, and every sentence adds value. No wasted 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?

With no output schema, the description gives a good sense of what is returned (buy vs sell values, shares, counts). It could be slightly more specific about output structure, but it is adequate for the tool's simplicity.

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 not add significant meaning beyond what the schema already provides; it only loosely mentions 'open-market buy vs sell value/shares' without linking to parameters.

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 computes net insider activity for one company over a time window, distinguishing it from sibling tools like 'insider.transactions' (individual transactions) and 'insider.clusters' (groupings). It answers a specific question: 'are insiders net buying or selling this name right now?'

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 when to use the tool by framing the question it answers. It does not explicitly state when not to use or mention alternatives, but the sibling list and context signal make the use case 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?

Discloses what the tool returns (full filing details, net flow, link) and is consistent with the readOnlyHint annotation. No contradictions; description adds value beyond annotations by specifying output contents.

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?

Single, well-structured sentence that front-loads the main purpose and includes critical context. Every word earns its place; no fluff.

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

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

For a simple one-parameter tool with readOnlyHint annotation and no output schema, the description is fully adequate. It explains inputs, outputs, and usage context comprehensively.

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

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

Only one parameter (accession) with schema description. Schema coverage is 100%, so the description adds minimal additional meaning. It mentions the accession_number concept elsewhere, but the schema already clearly defines 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 provides a specific verb+resource ('One SEC Form 4 filing by accession number') and lists all key components (insider, issuer, transactions, net flow, link). It also distinguishes itself as a follow-up tool for insider.transactions or events.latest, clearly differentiating from siblings.

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 states when to use: 'The full-filing follow-up when insider.transactions or events.latest hands you an accession_number.' This provides clear context and references sibling tools, guiding appropriate invocation.

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 behavior (readOnlyHint=true). The description adds context about transaction types (open-market, awards, option exercises) and filtering behavior, but lacks detail on return fields or pagination, which would enhance transparency.

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

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

Two concise sentences cover purpose and key usage tips. No unnecessary words; front-loaded with core 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 5 parameters and no output schema, the description covers the main use cases and two key parameters. It is adequate for a list tool but could mention the structure of returned data or error scenarios for full completeness.

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 baseline is 3. The description adds value by explaining `signal` (restrict to tradeable subset) and `since` (diff new filings), which enriches the brief schema descriptions. Other parameters are adequately described.

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 that the tool retrieves insider transactions (SEC Form 4) for a company by ticker or a person by insider name, listing specific transaction types. It effectively distinguishes itself from sibling tools like insider.clusters and insider.company.

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 explicit guidance on when to use optional parameters (`signal: true` for open-market trades, `since` for diffs). However, it does not explicitly state when to avoid this tool or mention alternatives, though differentiation is implicitly clear from sibling names.

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. Description adds no extra behavioral context beyond stating it gets observations. No contradiction.

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?

Single sentence with examples, no wasted words. Information is front-loaded and clear.

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

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

With no output schema, tool is simple enough. Description covers purpose and key parameter examples. Could mention return format but not critical.

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%, but description adds helpful examples for series_id (e.g., DGS10, CPIAUCSL) which add value.

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?

Clear verb 'Get' and resource 'recent observations for a macro/economic time series from FRED' with examples. Distinguishes from macro.series.search which is for finding series.

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?

Implicit usage by providing series IDs, but no explicit when-to-use or when-not-to-use compared to siblings like macro.series.search.

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 is consistent with the readOnlyHint annotation (read-only search operation). It adds that the tool returns series IDs and titles, which provides some behavioral context. However, it does not disclose pagination, result limits, or any quirks of the FRED search API. With annotations already covering safety, the description's added value is moderate.

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 a single, front-loaded sentence with no extraneous information. Every word serves a purpose: verb, resource, input, output. At ~15 words, it is highly efficient.

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

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

For a simple search tool with one required parameter, no output schema, and clear annotations, the description is nearly complete. It specifies the domain (macro/economic), the source (FRED), and the return type (IDs and titles). It lacks details like result ordering or pagination, but these are minor for a typical search tool.

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 input schema has 100% coverage with a single 'query' parameter and an example. The description merely repeats 'by keyword', adding no new semantic value beyond the schema. The baseline score of 3 is appropriate since the schema already handles documentation.

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 action ('Search'), the resource ('FRED for macro/economic time series'), the input method ('by keyword'), and the output ('returns matching series IDs and titles'). This is specific and distinguishes it from sibling tools like macro.series.get, which likely retrieves a specific series rather than searching.

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 keyword-based search of economic time series, but does not explicitly provide when-to-use or when-not-to-use guidance. It does not mention alternatives like macro.series.get for retrieving a known series, leaving the agent to infer context from sibling names.

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 significant detail beyond the readOnlyHint annotation: it lists the return fields (ticker, company name, exchange, resolution method) and explains the handling of private/unmatched names (returns null instead of guessing). This fully discloses the tool's 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?

The description is concise (3-4 sentences) and front-loaded: first sentence states the function, second gives the purpose, third summarizes the output, and last addresses the edge case. No unnecessary 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 simple lookup tool with one parameter and no output schema, the description covers purpose, input format, output structure, and edge cases. It is complete enough for an agent to use 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 single parameter 'name' is described in the schema as 'Sponsor / manufacturer name to resolve'. The description adds examples ('Janssen Pharms', 'AstraZeneca AB') and context about what the parameter is used for, adding value 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 states the tool resolves a pharma sponsor/manufacturer name to its public ticker, with examples like 'Janssen Pharms' and 'AstraZeneca AB'. It explains the purpose: joining FDA data to financial data (13F, insider buys, confluence signal), distinguishing it from siblings like fda.approvals or get_ticker_confluence.

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 use case (joining FDA approvals/trials/recalls to financial data) and provides guidance on output behavior (ticker:null for private/unmatched, no guessing). It does not explicitly state when not to use it or list alternatives, 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?

The readOnlyHint annotation already indicates a safe read operation. The description adds that it returns implied probabilities, but does not disclose other behavioral details such as rate limits, pagination, or data freshness. No contradiction with 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 a single, front-loaded sentence that clearly states the action, resource, and scope with no redundant 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?

Given no output schema, the description states the return type (list with implied probabilities). It lacks details on sorting or pagination, but for a simple list tool with optional filters, this is mostly adequate.

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 description reiterates the optional keyword filter but adds minimal meaning beyond what the schema already provides for each parameter (limit, query, platform).

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 'List' and identifies the resource 'prediction-market contracts with implied probabilities' from defined platforms (Polymarket and/or Kalshi), clearly distinguishing it from sibling tool predictionmarket.quote which retrieves a single quote.

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 mentions optional keyword filtering and default for platform and limit, but does not provide explicit guidance on when to use this tool versus alternatives like predictionmarket.quote or how to choose between platforms.

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', so the safety profile is known. The description adds that it returns 'implied probability', but no further behavioral details (e.g., output format, error handling) are provided.

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 a single, effective sentence with no unnecessary words. It front-loads the key action and resource, making it 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?

The description adequately explains the tool's purpose and parameters, but lacks output format details (e.g., probability as decimal or percentage) and error handling. Given no output schema, this is a minor gap.

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

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

The description adds no new information beyond the input schema: it repeats that the tool uses 'platform' and 'id'. Schema description coverage is 50% (only 'id' has a description), but the description does not clarify the 'platform' parameter or add syntax details.

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 action ('Get'), resource ('prediction-market contract's implied probability'), and the identification method ('by platform + id'). It also clarifies 'id' as 'Polymarket slug or Kalshi ticker', differentiating it from sibling 'predictionmarket.list'.

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 use for a single contract quote, but does not explicitly state when to use this tool over siblings like 'predictionmarket.list' or provide exclusions. The guidance is implicit rather than explicit.

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 indicate the tool is read-only (readOnlyHint=true). The description adds behavioral context by specifying the returned fields (origin URL, fetch time, parser version), which goes beyond the annotations. No contradictions.

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 a single sentence of 18 words, efficiently conveying purpose and output. 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?

Despite lacking an output schema, the description lists key return fields. It covers the essential context for a simple lookup tool. Slightly lacking in error or limitation details, but sufficient for typical use.

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 input schema covers both parameters with descriptions (100% coverage). The description does not add additional parameter semantics beyond what the schema provides, hence the baseline of 3.

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 source records for a datapoint, listing specific fields (origin URL, fetch time, parser version) and the purpose (citing primary sources). It uses a specific verb and resource, and there are no sibling tools with overlapping 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 implies when to use the tool (to trace provenance of a datapoint) but does not provide explicit guidance on when not to use it or compare it to alternatives. With no directly similar siblings, the lack of explicit usage guidance is acceptable but not optimal.

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 declare readOnlyHint=true, so the description need not repeat that. It adds context about the type of entities searched and the output format but does not disclose further behavioral traits beyond what annotations provide.

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

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

The description is two sentences, front-loaded with the main purpose, and contains no extraneous words. Every sentence adds value.

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

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

For a simple tool with one parameter and no output schema, the description covers purpose, input examples, expected output (CIK/slug), and relationship to sibling tools. It is fully adequate for an agent to use 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 schema describes parameter 'q' as 'Search query'. The description adds meaning by specifying that it is a fund or manager name and providing examples. This enhances understanding 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 clearly states that the tool resolves a name to a tracked entity, converting names like 'Berkshire' or 'Citadel' into SEC CIK or slug for use with fund.* tools. It also identifies itself as the entity-resolution entry point, distinguishing it from sibling 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?

The description explains that the tool is the entry point for entity resolution and that its output is passed to fund.* tools. While it implies when to use it (when needing CIK/slug for funds/managers), it does not explicitly state when not to use it or mention 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?

Annotations already indicate `readOnlyHint: true`. The description adds behavioral details such as congress dollar amounts being approximate midpoints and strict ticker joining (no fuzzy match), which informs the agent about data quality and constraints.

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 a single dense paragraph with heavy emphasis (caps, emojis). While it front-loads the core concept, it contains redundant phrasing ('the moat join', 'triple_confluence_buy') and could be more streamlined. It earns its place but is not optimally concise.

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 5 parameters, two modes, and no output schema, the description covers purpose, parameter roles, data sources, and return concept (verdict, triple_confluence). It omits exact output fields but provides enough for an agent to understand the tool's capabilities and limits.

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 baselines are met. The description enhances understanding by explaining how each parameter affects the tool's behavior (e.g., lookback window for insiders, limit for market mode, and how `ticker` switches mode). This adds practical context 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 states it finds agreement among insider, institutional, and congressional signals, and distinguishes per-ticker vs market-wide modes. It is specific about the resource (confluence signals) and action (join/agree). However, the phrasing 'the moat join' is jargon-heavy, slightly reducing clarity.

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 explicitly covers when to use `ticker` (per-name analysis) vs omitting it (market-wide ranked list), and explains the default parameters and qualifiers like `min_funds` and `min_insiders`. It also warns about no fuzzy matching, giving clear operational 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 annotation readOnlyHint=true already indicates no side effects. The description adds behavioral context: it aggregates data from all tracked funds, ranks by number of funds agreeing, and surfaces consensus on holdings or changes. This goes beyond the annotation.

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

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

Two sentences, no wasted words. The first sentence states the primary purpose and lists modes; the second provides a key differentiator. Information is front-loaded and structured.

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

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

For a simple tool with two parameters, good annotations, and a clear description, it is largely complete. No output schema exists, but the description implies ranked results by number of funds. Minor gap: it doesn't specify the exact output fields, but that is acceptable given the context.

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 both parameters. The description adds meaning for the mode parameter by explaining the three enum values ('held=consensus longs, bought=cluster-buys, sold=cluster-exits'). For limit, it restates the schema's range but provides no new info.

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 'Cross-fund smart money consensus' and enumerates three modes (held, bought, sold) with specific meanings. It distinguishes itself from sibling tool stock.owners by stating 'The inverse of stock.owners'.

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 what each returns, helping the agent decide which mode to use. It also mentions it's the inverse of stock.owners, providing differentiation. However, it does not explicitly list conditions for when to use this tool versus other siblings like signal.confluence.

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 declare readOnlyHint=true, and the description aligns by describing a query operation. The description adds that data is from 13F filings but doesn't disclose other behaviors like pagination or rate limits.

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

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

Two sentences, no fluff. The first sentence provides the core purpose, and the second adds context. Highly concise and well-structured.

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

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

With no output schema, the description adequately explains the return fields (funds, position value, share count, change). It covers the essential aspects needed for an agent to understand the output. Slight lack of mention of default behavior for limit, but minor.

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 both parameters. The description does not add additional meaning beyond highlighting that ticker is the main input and implicitly that limit controls results. Baseline score 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 clearly states it retrieves institutional (13F) owners of a stock by ticker, including position value, share count, and change. This is specific and distinguishable from sibling tools like fund.holdings, which show holdings of a fund.

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 indicates it is used to find 'who owns this stock' across tracked funds, which implies usage context. However, it lacks explicit when-to-use vs alternatives or when-not-to-use guidance for the agent.

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 it as read-only. The description adds valuable behavioral context: cursor-based pagination, freshness guarantees, and that each event includes an SEC source URL. No contradictions.

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

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

Two well-structured sentences cover purpose, usage, and behavior without any wasted words. Front-loaded with the core action.

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 no output schema, the description hints at response content (SEC source URL) and cursor usage but does not explicitly mention the next_cursor field in the response. Still fairly complete for a polling tool.

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 clearly explains the `since` parameter as a cursor from a prior response and reinforces its purpose for incremental polling. It adds meaning beyond the schema, which already has 100% coverage but lacks usage context.

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 verb 'poll', the resource 'workspace's watchlist', and the specific filings (Form 4/8-K/13D-G). It distinguishes from the sibling 'watchlist.poll.live' by noting 'Standard (delayed, ≤24h-old) freshness'.

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 how to use the cursor parameter for incremental polling ('built for a watch loop') and mentions dashboard curation. However, it does not explicitly contrast with the live sibling or list alternatives, leaving some usage ambiguity.

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 readOnlyHint=true. The description adds context about premium pricing, plan requirements, and data freshness normalization, which are behavioral traits not captured by annotations. No contradictions.

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

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

Two concise sentences that efficiently cover purpose, freshness, pricing, plan requirements, sibling comparison, and scope. No wasted 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?

The description covers purpose, usage, restrictions, and relationship to sibling. It could mention return format or pagination behavior, but given read-only nature and simplicity of parameters, it is largely complete.

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

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

The input schema covers both parameters with clear descriptions, achieving 100% schema coverage. The description does not add new parameter details beyond referencing cursor semantics, so baseline score 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 clearly states the tool polls for live watchlist events with minute-fresh SEC filings. It distinguishes itself from the sibling 'watchlist.poll' by emphasizing 'LIVE freshness', making its 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?

The description explicitly states when to use this tool (for live, minute-fresh data) and when to use the sibling tool (for delayed data). It also notes the premium pricing and required plans, providing clear usage context.

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