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 already note readOnlyHint=true. Description adds value by explaining that the tool returns a filing index + PDF link and that transaction line-items live in the PDF, which goes beyond the annotation alone.

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

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

Two sentences, front-loaded with the main purpose, then additional details. Every word adds value with no redundancy.

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

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

Despite no output schema, the description explains the return structure (filing index + PDF link) and hints at where to find transaction details, providing sufficient context for a list tool with four parameters.

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 parameters with descriptions. The description adds extra context for filingType (explaining 'P' means Periodic Transaction Report) and mentions default limit (50) and max (200), which are not in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists US House financial-disclosure filings for a year, specifying the STOCK Act context and defining filingType 'P' as Periodic Transaction Report. It distinguishes itself from sibling tools like congress.member.search.

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

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

No explicit guidance on when to use this tool versus alternatives, no when-not-to-use instructions, and no mention of prerequisites or preferred contexts.

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 aligns with the readOnlyHint annotation, confirming a read-only query. However, it adds no additional behavioral context beyond what the annotation already provides, such as rate limits or scope restrictions.

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 waste. It is concise, though slightly more detail (e.g., expected output) could improve it without sacrificing brevity.

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 lack of output schema, the description does not explain what the tool returns (e.g., member names, IDs, filing details). For a simple search tool, this is a notable gap, as the user cannot anticipate the response format.

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 both parameters with 100% coverage. The description adds minimal value by restating the parameter concept ('by name') and the default year (2024), which is also in the schema. It does not compensate for any missing schema 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 tool's purpose: finding US House representatives by name who filed financial disclosures in a given year. It uses a specific verb ('Find') and resource ('US House representatives'), and the context of financial disclosures distinguishes it 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 implies the tool is for searching by name, but it does not explicitly guide when to use this tool versus alternatives like congress.disclosures.list. No when-not or exclusion criteria are provided, relying on the user to infer the use case.

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 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?

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?

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 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 declare readOnlyHint=true. The description adds useful context: the join logic, source provenance for each leg, no fuzzy name matching, and the two modes. No contradiction. Could mention rate limits or auth needs, but not critical given 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 core purpose. Every sentence adds essential information. No filler or repetition.

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 input side is well-covered with explanation of the join and modes. However, the output structure is not described (e.g., what does the 'confluence verdict' look like? How is the market-wide list ranked?). With no output schema, this is a gap for an agent to understand the return value.

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 high. The description adds value by explaining the dual-mode behavior and the role of 'ticker' as optional. It also clarifies that 'min_funds' and 'min_insiders' are thresholds for market mode, which are not obvious from 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 specifies a unique verb-resource combination: joining insider (Form 4) and institutional (13F) signals. It clearly distinguishes from sibling tools like 'insider.clusters' or 'fund.holdings' and explains both per-ticker and market-wide modes.

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 clearly explains when to use with a 'ticker' (per-name analysis) and without (market-wide list). It also states the join is on ticker, not fuzzy match. However, it does not explicitly mention when not to use this tool (e.g., if only insider data is needed, use 'insider.clusters').

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?

Beyond the readOnlyHint annotation, the description adds critical behavioral details: data freshness (minute-fresh, within minutes of SEC acceptance) and premium pricing. No contradictions 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 sentence that front-loads the key differentiator ('LIVE freshness') and efficiently packs scope, freshness, pricing, and cursors without 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?

No output schema, so description should ideally describe return values. It implies return of filings but doesn't detail structure. References sibling for cursor semantics, but could be more explicit about output shape. Loses a point for slight incompleteness.

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

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

Schema coverage is 100%, so the schema already documents both parameters. The description adds no new parameter meaning beyond referencing sibling cursor semantics, which is helpful but not additional semantics.

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 is like watchlist.poll but with 'LIVE freshness', specifying it includes filings accepted within the last 24 hours, minute-fresh. It distinguishes itself from the sibling watchlist.poll by emphasizing real-time data.

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 mentions 'Premium-priced' and contrasts with watchlist.poll, guiding when to use this tool for the freshest data. It also notes same scope and cursor semantics, providing clear alternatives.

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