Cabrini MCP

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

With no annotations provided, the description carries the full transparency burden. It discloses the exact data fields returned (OHLC, fractional change from daily open, volume, transactions) and the cost per day, which is valuable. It does not cover pagination or the date vs. range distinction, but those are addressed in the schema.

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

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

The description is three concise sentences, each providing essential information: the tool's function, the structure of returned bars, and the pricing. It is front-loaded and contains 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?

There is no output schema, so the description adequately explains the return value structure (OHLC plus additional fields) and the cost. It does not mention the 'adjusted' parameter's runtime behavior, but that is documented in the input schema. Overall, it is sufficiently complete for an agent to decide when to use it.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds the constraint that it works for one ticker and repeats the allowed intervals, but it does not clarify the relationship between date, start, and end parameters. It provides minimal added meaning 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 that this tool returns resampled intraday bars at specific custom timeframes for a single ticker, listing the exact intervals. This distinguishes it from siblings like query_minute_bars or query_daily, making the purpose unambiguous.

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

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

The description implies usage for resampled intraday bars at custom intervals, providing clear context about what the tool does. However, it does not explicitly mention when to prefer this over alternatives like query_minute_bars, nor does it state any exclusions or prerequisites.

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 the $0.25 USDC cost, which is a meaningful behavioral trait, but with no annotations it carries the full burden of behavioral disclosure. It does not explain the output structure, whether the price data is a time series or snapshot, or how the four components are combined. Significant behavioral details remain hidden.

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 short sentences, with the core content ('Full research brief') and key qualifiers (components and cost) stated up front. There is no fluff 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?

As a paid composite tool with no output schema, the description should cover the response format and usage trade-offs compared to individual data tools. It only lists high-level components and cost, leaving the agent to guess what 'brief' contains structurally and when it is advantageous to 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 provides 100% coverage of all three parameters (ticker, date, lookback_days) with descriptive text, so the baseline is 3. The description adds no extra meaning beyond naming the data components; it does not map those components to specific parameters or explain interactions.

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 it returns a 'Full research brief' composed of price, fundamentals, insiders, and splits for one ticker. This distinguishes it from sibling tools like get_pricing or get_insiders, which each cover only one aspect. The missing explicit verb is compensated by the tool name 'get_brief'.

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 guidance is provided on when to use this composite brief versus calling individual sibling tools (e.g., get_fundamentals, get_insiders). The description does not mention prerequisites, alternatives, or exclusions. The only additional context is the cost and the single-ticker restriction.

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?

With no annotations provided, the description carries the burden of behavioral disclosure. It adds the cost ($0.005 USDC) and the specific fields returned, which are useful. However, it does not disclose details like authentication, error handling, or the format of the response, though as a read-only tool the risk is lower.

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 extremely concise: two clauses that clearly list the return fields and the cost. It is front-loaded with the core purpose and contains no unnecessary words 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?

For a simple one-parameter lookup tool, the description is quite complete. It lists the expected output fields and the cost, which are the most relevant operational details. It does not explicitly state the response format (e.g., JSON), but this is standard and not critical. Given the simple nature and absence of an output schema, 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?

The schema already fully documents the ticker parameter with an example (100% coverage), so the description doesn't need to explain the parameter itself. The description indirectly clarifies that the ticker is used to fetch the listed profile fields, which provides context but no additional syntactic or semantic detail beyond the schema.

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

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

The description clearly identifies the tool as returning a company profile with specific fields (name, CIK, industry, exchange, fiscal year), which distinguishes it from siblings like get_filings or get_fundamentals. However, it uses a noun phrase rather than a verb like 'retrieves' or 'gets', though the tool name provides the action.

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 when company profile data is needed by listing the fields, but it provides no explicit guidance on when to use this tool over alternatives. No alternatives are referenced, and no exclusions are stated.

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

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

No annotations are provided, so the description carries the full burden. It discloses pricing ($0.01, $0.05 with sections) and the section-extraction behavior (from latest 10-K/10-Q). However, it does not mention default response shape, pagination, or potential side effects—though the tool is clearly 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?

Two sentences, front-loaded with the core purpose, followed by cost and optional features. No redundant or vague wording—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?

With 6 parameters and no output schema, the description covers the key decision points (what tool is for, how to get sections, costs). It does not describe the structure of the returned index, but that is not essential for tool selection and invocation. The schema fills parameter-specific 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 each parameter described. The description adds meaningful context beyond the schema by explaining the pricing implications of sections and that sections extract from the latest filing unless an accession is specified. This enriches parameter understanding.

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 provides an SEC filing index (10-K, 10-Q, 8-K, proxies) for a ticker, with an optional section-extraction capability. This distinct resource and action sets it apart from sibling tools like get_bars or get_fundamentals.

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 context for when to use the tool (filing lookups) and even explains how to use sections for full-text extraction. It does not explicitly mention alternatives or when not to use it, but the niche purpose is self-evident 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the data source (SEC EDGAR), quarterly frequency, and a $0.02 USDC cost, but does not explain return format, filtering behavior, date inclusiveness, or any side effects. This is a sparse disclosure for a tool that could involve external API calls and cost.

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 purpose, gives concrete examples, and includes a relevant cost detail. Every part earns its place, and there is no verbose or redundant text.

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 is adequate for a simple data-retrieval tool, but it lacks several contextual details that would help an agent invoke it correctly: what the response shape is, whether all metrics are returned by default, and how date filtering interacts with quarterly data. Given the absence of an output schema and annotations, the description leaves meaningful 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 description coverage is 100%, providing baseline clarity for all four parameters. The description adds value by naming example metrics (revenue, EPS, margins) that clarify what 'fundamentals' means and thus what the 'metrics' filter likely accepts, but it does not elaborate on date parameters or whether to_date/from_date are optional.

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

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

The description clearly identifies the tool as providing quarterly fundamentals from SEC EDGAR, with examples (revenue, EPS, margins) that make the resource specific. It distinguishes from siblings like get_stats or get_company by naming the data source and frequency, though it lacks an explicit action verb like 'get' or 'retrieve'.

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 no guidance on when to use this tool versus alternatives such as get_stats, get_company, or get_filings. There is no mention of preferred use cases, exclusions, or when another sibling would be more appropriate. The only contextual hint is that it is specifically for SEC EDGAR fundamentals.

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?

With no annotations provided, the description carries the full disclosure burden. It mentions the cost ($0.02 USDC), which is useful, but does not describe data freshness, pagination, rate limits, return format, or any other behavioral traits. For a read operation, it omits safety and limitation details.

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 filler. It conveys the tool's function and pricing efficiently, and every word earns its place. Structure is front-loaded with the primary purpose first.

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 should clarify what data will be returned. It only states 'insider transactions (Form 4)' without indicating the fields, structure, or any caveats. Given the tool's simplicity, some indication of expected output or limitations is necessary for 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 each parameter (ticker, from_date, to_date) is already described in the schema. The tool description adds no additional parameter semantics beyond the overall purpose, providing no extra value. Baseline 3 is appropriate given full schema coverage.

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

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

The description specifies 'Insider transactions (Form 4) from SEC EDGAR', clearly indicating a verb-like action (get) and a specific resource (insider transactions) with a source. This distinguishes it from sibling tools like get_bars or get_filings, which address different data types.

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 no explicit guidance on when to use this tool versus alternatives. It neither mentions alternative tools nor provides contextual cues about when insider transaction data is needed. Usage is only implied by the tool's name and purpose, which is insufficient per the rubric.

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?

With no annotations, the description carries the full burden. The word 'Free' adds a minor note about cost, but it does not disclose other behavioral traits such as whether the tool is read-only, requires authentication, or returns specific structures. The description is overly minimal for a tool with no schema details.

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 extremely short and every word is concise, but the fragment 'Free.' is somewhat extraneous. It is not structured or front-loaded, but there is little content to structure. It earns a 4 for being efficiently sized.

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

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

The tool has no parameters and no output schema, so the description should explain what the tool returns or covers. It only says 'Pricing and data coverage information,' which is vague and does not clarify whether this is general information or ticker-specific. Given the sibling tools, this lacks essential context for an agent to know when and how to invoke it.

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 zero parameters, so there is no parameter information to supplement. The baseline of 4 applies because the description does not need to explain parameters, and it does not mislead.

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 'Pricing and data coverage information,' which identifies the subject matter but lacks a verb phrase. It is more descriptive than tautological, but it doesn't clearly specify what the tool does (e.g., 'retrieves pricing plans') and does not differentiate it from sibling tools like get_stats or get_bars.

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 guidance is provided on when to use this tool versus alternatives. The phrase 'Pricing and data coverage information' implies a use case, but there is no explicit context, exclusions, or mention of sibling 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?

With no annotations, the description fully discloses behavioral traits: it is free ('FREE, no payment'), returns real data ('real intraday OHLCV bars'), and produces output identical to a paid query. It also notes it takes no arguments, providing complete cost and data authenticity expectations.

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

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

The description is three short sentences, each earning its place: it states the data delivered and cost, instructs when to use it, and clarifies the parameter constraints. 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 the tool's simplicity (zero params, no output schema), the description is complete: it covers purpose, cost, usage timing, and limitations. The reference to 'OHLCV' implies the standard return fields, making it sufficient for an agent to select and invoke the tool correctly.

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

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

Although the schema is empty, the description adds meaningful semantics by explicitly stating 'Takes no arguments — fixed ticker and date' and naming the fixed values (AAPL, 2024-01-02), which the schema cannot convey. This exceeds the baseline for zero-parameter tools.

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 what the tool does: it returns real intraday OHLCV bars for AAPL on 2024-01-02. It distinguishes itself from sibling tools by explicitly being a free, fixed-parameter sample identical in shape to a paid query, which is a distinct resource.

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

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

It provides explicit when-to-use guidance: 'Call this first to verify data quality before spending.' This tells the agent to use it as a trial before using paid queries, and the fixed ticker/date limitation implies it is not for arbitrary queries.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Free' and 'Platform statistics,' with no mention of return format, data source, side effects, or limitations. This is extremely lacking and does not inform the agent about what happens when the tool is invoked.

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 extremely short but under-specified to the point of being a fragment. 'Free' appears as an unrelated addition and does not help clarify the tool's purpose. This is not concise writing; it is incomplete writing.

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 annotations, no output schema, and a minimal description, the tool definition is incomplete. Given the sibling tools are data-focused, it is unclear what 'platform statistics' refers to or what the agent can expect. The description offers no context for correct usage or interpretation of results.

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 is empty with zero parameters, so there is nothing to explain. The baseline score for 0 parameters is 4, and the description correctly does not need to add parameter details. No additional parameter semantics are needed.

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 'Platform statistics. Free.' is a noun phrase with no verb, so it doesn't explicitly state an action. It vaguely refers to platform-level statistics but does not distinguish itself from sibling tools like get_bars or get_filings. It essentially restates the tool name without adding specific functionality.

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?

There is no guidance on when to use this tool versus alternatives, no examples, and no mention of prerequisites. The only extra information is 'Free,' which relates to cost, not usage context. This provides no help for an AI agent deciding between get_stats and its 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?

With no annotations, the description carries the full burden. It adds a cost disclosure ($0.005 USDC) and specifies 'all tickers' implying broad scope, but does not mention return format, pagination, or any limitations. For a simple list operation, this is adequate but not rich.

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 one concise sentence plus a cost note. It is front-loaded with the action and resource, and every word adds value. No redundancy or unnecessary detail.

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

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

Given the tool's simplicity (one parameter, no output schema, no annotations), the description is nearly complete. It explains the purpose and cost, and the schema handles the parameter format. It could mention the return type (ticker symbols) but that is implied by the name.

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 description for 'date' is 'YYYY-MM-DD', which fully describes the expected format. The tool description does not add further semantic meaning 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 a specific action ('List all tickers') with a resource ('tickers') and a scope condition ('that traded on a given date'). This distinguishes it from sibling tools like get_pricing or get_company, which focus on different data types.

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 no guidance on when to use this tool versus alternatives. It does not mention any exclusions or specific use cases, leaving the agent to infer appropriate usage from the tool name and 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?

No annotations are provided, so the description carries the full burden. It discloses the output format (absolute OHLC and fractional change from the daily open) and pricing ($0.02/ticker, no limit), which is valuable context. It does not cover errors or permissions, but for a read-only batch query this is adequate and goes beyond the schema.

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

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

The description is two sentences with no filler. It front-loads the core purpose, then adds output details, then pricing. Every sentence adds essential information, achieving maximum efficiency.

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's explanation of bar fields fills the gap by telling the user what to expect in the response. It also covers pricing and limits. It does not specify the exact response grouping or error behavior, but for a simple batch query, the description is 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?

The schema already covers both parameters with descriptions, so the baseline is 3. The description adds meaning by clarifying there is no limit on the number of tickers, a constraint not present in the schema, and reinforces that the date is a single day. This is meaningful 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 states that the tool handles multiple tickers for a single date, which is a specific and distinct use case. This clearly differentiates it from sibling tools like query_range or query_daily that cover ranges or single tickers. The mention of OHLC and fractional change further specifies the output, making the purpose unambiguous.

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

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

The description implies usage when the user needs data for several symbols on one specific date, and the 'no limit' note suggests batch queries. It does not explicitly name alternatives or say when not to use it, but the 'one date' constraint provides clear contextual scoping against other query 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?

With no annotations provided, the description carries full burden. It discloses the data content, defines derived metrics (range_pct and true_range_pct), notes the one-ticker limitation, and states cost ($0.001/year) — valuable behavioral context beyond the schema.

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

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

Four sentences, each earning its place: core purpose, formula clarifications, use-case/cost context. No redundant or vague language. Front-loaded with the essential 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 3-parameter data-retrieval tool with no output schema, the description is complete enough: it specifies the data returned, the computed metrics, the single-ticker scope, and pricing. It lacks explicit error handling or response format, but the given context does not demand it.

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 explains ticker, start, and end fully. The description does not add meaning to the parameters themselves; it only describes output fields, which is not part of parameter 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 the tool returns daily OHLCV bars with additional VWAP and volatility metrics for one ticker over a date range. It effectively distinguishes from siblings by specifying 'one ticker' and 'Daily' vs minute/batch 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?

It implies when to use this tool by noting 'Day-level aggregates — the cheapest way to cover long histories' and 'one ticker', contrasting with broader or more granular alternatives. However, it does not explicitly name sibling tools or exclusions, so slightly below the highest bar.

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?

With no annotations provided, the description carries the full burden. It discloses key behaviors: returns a full trading day of bars, each bar contains absolute OHLC plus pct-change fields, volume, and transactions. It also discloses the cost ($0.025 USDC). This goes beyond simple data retrieval by explaining return structure and pricing, though it doesn't mention rate limits, timezone, or market session specifics.

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 pack all essential information: scope, interval, default, data fields, and cost. The opening phrase 'Full trading day of intraday bars' immediately captures the tool's core purpose. No irrelevant details 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?

With no output schema, the description effectively explains the return format (OHLC, pct fields, volume, transactions) and also mentions pricing. It covers the main contextual needs for a data retrieval tool. Minor gaps like timezone handling or market session definition prevent a 5, but overall it is complete for typical usage.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by stating 'full trading day' (clarifying that 'date' means a single trading day) and 'one US stock' (context for ticker). It also previews interval range and default, which the schema already covers. This marginal addition justifies a slight upgrade.

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 'Full trading day of intraday bars for one US stock', specifying the verb (query/returns), resource (minute bars), and scope (one US stock, interval 3-240 min). It distinguishes from siblings like query_daily or get_bars by emphasizing 'intraday' and 'full trading day', making the tool's unique purpose explicit.

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

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

The description provides clear context: use this for intraday bars with configurable interval, defaulting to 3 minutes, for a single US stock on a specific date. While it doesn't explicitly name alternatives or exclusions, the scope ('full trading day', 'one US stock') implicitly differentiates from range/daily tools. It lacks an explicit 'use this instead of X' statement, so it falls short of a 5.

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

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

With no annotations, the description carries the full burden. It discloses a key behavioral detail: fractional change is calculated from that day's own open and resets daily, not cumulative. It also states the cost and no day limit, but omits result format, timezone, 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?

The description is exceptionally concise, using three sentences to cover the core purpose, data semantics, and pricing. It is front-loaded with the main use case and contains no fluff or repeated schema content.

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

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

Given no output schema or annotations, the description does a solid job explaining the data content (OHLC plus daily-reset fractional change) and the query scope. It omits minor details like date inclusivity or timezone handling, but is adequate for tool selection and invocation.

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

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

Schema coverage is 100%, so all parameters are already documented in the input schema. The description adds only a summary of interval range and default, which duplicates the schema's enumerated list, providing no significant extra 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 identifies the tool as providing multi-day intraday bars for one ticker, with interval range and default specified. It distinguishes from sibling tools by scope ('one ticker', 'multi-day') but lacks an explicit action verb like 'returns' or 'fetches'.

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 context for when to use the tool: for multi-day intraday bars for a single ticker, with pricing and no day limit. It does not explicitly name alternative tools or exclusion criteria, but the scope is strongly implied.

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

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

With no annotations, the description discloses key behaviors: it lists the exact return fields (pct_change, range_pct, pct_gap, true_range_pct, volume, volume_ratio), clarifies unit conventions (criteria in percent, outputs fractional), and notes the cost ($0.10 USDC). This goes beyond the schema, though it does not mention 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?

The description is three sentences, each conveying essential information: purpose, return fields, and unit/cost details. It is front-loaded, efficient, and contains no redundancy or filler.

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

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

Given no output schema and no annotations, the description compensates by listing the return fields and unit conventions. It covers the main use case (custom criteria, date-based scan) and cost, but lacks details on pagination or edge cases like conflicting criteria. The schema covers parameter meanings and default limit, so overall it is fairly 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 schema already documents all 9 parameters with descriptions (100% coverage), providing a baseline of 3. The description adds valuable cross-parameter context: criteria are in percent (5 = 5%) while outputs are fractional (0.05 = 5%), which clarifies unit conversions not fully evident from 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 clearly states 'Scan all US stocks on a date for custom criteria (gaps, volume, change)', identifying the exact action and scope. It distinguishes from sibling data-retrieval tools by focusing on market-wide screening rather than per-ticker queries.

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 for when to use this tool: when you need to screen all US stocks on a specific date with custom criteria. It does not explicitly mention alternatives, but the market-wide scope inherently contrasts with sibling tools like get_bars or query_range, making the intended usage evident.

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