Autario Data Analytics Platform

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

Annotations indicate readOnlyHint, idempotentHint, and destructiveHint false, so behavior is safe and non-destructive. Description adds that results are deterministic, based on real SEC filings and market data, unknown tickers fetched live, and includes inline chart and shareable link. 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 overly verbose, containing multiple paragraphs and promotional language (e.g., 'deterministic, verifiable MULTI-YEAR valuation brief'). While front-loaded with purpose, it could be significantly shortened without losing 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?

No output schema exists, but description thoroughly explains return values: text valuation block, inline chart image, shareable view_url. It also details how parameters control the view and provides examples. Complete for the complexity.

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?

Input schema covers all 5 parameters with descriptions (100% coverage). Description adds some context (e.g., metric choices, default chart_type is smart choice) but does not significantly enhance beyond schema. Baseline 3 due to high 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 clearly states the tool checks if a US stock's price is backed by fundamentals by overlaying price against a SEC-reported fundamental, returning a multi-year valuation brief. It distinguishes from siblings like compare_entities or get_company_snapshot through its specific purpose and includes examples.

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 lists when to use the tool (e.g., queries about bubbles, overvaluation, history comparisons) and provides multiple examples. However, it does not explicitly state when not to use it or suggest alternative tools 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?

Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds valuable transparency: it notes the return structure ('per-timepoint result + summary') and details the 'full' parameter behavior, including token implications. 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 with no fluff. First sentence states purpose and operations; second sentence gives examples and mentions return. Every sentence adds value.

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

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

Given 6 parameters and no output schema, the description covers the main inputs, operations, return value, and the 'full' parameter behavior. It lacks details on the 'time' and 'entity' parameters and the exact format of the summary, but is reasonably complete for most use cases.

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 33% (only 'op' and 'full' have descriptions). The description explains that 'a' and 'b' are indicators and lists operations, but does not describe 'time' or 'entity' parameters. While it partially compensates for low coverage, it leaves gaps for required 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 creates a derived series from two indicators using specific Excel-style operations (ratio, ratio_pct, diff, sum, product). It provides concrete examples like debt-to-GDP ratio, which differentiates it from sibling tools like correlate or regression.

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

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

The description gives explicit use cases ('Use for things like debt-to-GDP ratio, revenue-per-employee, spread between two yields'), guiding when to apply. It does not mention when not to use or alternatives, but the examples are sufficient.

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

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

Annotations already declare read-only, non-destructive, and idempotent. The description adds valuable detail on the output contents (chart_type enum, fields, palette, axis-override, annotation format, examples) and instructs to call once per session, reinforcing idempotency. 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?

Three efficient sentences: first states purpose and output content, second gives usage guidance, third provides rationale. No redundant or missing 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 parameterless read-only tool, the description fully covers what it does, what it returns, and how to use it. No output schema is provided, but the description lists return contents, making it 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?

Input schema has zero parameters, so baseline is 4. No additional parameter info needed, and the description doesn't attempt to describe 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 verb 'Get' and the resource 'Builder spec schema reference', listing specific return items (chart_type enum, fields, etc.). It distinguishes itself from siblings like create_chart_from_spec by noting that the returned spec is the input shape for that tool.

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 call this once at session-start and explains that it provides the input shape for create_chart_from_spec. Additionally mentions it's cheaper and clearer than guessing Plotly JSON, offering a clear rationale 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 convey destructive and idempotent nature. The description adds useful context: preserving schema/columns and requiring AUTARIO_API_KEY, enhancing transparency beyond annotations.

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

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

Two concise sentences, front-loaded with the primary action, no unnecessary words.

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

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

For a simple destructive tool with one parameter and no output schema, the description covers action, effect, use case, and prerequisite completely.

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

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

The single parameter dataset_id is fully described in the schema (100% coverage). The description adds no extra meaning beyond restating the parameter's role.

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-resource combination ('Delete all rows from a dataset') and explicitly distinguishes itself from sibling tools like delete_dataset by stating it keeps schema and columns intact.

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 a clear use case ('refreshing data before re-importing') and a prerequisite (API key), but does not explicitly exclude scenarios or name alternative tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so no contradiction. The description goes beyond by explaining the default output (per-entity summary with stats, row_count, x_range) and the effect of full=true (heavy pivot data). It discloses the cost of full (heavy, many tokens), which is valuable behavioral context.

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

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

The description is a single, well-structured paragraph that front-loads the core purpose and flows logically. Every sentence earns its place: purpose, default behavior, full option, and usage scenarios. 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 complexity (comparing across entities with optional detailed output), the description effectively covers return structure (summary vs pivot), parameter options, and use cases. No output schema exists, but the textual description compensates by describing what the agent gets. Completeness is very high.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining how the 'full' parameter transforms the output and the purpose of the default behavior. It also provides concrete examples for 'entities' (e.g., ['DEU','USA','CHN']). This adds value beyond the 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 specifies a clear verb+resource+scope: 'Compare ONE indicator across MULTIPLE entities' with concrete examples (GDP of DEU vs USA vs CHN). It distinguishes this from siblings like 'get_entity_data' by emphasizing cross-entity comparisons for a single metric.

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: 'country comparisons, cross-region analyses, or any chart that compares the same metric across entities.' Also provides guidance on when to set full=true vs default (default enough for answering questions, full only for plotting/export). Does not mention alternatives but the context is clear 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 declare the tool as read-only, idempotent, and non-destructive. The description adds beyond that by specifying the return values (r, p-value, n, human-readable interpretation) and the automatic causation disclaimer, providing useful behavioral context.

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

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

Two sentences: the first clearly states the action and output, the second adds usage guidance and a behavior note. No fluff, front-loaded with the core functionality.

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

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

Given no output schema, the description adequately describes the return values. It covers the main purpose and usage, but lacks details on edge cases or prerequisites (e.g., data availability, frequency alignment). Still, it is sufficient for an agent to decide and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add any additional parameter meaning beyond what is already in the schema; it only summarizes the overall purpose.

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

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

The description clearly states the tool computes Pearson and Spearman correlation between two indicators for one entity, specifying the statistical methods. It distinguishes from sibling tools like regression or lag analysis by focusing on simple correlation and explicitly mentioning "does X move with Y?" questions.

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 a clear usage context: "Use for 'does X move with Y?' questions." It also mentions the automatic causation disclaimer, hinting at when not to use (not for causal inference). However, it lacks explicit exclusions or comparisons to alternative 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?

Annotations indicate non-read-only and non-destructive behavior. The description adds behavioral context: automatic and non-overridable brand attribution, and that hallucinated numbers return 422 with available anchor list. No contradictions. It does not explicitly state if the chart is persisted or if there are side effects on datasets, but the provided context is sufficient.

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

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

The description is dense but well-structured. It front-loads 'PREFERRED chart-creation path' and gradually builds detail. Every sentence adds value, though some clauses could be tightened. The length is justified given the complexity of the tool, but a slight trim would improve conciseness.

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 with nested objects, no output schema, and moderate complexity, the description covers prerequisites (call chart_instructions first), data citation rules, error behavior (422 on hallucinated numbers), and brand attribution limitations. The lack of output schema is acceptable. It feels complete for an agent to select and invoke correctly.

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

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

Schema coverage is 100%, but the description adds substantial value beyond the schema. For example, the 'title' parameter gets detailed formatting rules (year range, unit, examples). 'insight' warns against hallucinated numbers. 'builder_spec' lists required and optional fields. This enhances understanding beyond the basic 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 it is the 'PREFERRED chart-creation path' and uses a structured Builder spec. It contrasts with publish_chart for advanced cases, and distinguishes itself from sibling tools like bubble_or_not, chart_instructions, etc. The verb 'create' along with resource 'chart from spec' is specific and unambiguous.

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

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

The description explicitly guides when to use this tool: 'PREFERRED chart-creation path' and advises to fall back to publish_chart for advanced Builder-incompatible cases. It also recommends calling chart_instructions() first if unsure of spec shape. This provides clear contextual usage and alternatives.

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

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

Annotations already indicate readOnlyHint=false and destructiveHint=false, so the creation side effect is expected. Description adds the authentication requirement and the workflow hint about populating with write_rows.

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, dense with information, no filler. Front-loaded with action and return 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?

Covers creation, return value, workflow step, duplicate avoidance, and authentication. Minor gap: no mention of error handling for duplicate titles.

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?

Input schema has 100% coverage with detailed descriptions for all 4 parameters. The description does not add additional meaning beyond what the schema provides. 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?

Clearly states it creates a new empty dataset on Autario and returns a dataset_id. Distinguishes from sibling tools like delete_dataset or search_datasets.

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 a clear 'when not to use' instruction ('Only create new datasets if the data does not already exist on Autario') and mentions the required API key. Could be improved by explicitly suggesting to search first.

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 context beyond annotations: irreversibility, ownership requirement, and API key necessity. Annotations already indicate destructiveHint=true, but description specifies who can delete and the authentication requirement, which are valuable for agent behavior.

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

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

Three concise sentences, each adding essential information: action, consequence, and access constraints. No redundant content. Front-loaded with the core purpose.

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

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

For a simple destructive tool with one parameter and no output schema, the description covers all critical aspects: what it does, permanence, ownership, and authentication. It could mention the success response (e.g., returns empty), but that is not essential given no output schema.

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

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

Only one parameter (dataset_id) with 100% schema coverage. The description does not add extra meaning beyond the schema's description of the parameter as 'the UUID of the dataset to permanently delete'. Baseline of 3 is appropriate as schema covers the parameter well.

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 action (permanently delete) and resource (dataset and all its data). It distinguishes from siblings like 'clear_rows' by specifying full deletion of the dataset, not just data clearing.

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

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

Provides explicit usage guidance: action is irreversible, only dataset owner can perform it, and requires AUTARIO_API_KEY. No direct comparisons to siblings, but the destructive nature and access restrictions are clearly communicated.

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 readOnly, idempotent, non-destructive behavior. The description adds value by detailing the output statistics (histogram, quartiles, etc.), which is beyond annotations. No contradictions.

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

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

Two sentences, no fluff. The first sentence states the output, the second gives usage advice. Perfectly front-loaded and 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?

Lacks output schema but description lists returned statistics. Missing explanation of the 'time' parameter and potential edge cases, but overall adequate for a read-only summary 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 coverage is 0% and description only mentions 'indicator+entity' but fails to describe the 'time' parameter, which is optional but unexplained. The description partially compensates for entity and indicator but is incomplete.

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 computes summary statistics for a single indicator and entity, listing specific statistics (n, mean, median, etc.). This distinguishes it from sibling tools like calculate or correlate which perform different operations.

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 advises 'Use FIRST before running any test' to understand data characteristics, providing clear context for when to employ this tool relative to other analytical 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?

Goes beyond annotations with detailed ranking logic (tier_1 source quality, coverage, recency) and quality gates, plus mentions result content (tagline + sample facts).

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?

Concise at ~100 words, front-loaded with purpose and usage, then ranking details; 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?

Complete for a discovery tool: explains what it returns, ranking criteria, and usage guidance. No output schema, but description covers result content adequately.

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

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

Schema coverage is 100%, and description adds contextual examples for topic and explains depth_pref/recency_window implications for trend vs. snapshot articles, slightly exceeding baseline.

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

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

Clearly states it discovers relevant verified datasets for a topic, distinguishing from siblings like query_dataset and search_datasets.

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

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

Explicitly says 'Use this when starting an article, dashboard, or analysis on a topic' and suggests picking top 3-5 without further round-trips, providing 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 indicate a safe read-only, idempotent tool. The description adds behavioral details: returns r, p-value, R² values, and a maximum of 30 candidates per call, which enhances transparency beyond 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 extremely concise: two sentences that efficiently convey purpose, use case, output details, and constraints. 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?

Despite no output schema, the description fully explains the return values (r, p-value, R²) and constraints (max 30 candidates), making the tool's behavior completely understandable 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?

The input schema covers 75% of parameters with descriptions. The description adds value by explaining the candidates array's maximum size (30) and clarifying the overall purpose of target_indicator and candidates, complementing 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 explicitly states the tool's purpose: ranking candidate indicators by correlation strength against a target KPI. It uses specific verb+resource: 'rank which candidates best predict the target', distinguishing it from siblings like 'correlate' or 'regression'.

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 usage context: 'Perfect for "what moves my KPI?" questions.' It implies suitable scenarios but does not explicitly state when not to use it or mention alternatives among siblings.

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

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

Annotations already declare readOnlyHint and idempotentHint, but the description adds valuable behavioral context: the tool returns a compact summary (not full data), describes the per-series summary contents, and provides a shareable URL. 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 paragraph but is information-dense without fluff. It could benefit from brief bullet points for readability, but overall it's concise and 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?

Despite lacking an output schema, the description thoroughly explains the response structure and the shareable URL. For a read-only tool with comprehensive annotations, the description is complete and leaves no ambiguity about what to expect.

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 both parameters. The description adds minimal extra meaning beyond mentioning the default 'toon' format, which is already in the schema enum. 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 'Get a specific chart by ID or slug' and specifies what the response includes (compact summary) and excludes (raw Plotly spec, full data arrays). It distinguishes this tool from siblings like 'list_charts' by focusing on a single chart retrieval with a token-bounded summary.

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

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

The description explains when to use this tool (to get a specific chart) and provides guidance on the format parameter for token efficiency. It directs users to view_url for the full interactive chart, implying when not to use this tool. However, it does not explicitly contrast with alternatives like 'list_charts' or 'get_dataset_info'.

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 and idempotentHint. Description adds value by noting data source (autario.com), token-efficient metric selection, and instruction to cite citation_url.

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?

Well-structured with clear sections: purpose, usage, note on metrics, list, examples. Slightly verbose but efficient for the information provided.

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 2 parameters and no output schema, description sufficiently covers return values and usage. Includes citation instruction. Lacks explanation of error handling but adequate for a read-only 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 coverage is 100%, but description enhances by listing available metrics, explaining default if omitted, and providing parameter examples with user queries.

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 current stock metrics for a public company, using specific verbs and resource. It distinguishes from siblings like calculate or describe by focusing on stock 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?

Explicitly states when to use (e.g., user asks about stock price, market cap) and contrasts with outdated training data. Provides examples mapping user queries to parameters.

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 and destructiveHint=false. Description adds no contradiction and details the specific metadata fields returned. No behavioral surprises.

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

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

Description is slightly verbose with list of fields and usage advice. Could be more concise, but front-loaded with main purpose. Earns its length for utility.

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 explains return fields, especially those needed for chart creation. Given the tool's role and siblings, it provides sufficient context for an agent to use it effectively.

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 both parameters with descriptions (dataset_id as UUID, format with enum). Description adds value by explaining format wire types and token efficiency, but baseline is high due to 100% 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?

Description clearly states it retrieves full metadata for a specific dataset, listing many fields including ontology fields. Distinguishes from siblings like get_dataset_schema (schema only) and search_datasets.

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 tells when to use this tool: before creating charts, to obtain unit and frequency for chart titles. Does not explicitly exclude scenarios but provides actionable guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows it's safe. The description adds extensive behavioral transparency by detailing the datasheet block structure (shape, roles, cadence, cardinality, level_mix, ignore_cols, notes), which is far beyond the annotation coverage.

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 front-loaded with the main purpose but is quite verbose, especially with the detailed datasheet breakdown. While the detail is useful, it could be more concise without losing essential information. The density of content is appropriate, but length reduces readability.

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 thoroughly covers the datasheet output but lacks detail on the return format for column names, data types, and row count beyond stating they are part of the result. Since there is no output schema, the description should fully describe these fields. The omission creates 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?

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the format parameter's purpose ('Token-Oriented Notation, fewest tokens, best for tabular rows') and the dataset_id as a UUID. This extra context justifies a score above baseline.

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

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

The description clearly states the tool retrieves column names, data types, row count, and a machine-legible datasheet. It specifies the verb 'Get' and the resource 'dataset schema', and explicitly distinguishes itself from sibling tools by recommending it be called before query_dataset and charting.

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 the tool ('Always call this before query_dataset and before charting'). While it does not explicitly list alternatives or when not to use, the provided context effectively guides the agent to use it as a prerequisite, which is sufficient for effective selection.

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, idempotentHint, destructiveHint. Description adds context: automatic time join via shadow columns, default returns pre-computed stats block (n, min, max, avg, first, latest, latest_change_pct, range_change_pct), row_count, x_range, provenance. Full=true returns wide raw rows. 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 fairly concise but could be slightly tightened. Front-loaded with purpose and key capability. Every sentence adds value, but some elaboration could be trimmed without losing meaning.

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

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

Despite no output schema, description fully explains return structure: stats block details, row_count, x_range, provenance, and raw rows with full=true. Covers all parameters and usage scenarios adequately.

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 value by explaining defaults for 'full' (default false, reason to set true), format options, and max 10 indicator limit. Slight repetition of schema descriptions, but overall helpful 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 tool fetches data for one entity across multiple indicators with automatic join via shadow columns. It distinguishes itself from siblings like compare_entities and get_entity_profile by highlighting the cross-dataset join and default stats summary.

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 advises when to use default (stats only for answering questions) vs full=true (for plotting/export). References sibling tools list_indicators and get_entity_profile for obtaining inputs, and mentions token usage trade-offs for full=true.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, indicating a safe read operation. The description adds significant behavioral context: pagination (default 100, max 500), sorting by observation count, pagination fields (has_more, offset), and wire format options (toon, compact, json) with rationale. 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 well-structured: purpose first, then pagination details, then usage guidance, then entity ID examples. Every sentence adds necessary information. It is efficient for the amount of detail provided, though slightly longer than minimal.

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

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

Given no output schema, the description adequately explains what is returned (indicator IDs with metadata and time coverage, sorted by observation count) and pagination fields. It also mentions optional filtering by topic. It does not detail the exact structure of metadata, but the schema for the response is not provided; the description covers the essential context for an agent to choose and invoke the 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 coverage is 100%, so each parameter is described in the schema. The description adds value by explaining pagination mechanics (offset, has_more), providing defaults (limit=100), and giving examples of entity IDs (DEU, USA, WLD). It also explains the format parameter and its default. This enriches the 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 the verb 'Get the indicators available for one entity' and specifies the resource (entity profile). It distinguishes itself from siblings like `list_indicators` or `discover_by_topic` by focusing on entity-specific available indicators. The mention of entity IDs (ISO codes or aggregates) further clarifies 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 explicitly states when to use this tool: 'Use this to discover what you can query about Germany, USA, G7, or any known entity.' It provides examples and mentions optional filtering by topic. It does not explicitly specify when not to use or list alternatives, but the context from sibling names and the description itself gives enough guidance for an agent to distinguish.

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 and idempotentHint=true, so the tool is safe. The description adds valuable behavioral context: it requires admin OAuth, returns a cached snapshot, excludes bots, uses a 30-day window, and includes a separate llm_crawler section. 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 comprehensive but slightly lengthy. However, it is well-structured: purpose first, then details, then usage examples. Every sentence adds value, so it earns its length. A minor deduction for not being more concise.

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

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

Given zero parameters and no output schema, the description fully covers what the tool returns, its scope, permissions, caching behavior, and typical use cases. 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?

The tool has no parameters, so schema coverage is 100%. The description effectively communicates that no input is needed, which is sufficient. A baseline of 4 is appropriate.

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

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

The description clearly states the tool fetches an autario traction overview uniting three signal sources (GA4-humans, MCP/agent channel, signup funnel) and additional details. It distinguishes itself from siblings by being an admin-only overview tool, with no similar sibling tool in the 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?

Explicitly states ADMIN/CURATOR ONLY, provides example queries like 'how is autario doing', and notes that non-admin callers get a permission error. These guidelines clearly indicate when and by whom the tool should be used.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds interpretation of the output (peak |r| at positive lag indicates leading relationship), which is valuable behavioral context beyond 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 extremely concise: two sentences that front-load the core function and follow with interpretation and a real-world example. Every word serves a purpose.

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

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

For a read-only analysis tool with 5 parameters and no output schema, the description explains the concept and interpretation sufficiently. It could be improved by briefly noting the output structure (e.g., returns lag vs correlation results), but it remains functional.

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 80% of parameters with descriptions. The tool description does not add parameter-specific details beyond what the schema provides, so it meets the baseline but does not exceed it.

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

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

The description clearly states the tool performs cross-correlation at multiple lags to determine lead/lag relationships between two indicators. It distinguishes itself from sibling 'correlate' by focusing on lags and temporal precedence.

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 a concrete use case ('is consumer confidence a leading indicator of retail sales?') that illustrates when to use this tool. However, it does not explicitly contrast with alternatives like 'correlate' or state when not to use it.

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 read-only, idempotent, non-destructive. Description adds that datasets are pre-filtered to be chartable, explains why (won't bounce), and lists returned fields. 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 front-loaded with key info (admin-only), every sentence is informative, no redundancy. Efficient 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?

No output schema, so description fully explains returned fields and behavioral context. Covers auth, filtering rationale, and usage intent. Complete for a complex admin 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?

Single parameter 'limit' with default and max fully documented in schema. Description reiterates default and max but adds no new meaning beyond schema. Schema coverage is 100%, so baseline 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?

Description clearly states it lists datasets without published charts, ranked by relevance, for admin use. It distinguishes from siblings like 'list_charts' and 'request_chart' by specifying the admin-only scope and 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?

Explicitly states admin-only, non-admin gets 403. Provides a workflow sequence (request_chart preferred, etc.) and clarifies that third parties do not need it.

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

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

Annotations already provide readOnlyHint=true and destructiveHint=false, so the tool is safe. The description adds that it returns specific fields (IDs, titles, etc.), contributing behavioral context beyond annotations. No contradictions.

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

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

Two concise sentences: first states the action and returns, second gives usage guidance. No wasted words, front-loaded with key 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 listing tool with 4 parameters (all optional), good annotations, and no output schema, the description adequately covers purpose, returns, and usage. It mentions the fields returned, which compensates for lack of output schema.

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

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

Input schema has 100% description coverage, so baseline is 3. The description does not add new information about parameter meaning beyond the schema, but correctly implies that the tool retrieves charts based on default behavior.

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 'List' and the resource 'published chart visualizations' on Autario, and specifies the returned fields. It distinguishes from siblings like 'get_chart' (single chart) and 'list_chart_candidates' (different 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 includes 'Use to discover existing analyses' that implies usage context, but lacks explicit when-not-to-use or alternative tools. Sibling differentiation is not explicit, though the purpose is clear enough for agents to infer.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is clear. Description adds that it 'browses' and 'discovers,' reinforcing the read-only nature. No behavioral contradictions, and the description is consistent 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 purpose, then key parameters, then usage guidance. Every sentence adds value, no fluff.

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

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

For a list/discovery tool with no output schema, the description adequately covers what the tool does and when to use it. It explains the semantic layer and the available filters. Could be slightly more explicit about the return format, but the context is sufficient for an AI 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?

Schema description coverage is 100%, so baseline is 3. The description mentions key filters (topic, unit, frequency, entity_type) but does not add meaning beyond the schema's parameter descriptions. It summarizes the filter options without adding new 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: 'Browse the Autario indicator registry — semantic layer over all 2600+ datasets.' It uses specific verbs ('browse', 'discover') and distinguishes from sibling tool 'search_datasets' by noting it is more precise when topic/unit is known.

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

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

Explicitly says 'Use this to discover what data is available before querying it' and contrasts with 'search_datasets' by stating 'Much more precise ... when you know what topic or unit you need.' Provides clear context for when to use this tool and suggests an alternative.

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

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

Annotations already declare read-only, idempotent, non-destructive. Description adds minimal behavioral context beyond stating the computation. It does not discuss output format or side effects, but annotations cover safety.

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, no unnecessary 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?

No output schema and description omits return value details. The tool has 5 parameters but only period and full get any guidance. Missing parameter descriptions and output context reduce 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 only 40% (full, period). Description only reinforces the period parameter's meaning via YoY/QoQ/MoM, but leaves required parameters (entity, indicator) undocumented. Insufficient compensation for low 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?

Description clearly states the tool computes period-over-period percentage change for an indicator, specifying common growth rates (YoY, QoQ, MoM). This distinguishes it from siblings like calculate or compare_entities.

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 suggests use for growth rates, but does not mention when not to use or alternatives. Good guidance but lacks exclusion criteria.

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 are present and the description adds context about authentication (API key) and the insight verification gate, which goes beyond what annotations provide. 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?

Three concise sentences: purpose, usage guidance, and requirements. No fluff, front-loaded, and every sentence earns its place.

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

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

Covers purpose, usage guidance, requirements, and key parameters. Could mention output/return value, but given no output schema and sibling tools, it's reasonably complete.

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

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

Schema coverage is 100% with good parameter descriptions. The tool description adds value by explaining when the plotly_spec is appropriate (for advanced Plotly features), which enhances interpretation 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 publishes a chart using a freeform Plotly spec, and explicitly distinguishes it from create_chart_from_spec, 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?

It provides explicit guidance: use create_chart_from_spec unless a specific Plotly feature is needed, and mentions requirements (AUTARIO_API_KEY) and identical verification gates.

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=true, destructiveHint=false, idempotentHint=true. The description goes beyond by disclosing that aggregates are numerically correct despite text storage, and explains return values (rows as JSON plus per-category statistics or summary). 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 well-structured with sections for token efficiency and examples. It is front-loaded with the core purpose. However, it is relatively long and could be slightly more concise while retaining all key information.

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

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

Given the tool has 11 parameters, no output schema, and requires understanding of token efficiency, the description is remarkably complete. It covers return format, data source citation, handling null rows, pagination hints, and aggregation correctness. All critical aspects are addressed.

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 schema coverage is 100%, the description adds significant meaning: it explains how to use aggregate and groupby, clarifies output formats (toon is recommended), interprets summary_only and non_null_only in context, and provides alias conventions. This goes well beyond the schema definitions.

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 queries data from a dataset with optional filtering, sorting, field selection, and aggregations. It distinguishes itself by detailing specific aggregation functions and token-efficient practices, which sets it apart from sibling tools like 'clear_rows' or 'get_dataset_info'.

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 aggregations versus raw rows, and recommends summary_only for token efficiency. It gives concrete examples like 'average GDP of Germany 2010-2020' and states when to use non_null_only. However, it does not directly compare to alternative tools like 'verify_value' or 'describe'.

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 and idempotentHint=true, so the description adds context about returning slope, intercept, R², and interpretation. No contradictions, and the description aligns with the safety profile.

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

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

Two concise sentences with no fluff. The first sentence defines the tool's action and output; the second provides a usage example. 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?

The description covers purpose, outputs, and usage context for a 5-parameter tool without output schema. It lacks details on edge cases or assumptions (e.g., missing data, single points), but these are not critical for core understanding.

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 60% (3 of 5 parameters described). The description reinforces the role of x and y (predictor and target) but adds no detail for the entity or time parameters. The baseline of 3 is appropriate given moderate 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 clearly states it performs linear regression of y on x for one entity and lists the outputs (slope, intercept, R², interpretation). It distinguishes from sibling 'correlate' by specifying regression.

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 'Use for "how does X predict Y?" questions,' providing clear context for when to use. However, it does not mention when not to use or specify alternatives beyond implied contrast with correlation.

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

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

The description adds significant behavioral context beyond annotations: it explains deduplication (aligns with idempotentHint), requires authentication, describes routing logic (auto re-ingest vs. human review), and emphasizes the need for concrete evidence. 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 concise yet comprehensive, starting with the main purpose, listing specific use cases, and adding key notes like deduplication and authentication. Each sentence serves a clear purpose without unnecessary words.

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

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

Given the tool's complexity (5 parameters, enums, nested objects) and no output schema, the description covers usage scenarios, parameter details, routing, dedup, and authentication. It could mention what the tool returns upon success, but overall it provides sufficient contextual 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?

The input schema has 100% description coverage for parameters. The description adds value by elaborating on the purpose of 'evidence' with examples and explaining the 'finding_type' enum values in context, making the parameters more understandable than 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 explicitly states the tool's purpose: reporting data-quality problems in datasets or charts. It provides a comprehensive list of specific scenarios (truncated data, unit mismatch, etc.), making it clear when to use this tool and distinguishing it from siblings that perform different actions like creating or updating datasets/charts.

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 usage context: 'Use this during a QA pass when you spot...' followed by specific examples. It also mentions that duplicate reports are harmless. However, it does not explicitly state when not to use this tool or suggest alternative tools for different types of issues, which would improve guidance further.

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 key behaviors beyond annotations: the server composes the chart deterministically, returns charted_entities without publishing on prepare, verifies insight with a number-hallucination gate, and returns 422 with specific failure details. Also states the server runs no LLM.

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 well-structured with bold headings for the two steps and important notes. It is longer due to complexity but every sentence adds value, though it could be slightly more concise.

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

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

For a tool with 6 parameters and no output schema, the description is complete: it covers the full workflow, error handling, access restrictions, and provides all necessary context for correct invocation.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining each parameter's purpose, soft preferences, and the interplay between query and dataset_id. The insight parameter is thoroughly explained with context about verification.

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 is for high-level chart requests (admin only) and distinguishes it from create_chart_from_spec. It specifies the two-step flow (prepare/publish) and the outcome (getting a chart without building a spec).

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 tells when to use this tool ('Use THIS over create_chart_from_spec...'), describes the two-step flow with clear instructions for each step, and notes that non-admin get 403 and third parties use create_chart_from_spec.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint false, so the safety profile is clear. The description adds that it computes rolling statistics and the specific operations, but does not disclose that the 'full' parameter can return heavy data (though this is in the schema). Overall, it adds moderate context beyond 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 two sentences long, front-loads the core functionality, and contains no redundant 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?

Given the moderate complexity (6 parameters, no output schema), the description is too minimal. It omits the output format, does not mention the required parameters (entity, indicator), and lacks any information about window defaults or optionality, making it inadequate for complete understanding.

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 50% (3 of 6 parameters have descriptions: op, full, window). The description does not add any parameter-specific details beyond what the schema provides, failing to compensate for the undocumented 'time', 'entity', and 'indicator' 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 explicitly states it computes rolling window statistics (mean, std, min, max, sum) for an indicator, which is clear and specific. However, it does not differentiate from sibling tools like 'correlate' or 'regression', though the rolling window concept implies temporal analysis.

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 only implies use cases ('smooths noise, reveals trends') but gives no explicit guidance on when to use this tool vs alternatives like 'lag_analysis' or 'seasonality_decomposition'. It also does not mention prerequisites or when not to use it.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by specifying the return fields (including conditional ontology fields) and the scope of the search. It does not contradict annotations and provides useful behavioral context beyond the structured fields.

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 long, front-loaded with the core purpose and return value, followed by usage guidance and alternatives. Every sentence adds value without 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?

For a tool with 5 optional parameters, no output schema, and many siblings, the description provides sufficient context: it lists return fields, gives usage guidance, and points to alternatives. It could mention pagination limits but those are already in the schema. No major 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?

Schema coverage is 100% with all parameters described. The description adds little beyond the schema, providing examples for the query parameter but no additional semantic meaning. Baseline score of 3 is appropriate as the schema already adequately documents 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 searches the Autario public data catalog and lists the specific return fields. It differentiates itself from sibling tools by indicating when to use alternatives like list_indicators or discover_by_topic.

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 advises to 'Use this first to discover available datasets before querying' and provides clear alternatives: for precise filtering prefer list_indicators, for topic-driven research prefer discover_by_topic. This gives strong guidance on when to use this tool versus others.

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 the tool as readOnly and idempotent. The description adds behavioral details: it returns per-timepoint components plus summary amplitude, and warns that setting 'full' to true returns a heavy raw series. 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: first explains the method, second provides usage guidance and return information. No redundant words, tightly written.

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 5 parameters and no output schema, the description covers the decomposition formula, typical use cases, and return type (components + amplitude). It could be more detailed about output interpretation, but it's 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 coverage is 40%. The description adds context for 'period' by mentioning monthly/quarterly data, and for 'full' by noting it returns heavy series. But it does not cover other parameters like 'time' or 'entity', and the added value beyond the schema is minimal.

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 'Additive decomposition Y = trend + seasonal + residual' and explains it strips the seasonal cycle to reveal underlying trend. It provides specific use examples (retail sales, unemployment) that differentiate it from other time series tools, though it doesn't explicitly name siblings.

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

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

The description explicitly says 'Use this to strip the seasonal cycle' and notes it's 'great for monthly or quarterly data', providing clear context. However, it does not mention when to avoid using it or name alternative tools like rolling_stats or regression.

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 provide safety profile (not read-only, not destructive, idempotent). Description adds behavioral context: ownership constraint and typical mutation behavior. 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?

Two concise sentences, front-loaded with purpose. Every sentence provides unique value: purpose, ownership constraint, and typical use. No redundant or filler content.

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

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

Adequate for a mutation tool with 5 parameters and no output schema. Covers purpose, ownership, and typical modifications. Lacks note on return value or effect on unspecified fields, but not critical given schema richness.

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 all 5 parameters (100% coverage). Description mentions three key fields (plotly_spec, title, insight) but adds no additional meaning beyond what schema provides. Baseline score 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 explicitly states 'Update an existing chart you own' with specific verb and resource. It enumerates modifiable fields (Plotly spec, title, insight), distinguishing from create (publish_chart) and read (get_chart) operations.

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?

Describes when to use: to modify a previously published chart. Includes ownership restriction: 'Only the API key that created the chart can update it.' No explicit when-not-to-use or sibling alternatives, but the context is clear.

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

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

Annotations already declare readOnlyHint and idempotentHint, indicating a safe read operation. The description adds valuable behavioral details: it returns whether the value matches, plus relative difference and provenance, and explains the optional existence-only check.

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 with two sentences, front-loaded with the core purpose. Every sentence adds value, no verbose or redundant wording.

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 explains what the tool returns (match, relative difference, provenance). It covers primary use cases, optional behavior, and input requirements, making it fully complete for a verification 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 coverage is 100%, but the description adds meaning by explaining the role of each parameter in the verification process and explicitly mentions that 'expected' can be omitted for existence-only checks, which is 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 uses a specific verb-resource pair ('Verify that a claimed value is correct') and provides concrete use cases (hallucination checks, double-checking numbers). It clearly distinguishes from siblings by focusing on verification, which no other tool does.

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

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

The description explicitly states when to use the tool (user asks about hallucination, double-checking cited numbers) but does not mention when to avoid it or suggest alternatives. However, given the context of siblings, the usage is well-defined.

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

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

Annotations already indicate read-only, idempotent, non-destructive. Description adds rich details: returns confidence labels (strong/suggestive/weak/inconclusive), reason strings, sharpen-suggestions, and auto-aligned frequencies. 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 slightly long but well-structured. It front-loads the core purpose and then adds necessary details. Every sentence adds value, though it could be tightened slightly.

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 thoroughly explains return values (ranking with labels, reasons, sharpen-suggestions) and behavior (frequency alignment, auto-selection). It is complete for a read-only analytical 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 coverage is 75% (time parameter missing description). Description adds value by explaining that omitting 'candidates' auto-selects from ontology, and mentions frequency alignment related to time. Compensates well for the gap.

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 starts with a clear statement: 'given an outcome metric + entity, rank which other metrics best explain the outcome.' It uses specific verbs and resources, and explicitly distinguishes from the sibling tool 'find_drivers'.

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

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

Provides explicit guidance: 'Use this instead of find_drivers when you want a narrative-grade answer.' Also explains the auto-selection behavior when 'candidates' is omitted.

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 reveals behaviors beyond annotations: schema auto-inference, all values stored as text, and a row limit. Annotations already indicate non-read-only, non-idempotent, and open-world behavior, and description adds context without 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?

The description is three concise sentences, front-loading the purpose and efficiently covering key constraints (schema inference, storage type, row limit, auth). No unnecessary words.

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

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

For a simple two-parameter tool with no output schema, the description covers purpose, constraints, and requirements. It could mention error handling or idempotency, but overall it 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?

Schema description coverage is 100%, so the description adds minimal value for parameter semantics. It reinforces the append action but does not elaborate on parameter details 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 the tool appends rows to an existing dataset, using specific verbs and resources. It distinguishes from sibling tools like clear_rows and create_dataset by focusing on appending 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 provides a row limit (10,000 per call) and mentions the required API key, but it does not explicitly state when not to use this tool or offer alternatives like clear_rows for replacing data.

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