mfgcalcs

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

No annotations are provided, so the description carries full burden. It explicitly states 'Deterministic — no LLM' and enumerates return components: composed sentence, headline value with period/change, source, time series, and citable URL. This gives clear behavioral expectations.

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

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

The description is moderately sized, with two paragraphs covering purpose and details. It is mostly concise, though the last sentence about MFGSearch/MFGChat could be considered slightly redundant. Overall, it is well-structured and front-loaded.

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 thoroughly explains what the tool returns (sentence, headline value, source, time series, URL). It also provides example queries and context about the data source (mfgcalcs.com). This gives sufficient information for an agent to use the tool 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 coverage is 100% with one parameter 'query' described as 'A full question'. The description adds value by providing concrete examples and clarifying that queries can be natural language, which goes beyond the schema's minimal definition.

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 answers natural-language questions about U.S. manufacturing costs, tariffs, etc., with a single cited number. Examples like 'how much steel did the US import last month' illustrate the scope, and it distinguishes itself from sibling tools that are more specific (e.g., get_tariff_effect).

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 example queries and notes the engine is the same as MFGSearch/MFGChat, implying broad applicability. However, it does not explicitly state when to use this tool versus alternatives (e.g., for specific metrics like tariffs, the sibling tools might be preferred).

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

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

No annotations provided, so description bears full burden. It discloses return content (inputs and formula) but does not explicitly state read-only nature, error handling, or side effects. Adequate for a simple retrieval tool.

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 focused sentences with no wasted words. Front-loaded with action and result, immediately actionable.

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 single-parameter tool with no output schema, the description covers purpose, input source, and when to use. Lacks return format details but sufficient given tool simplicity.

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

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

Schema coverage is 100% and describes 'tool' as a slug with examples. Description adds context on obtaining slug from 'search_calculators', reinforcing but not adding new depth.

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

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

Clearly states the verb 'Get' and resource 'calculator's inputs (labels, units, defaults) and formula'. Distinguishes from sibling 'run_calculator' by specifying 'before running it' and references 'search_calculators' for slug retrieval.

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 'before running it' and mentions slug source from 'search_calculators', providing clear context. Lacks explicit exclusion of other uses but sufficiently guides 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?

With no annotations, the description carries full disclosure. It clearly states the tool outputs a statistical relationship, not a causal claim, and describes the regression method (shifting indices 0-6 months, reporting lag and coefficient). It also mentions to cite the returned URL, hinting at output format.

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, front-loading the main purpose. Each sentence adds meaningful detail about the method, output, and usage, without unnecessary filler.

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

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

Given no output schema, the description fully explains the returned elements (lag, coefficient, correlation, recent inflation info) and the tool's purpose. It is complete for an agent to understand when and how to use it.

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

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

The tool has zero parameters, so the parameter semantics burden is minimal. The description adds value by explaining what the tool computes and returns, compensating fully for the lack of 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 retrieves the 'MFG Calcs Cost Pass-Through Index' and explains exactly what it measures (how input cost changes affect downstream prices, with lag). It distinguishes itself from siblings like 'get_cost_pressure_index' by focusing on pass-through dynamics rather than pressure levels.

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 tells when to use this tool (to answer if input costs are being passed through and with what lag). It notes it takes no arguments, simplifying usage. It does not explicitly state when not to use it or name alternatives, but context with sibling tool names implies differentiation.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the index is illustrative (not official), frozen methodology, and requires citing the URL. It details the decomposition and what data is returned, providing good transparency.

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

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

The description is detailed but front-loaded with the main purpose. Each sentence adds important information, though it could be slightly more concise. The structure is logical.

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 complexity of the index (five drivers) and the absence of an output schema, the description sufficiently explains what is returned (level, changes, history, decomposition) and how to use it. It also mentions the URL for citation, making it fairly complete.

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

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

Only one parameter (points) with 100% schema coverage. The description adds valuable semantics: 'latest', 'points=<n>', or omit for full history, clarifying usage beyond the schema's type definition.

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: retrieving the MFG Calcs Manufacturing Cost Pressure Index, a composite index of five drivers. It distinguishes from sibling tools by calling it the 'flagship one-number read' and specifying its unique component decomposition.

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 instructions on when to use (e.g., answering questions about US manufacturing cost pressure) and how to use the 'points' parameter. It lacks explicit exclusions or alternatives, but the context is well-covered.

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 it uses USITC HTS public-domain data, is reference not a customs ruling, and notes Chapter 99 overlays. No destructive or auth implications, and the description adds behavioral context beyond basic read.

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 efficient, front-loading the core purpose. Each sentence adds value, though it could be slightly tighter. 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?

For a complex tool involving tariff layers and exclusions, the description covers everything: inputs, outputs (board), exclusions, and caveats. No output schema, so description compensates well.

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 'family' has full schema description with examples. The description adds context about 'U.S. manufacturing families' and the 'omit for full board' behavior, but this is mostly already in the schema. Baseline 3 is appropriate.

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

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

The description clearly states it determines whether a duty-free import route exists for a U.S. manufacturing family, covering both base tariff schedule and Chapter 99 overlays. This is distinct from sibling tools like lookup_tariff which likely focus on a single tariff line.

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 pass a family key/label for one family or omit for full board. Explains what the tool answers and excludes (unilateral programs). Even without explicit 'when not to use', 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?

Without annotations, the description discloses key behavioral traits: it is a statistical extrapolation, knows nothing about pending Federal Register actions, and includes backtest error. It instructs to cite the URL and uncertainty, adding transparency.

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

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

The description is relatively concise with two sentences plus an instruction. It front-loads the key purpose and model details. A minor improvement could be to avoid repeating 'forecast' but overall efficient.

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

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

For a zero-parameter tool with no output schema, the description fully captures what the tool does, its limitations, and how to use the returned data (cite URL and uncertainty). It is contextually complete.

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

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

The input schema has no parameters, and schema description coverage is 100%. The description explains what the tool returns (forecast band, backtest error, URL) and how to handle output, going beyond baseline.

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

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

The description clearly states the tool retrieves the Effective-Tariff Index Outlook, a six-month forecast band on the manufacturing effective-tariff rate, using a specific model (damped Holt-Winters). It distinguishes from siblings by specifying the exact resource and method.

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

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

The description provides context for when to use (answering 'where is the manufacturing tariff burden heading?') and explicitly states it is not a policy forecast. However, it does not mention when not to use or compare directly to 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?

Discloses that it uses statistical extrapolation, not market or policy forecasts, and knows nothing about pending decisions or actions. Explains the criteria for inclusion (12 observations, backtest MAPE <=35%). Describes return content and citation requirements.

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

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

Concise yet comprehensive: starts with purpose, then explains usage, then caveats. Every sentence provides necessary information without redundancy.

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

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

No output schema, but description fully explains what is returned in both cases (single series vs board). Includes behavioral context and citation instructions. Complete for a forecast retrieval 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?

Parameter documentation in schema is complete, but description adds essential context: examples of series slugs, and behavior when omitted (returns board ranked by biggest projected move). This adds significant value beyond the schema.

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

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

Clearly states it gets six-month statistical forecast for U.S. manufacturing series, with specific examples like 'where is copper / diesel / the 10-year treasury heading?'. Distinguishes from siblings by specifying scope (MFG Calcs) and method (damped Holt-Winters).

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 pass a series slug vs omit, and what each returns. Provides usage examples. Does not differentiate from sibling tools like get_forecast_accuracy, but gives enough context for common use cases.

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

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

With no annotations, the description carries full burden. It describes the aggregated metrics and includes a behavioral instruction ('Cite the returned url.'). It also warns about horizon differences. However, it does not disclose rate limits, data freshness, or side effects, leaving some transparency gaps.

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

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

The description is somewhat lengthy but necessary to explain the complex aggregated metrics. It front-loads the core purpose and uses bullet-style listing. Every sentence adds value; no redundancy. Could be slightly tighter, but overall effective.

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 the tool returns: a URL to a ledger containing the listed metrics. It covers the key information an agent needs to use the tool, including the horizon caveat.

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

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

There are no parameters, so the baseline is 4. The description correctly notes 'Takes no arguments' and does not attempt to add parameter meaning where none exists.

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

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

The description clearly identifies the tool as retrieving the Forecast Accuracy Ledger, a specific resource distinct from sibling tools like get_forecast. It lists the key metrics and answers the explicit questions 'how accurate are these forecasts?' and 'should I trust the manufacturing forecasts?'.

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 states it takes no arguments and explains the purpose. The important caveat about short-horizon vs published forecasts helps the agent understand when to use it. While no explicit alternatives are given, the zero-parameter, single-purpose nature makes usage 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?

With no annotations provided, the description discloses key behavioral aspects: the implied price is an average across HTS lines and origins (not a quoted market price), moves can reflect multiple factors, data source (USITC public-domain), and a note to cite the returned url and caveat. This is transparent, though it could explicitly state it's a read-only operation with no side effects.

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 core purpose and action. It is relatively concise, though it includes example answers and redundant phrasing (e.g., first sentence details what the tool does, then later repeats the parameter behavior). Every sentence adds value, but a slight trim could 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 the tool has only one parameter, no output schema, and no annotations, the description is remarkably complete. It covers input behavior, output interpretation, caveats, data source, and usage context. The agent has all necessary information to select and invoke the tool correctly without additional context.

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

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

The schema already describes the 'family' parameter with examples and behavior when omitted. The description adds further context: 'Pass a family key or label for one family; omit it for the full board ranked by biggest absolute price move.' This reinforces and clarifies the schema description, adding value beyond the structured field.

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: to get implied import prices and year-over-year moves for U.S. manufacturing families, ranking by biggest move. It answers specific questions like 'which imported goods got more or less expensive?' and 'what is the implied import price of aluminum articles?', making the purpose unmistakable and distinguishing it from sibling tools focused on other trade metrics.

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

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

The description explains when to use the tool (to find import price movers or a specific family's implied price) and how to use it (pass a family key/label for one family or omit for the full board). It does not explicitly list alternatives or when not to use, but the context makes it clear. The caveat about the implied price being an average adds important guidance for interpretation.

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?

Describes the index formula, return components (YoY, MoM, smoothed, directions), and that it takes no arguments. No contradictions with missing 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?

Efficiently packs purpose, explanation, comparison, and usage note in a few sentences with 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?

Without output schema, the description fully explains return values and usage, making it self-contained for a zero-parameter 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?

No parameters, so description adds value by explaining the return structure and index construction beyond the empty 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?

Explicitly states the tool gets the ICDI, explains it's a diffusion index measuring breadth of cost increases, and distinguishes from sibling MCPI 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?

Clearly mentions how it complements MCPI (magnitude vs breadth), provides context on when to use this tool, but doesn't explicitly list when not to use.

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

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

With no annotations, the description discloses key behavioral traits: data can be provisional vs final, the status field must be checked, and it's an illustrative composite not the official ISM. It could mention update frequency or limitations, but the provided context is sufficient for understanding the tool's behavior.

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

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

The description is front-loaded with purpose and includes necessary detail. It is somewhat verbose but every sentence adds context (e.g., status field, components, comparison to ISM). Could be slightly more concise, but overall well-structured.

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

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

Given no output schema, the description thoroughly explains the return values and the significance of the status field. It does not cover error scenarios, but for a data retrieval tool with no parameters, this is nearly complete.

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

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

The tool has zero parameters and schema coverage is 100%. The description adds value by explaining what the tool returns in detail (headline, components, regional Fed data, url), surpassing the baseline expectation for a no-parameter tool.

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 specific resource 'MFG Calcs PMI', a unique index. It distinguishes from siblings by emphasizing that this is a free, public alternative to proprietary PMIs, which none of the other tools provide.

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 the tool answers questions about US manufacturing expansion/contraction and the PMI, and notes it takes no arguments. It provides context on when to use it (for public hard data vs proprietary), but does not explicitly state when not to use it or list alternatives, though the sibling tools are different enough that this 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?

Discloses computation method (realized effective rate minus statutory MFN median), special case handling (noBaseline separate), data source (USITC public-domain), and citation instruction. No annotations provided, so description carries full burden and meets it well.

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

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

Four sentences, each providing unique value: definition, usage question, parameter guidance, and data source. No filler or repetition. Front-loaded with purposeful summary.

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

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

Given no output schema and no annotations, the description covers purpose, input, behavior, edge cases, and data provenance. The tool is simple (1 optional param) and description is self-contained for correct invocation and interpretation.

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 'family' has 100% schema coverage (string description). Description adds concrete examples ('steel-fasteners', 'aluminum-semis') and clarifies that omission yields full board. This adds meaning beyond the generic schema description.

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

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

Description uses specific verb 'get' and resource 'Policy Premium', clearly defining what it computes (policy overlay vs statutory schedule). Includes an example question and usage distinction (with/without family key). Differentiates from 24 sibling tools by focusing on tariff decomposition.

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: to answer 'how much of the tariff on X is policy'. Provides guidance on parameter usage (omit for full board, include for specific family) and mentions edge case (families without baseline). Lacks explicit when-not-to-use, but context is 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?

The description discloses that the tool takes no arguments, what it returns (hashes, generator, page, URL), and its limitations (does not prove correctness of underlying data), providing sufficient transparency without 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 fairly concise but conveys all necessary information. It is front-loaded with the core purpose and structured logically, though slightly verbose in parts.

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 no parameters and no output schema, the description fully explains the output, usage, and limitations, making it complete for effective use.

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

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

The tool has no parameters and schema coverage is 100%. The description simply states 'Takes no arguments', which is clear and adequate.

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 'MFG Calcs Provenance Manifest', and explains its purpose ('verifiable record') and output, distinguishing it from siblings that retrieve specific calculations.

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 when to use the tool ('to VERIFY a number before quoting it') and provides step-by-step usage instructions, but doesn't explicitly mention when not to use it or 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?

Despite no annotations, the description explicitly states it is an indicative signal (not a dollar quote), explains key assumptions (base-year parity, mix shifts), and instructs to cite the returned URL. This provides thorough behavioral context beyond what annotations would typically convey.

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

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

One paragraph, front-loaded with purpose. Could be slightly more concise, but every sentence adds value (purpose, usage, interpretation, caveats). 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?

Given no output schema, the description does well to explain the output interpretation (positive/negative gap) and mentions a URL to cite. It covers what the tool does, how to use it, and what to expect from the result, though a bit more structure would help.

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 (family) with 100% schema coverage. Description repeats the schema's explanation but adds an example and clarifies omission behavior. This adds modest value, meeting the baseline for 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 states the tool retrieves the reshoring break-even line, explains the calculation (effective tariff rate where landed import equals domestic price), and gives a concrete question it answers. While sibling differentiation is implicit due to the unique name, the purpose is exceptionally clear.

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?

Clear instructions to pass a family key/label or omit for full board. Provides context on when to use (e.g., for a specific family vs. full view). Does not explicitly compare to siblings like reshoring_score, but the intended use is well conveyed.

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

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

No annotations provided, so description carries full burden. Discloses data source (USITC public-domain), attribution (cite the returned url), and that shares are based on true customs-value total. No destructive behavior implied.

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 informative but slightly lengthy. However, every sentence adds value, and key information is front-loaded. Could be trimmed but still effective.

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 simple parameter and no output schema, description explains return values (ranking, source shift, changes) and attribution. Provides enough context for an agent to use correctly.

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

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

Parameter 'family' has 100% schema coverage, and description adds context: 'pass a family key or label for one family; omit it for the full board', clarifying usage beyond schema.

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

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

Describes a specific verb ('Get Source-Shift') targeting a defined resource ('U.S. manufacturing import families') and clearly states the tool answers 'who replaced China' and shows sourcing changes. Distinguishes itself from sibling tools by focusing on source-shift 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?

Explicitly states when to pass a 'family' parameter (for one family) vs omit (for full board). Does not explicitly mention when not to use or list alternatives, but context from sibling names suggests clear separation.

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

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

With no annotations, the description fully discloses that HHI is based only on named source countries (floor on true concentration), it is a supply-risk read not advice, and it returns a URL. It also notes the ranking order.

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 few sentences long, each adding distinct information. It could be slightly more concise, but it is well-structured with the main purpose first.

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

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

Given no output schema, the description adequately covers what the tool returns: HHI, base vs latest, verdict, ranking order, and a URL. It is complete for an agent to understand the tool's output and behavior.

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 only parameter 'family' has a schema description that is essentially identical to the tool description. Since schema coverage is 100% and clear, the description adds minimal value beyond what the schema already provides.

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 provides the Sourcing Diversification Tracker with HHI, base vs latest, and verdict, answering specific questions about concentration. It differentiates from sibling tools by focusing on import-source concentration for manufacturing families.

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 pass a family key/label for one family or omit for full board, and states what questions it answers. It does not explicitly mention alternatives or when not to use, but provides clear context.

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

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

No annotations are provided, so the description must disclose behavior. It explains the index construction (weighted average), that higher means costlier, and that it's an illustrative composite. It does not mention side effects (likely none) or authorization needs, but the 'get' verb implies read-only. The caution about exclusion of taxes, land, incentives adds transparency.

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

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

The description is packed with useful information (formula, examples, caveat, citation note). It is slightly long but every sentence earns its place. No unnecessary repetition.

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

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

No output schema is provided, but the description mentions 'Cite the returned url' and implies a ranking board or a single index value. However, it does not detail the structure of the output (e.g., fields, formatting), which would help an agent parse the result. For a tool with no output schema, more detail on return format would improve 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 schema has 100% coverage for the one optional parameter. The description adds meaningful context: 'pass a state code (e.g. 'TX') or name for one state; omit for the full ranked board,' and gives examples (California/Texas), which is more helpful 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 clearly states the tool provides the State Cost-to-Manufacture Index, explains the composite formula (75% wage, 25% electricity), and answers specific questions like 'which state is cheapest?' or 'how expensive is California/Texas?'. It is distinct from sibling tools like get_cost_pass_through or get_cost_pressure_index by focusing on state-level cost index.

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 tells when to use (e.g., for state cost comparison) and how to invoke (pass a state or omit for full ranking). It includes limitations ('not a full site-selection model, excludes taxes, land, incentives'), but does not explicitly contrast with sibling tools or state when not to use.

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

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

With no annotations, the description carries full burden. It discloses that the index is illustrative and not official, cites the returned URL, explains the decomposition and FX volatility caveat. This is good transparency, though it doesn't explicitly state read-only or mention authentication.

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 moderately long but well-structured: it starts with the main purpose, then details the score and drivers, followed by usage instructions and caveats. Each sentence contributes meaningful information, though some minor trimming could 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 the tool's complexity (multiple drivers, optional parameter, output includes URL) and the absence of an output schema, the description covers all necessary aspects: what the tool returns, how to interpret it, usage modes, and important caveats like the illustrative nature and FX currency limitations.

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

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

The input schema already has a clear description of the 'family' parameter. The description adds value by explaining the two usage modes (with or without family) and the FX volatility caveat, which provides context beyond the schema.

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

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

The description clearly states the tool's purpose: 'Get the MFG Calcs Supply Chain Fragility Index' with a detailed explanation of the score range (0-100), its decomposition into four drivers, and the specific questions it answers. It distinguishes itself from sibling tools by focusing on fragility 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 provides clear guidance on usage modes: pass a family key for one family or omit for the full board. However, it does not explicitly state when to use this tool over alternatives among the many sibling tools, nor does it provide exclusions or prerequisites.

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

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

With no annotations provided, the description fully discloses behavioral traits: it takes no arguments, returns a URL, is read-only, and includes important disclaimers about correlation and data recency. This goes well beyond the minimal requirement.

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 verbose but well-structured: it leads with the main purpose, details what each episode contains, and ends with important caveats. Every sentence adds value, though minor trimming could 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?

Despite having no output schema, the description thoroughly explains what the tool returns (dates, rates, cumulative moves, changes in customs value and tariff bill) and addresses edge cases (recent episodes with insufficient data). It fully covers the tool's functionality and limitations.

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

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

The tool has zero parameters, so the description's job is minimal. The baseline is 4, and the description correctly indicates 'Takes no arguments' without needing further parameter explanation.

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: retrieving a chronological git-timestamped record of tariff rate changes and their impact. It specifies the resource (MFG Calcs Tariff Action Ledger) and distinguishes it from siblings by focusing on historical tariff actions and economic effects, not current rates or general indices.

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, specifically to answer questions about tariff effectiveness and post-2014 events. It includes important caveats (association vs causation, data limitations) but does not explicitly mention when to avoid using it or suggest alternative tools for other scenarios.

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

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

No annotations are provided, so the description carries the full burden. It discloses the output structure (latest month, YoY change, TTM total, full series, annual board), data source (USITC public domain), and citation requirement. It does not mention rate limits or auth needs, but the tool appears safe and read-only.

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

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

The description is packed with essential information in two sentences. It front-loads the purpose, then clarifies scope and usage. Every sentence adds value with 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 (returns multiple data points) and lack of output schema, the description fully explains what is returned. It also covers provenance, data source, and parameter usage. No gaps are evident.

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 the single parameter 'points' with 100% coverage, describing values 'all', 'latest', or a positive integer. The description adds 'trim the series' but does not significantly enhance understanding beyond the schema. Baseline of 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Get the U.S. Manufacturing Tariff Bill' with specific detail about what it includes (dollars paid by manufacturers, monthly since 2014, constant panel). It distinguishes itself from related concepts like total customs revenue, making it unique among sibling tools such as get_tariff_index or get_tariff_dollars_by_country.

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: it gives the ETI numerator in dollars, not total customs revenue. However, it does not explicitly name alternative sibling tools or state when not to use it. The context is sufficient for an AI agent to infer appropriate usage.

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

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

No annotations exist, so description carries full transparency burden. Discloses that totals are a FLOOR, data is USITC public-domain, and returns a URL. Does not cover auth, rate limits, or latency, but for a data retrieval tool the key behavioral traits are addressed.

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 compact paragraph that packs purpose, usage, behavioral notes, and data source. No unnecessary words, though slightly denser than ideal. Earns its sentences without being verbose.

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 only one optional parameter and no output schema, the description fully covers what the tool does, what input it expects, what the output contains (ranked list, fields, URL), and key caveats (floor data, source). No significant 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% for the single parameter, with schema describing the param briefly. The description adds value by clarifying optionality and example values ('china', 'mexico'), and explaining what happens when omitted. This exceeds the baseline of 3 for high schema coverage.

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

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

The description clearly states the tool retrieves duties paid by origin country in USD, ranked with shipped value, effective burden, and per-year trend. It answers a specific question('who pays America's manufacturing tariffs?') and distinguishes from other tariff tools like get_tariff_index or get_tariff_bill.

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 how to use the optional 'country' parameter: pass a slug/name for one origin, omit for full board. Mentions data is a floor and from USITC. Does not explicitly compare to siblings or state when not to use, but provides sufficient context for correct invocation.

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

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

In the absence of annotations, the description carries full burden and does an excellent job. It discloses that the analysis is observational (not causal), uses customs value (not volume), and includes a caveat about confounding factors. It also mentions the returned URL and caveat to cite. This honesty is crucial for correct agent usage.

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 tool's purpose and includes detailed caveats. It is slightly verbose but every sentence adds value. It could be streamlined, but overall it is well-structured and informative.

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 single optional parameter and lack of output schema, the description covers all necessary context: what the tool does, how to use it, what the output contains (verdict, URL, caveat), and important limitations. It is complete for this tool's 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?

The schema already provides a description for the 'family' parameter (100% coverage), so baseline is 3. The description adds value by explaining that omission returns the full board ranked by rate step, which enhances understanding of parameter behavior 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's purpose: to retrieve an analysis of tariff effects on imports for U.S. manufacturing families with a significant rate step. It uses specific language like 'Get Did the Tariff Work?' and distinguishes it from sibling tools by its unique question-answering role.

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 usage instructions: pass a family key for one family or omit for the full board. It implies the tool's use case (answering tariff effect questions), but does not explicitly state when to avoid using it or mention alternatives among siblings. This is clear enough for an agent.

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

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

With no annotations, the description carries full burden. It explicitly states the tool returns the latest reading, full monthly series, and download URLs, notes the data is monthly since 2014 with base 100, and mentions public-domain status. No contradictory or missing behavioral information.

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 informative yet efficient, with important details front-loaded. It could be slightly shorter, but 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 no output schema, the description thoroughly explains what the tool returns (latest metrics, full series, download URLs) and includes metadata like period and baseline. No critical gaps.

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

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

Schema coverage is 100% with a clear parameter description for 'points.' The tool description adds minimal extra meaning beyond stating the default ('all'). Baseline 3 is appropriate.

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

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

The description clearly states the tool retrieves the U.S. Manufacturing Effective-Tariff Index, defines it precisely, and distinguishes it from siblings by calling it the 'single citable, redistributable benchmark' and the 'empirical counterpart to the statutory MFN column.' This leaves no ambiguity about what this 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 implies when to use (when needing the manufacturing tariff burden benchmark) but does not explicitly state when not to use or list alternative tools. However, it highlights uniqueness ('single citable...'), which guides 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?

With no annotations provided, the description carries full burden. It discloses data is a survey-year snapshot, not cost-of-living adjusted, and BLS public-domain. It also instructs to cite the returned URL. This adequately conveys the tool's read-only nature and data limitations.

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 verbose but front-loaded with the main purpose. It includes helpful examples and context, but could be more concise. Every sentence adds value, but overall length is more than necessary.

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

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

Given no output schema, the description does a good job explaining return values: per-trade wage data, state index, pressure trend. It also mentions a URL to cite. However, exact structure of the response is not specified, which is a minor gap.

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

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

The description adds significant meaning beyond the schema: it explains that omitting the parameter returns the full board plus state index and pressure gauge, and provides examples of valid inputs ('machinist', '51-4041'). Since schema coverage is 100%, baseline is 3, but the description enriches understanding.

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

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

The description clearly states 'Get the Manufacturing Wage Board' and elaborates on the specific content: factory pay across trades, state index, pressure trend. It distinguishes itself from sibling tools by its unique focus on manufacturing wages.

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

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

The description provides clear context on when to use the tool, giving examples of questions it answers (e.g., 'what does a machinist make?'). It explains parameter behavior (omit for full board) but does not explicitly compare to sibling tools 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?

With no annotations, the description fully discloses what the tool returns (statutory/effective rates, price, HHI, etc.) and its read-only nature. Adds context about data source and non-ruling status.

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 paragraph front-loaded with core purpose, but packs substantial detail. Could be more structured (e.g., lists) but remains concise given the breadth of 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 thoroughly enumerates return fields (statutory rates, effective rates, implied price, top countries, HHI) and query methods, providing sufficient context for accurate use.

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

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

Schema coverage is 100%, and the description adds value by explaining query types (keyword, family key, HTS code) with examples for the 'query' parameter. The 'limit' parameter is well-documented in the schema, so marginal added value.

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

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

The description clearly states the verb 'Look up' and specifies the resource 'current U.S. import tariff rates' with detailed elements (statutory rates, effective rates, etc.). It distinguishes from sibling tools by focusing on lookup of specific tariff 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?

Provides clear query methods with examples and notes data source (USITC) and citation requirement. Lacks explicit when-not-to-use or alternatives, but context with siblings implies use for tariff rate lookup.

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

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

With no annotations, the description fully bears the burden of behavioral disclosure. It details the calculation method (uplift formula), data source (USITC DataWeb), output components (duty, freight, HHI, FX direction), and behavior when unit price is available or not. This is comprehensive and transparent.

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 with useful information but remains well-structured and front-loaded. Each sentence adds value, though minor trimming could improve conciseness. Overall, it's efficient for its length.

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 and lack of output schema, the description thoroughly explains what the tool returns: duty, freight share, uplift, unit price (if applicable), HHI, FX direction, and a URL. It also covers parameter usage and limitations, leaving no critical gaps for the 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 schema already describes the 'family' parameter, but the tool description adds valuable context: examples of family keys ('steel-flat-rolled', 'bearings') and the behavior when omitted (list all families). This extra information helps the agent use the parameter correctly.

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

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

The description clearly states the tool's purpose: ranking source countries by fully-loaded landed cost for a manufacturing import family. The verb 'rank' and resource 'source countries' are specific, and the scope (family-based) distinguishes it from sibling tools like get_cost_index or get_tariff_effect.

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

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

The description explains when to use the tool ('to answer where is it cheapest to source X from?') and how to pass the parameter. It also clarifies what the output includes and that it's not a customs quote. However, it does not explicitly state when not to use it or compare to 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?

Without annotations, the description fully reveals the formula, components, monthly nature, data source, and disclaimer. It adds transparency beyond the schema, though it lacks details on rate limits or access restrictions.

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

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

The description is well-structured, front-loading purpose and score interpretation. It efficiently conveys formula, modes, and disclaimer in a few sentences, though it could be slightly more terse.

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 explains the return value (detail vs. leaderboard, monthly series, URL). It lacks explicit output structure but provides sufficient context for agent 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?

The description adds examples (e.g., 'bearings') and clarifies the behavior difference when omitting the parameter (leaderboard). This goes beyond the schema's simple description, which already had 100% 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 retrieves the Reshoring Readiness Index for a U.S. manufacturing import family, answering specific questions. It distinguishes two modes (with/without family key) and contrasts with siblings like get_reshoring_break_even.

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 (to assess reshoring readiness) and provides two usage paths, but does not explicitly state when not to use or compare to alternatives among the many 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?

No annotations, so description carries full burden. Discloses input handling (defaults), output (results with units, formula, citation URL). Does not explicitly state non-destructive nature or side effects, but it's implied for a calculation run.

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

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

Two sentences, no wasted words. Front-loaded with purpose and input method. Efficiently communicates output format.

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

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

Given no output schema, description adequately explains return value. References get_calculator for details. Could provide more structure on the output format, but sufficient for selection and invocation.

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

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

Schema coverage is 100%, baseline 3. Description adds value by explaining that inputs can be keyed by field key or slugified label, and that missing inputs use defaults. This goes beyond schema descriptions.

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

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

Description clearly states 'Run a manufacturing calculation' with specific verb and resource. It distinguishes from siblings like get_calculator and search_calculators, which retrieve calculator details or search for calculators.

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 guidance on how to provide inputs (by field key or slugified label) and mentions defaults. References get_calculator for input details. Could explicitly state prerequisites (e.g., slug from search_calculators) but still 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?

No annotations are provided, so the description carries the burden. It states it returns matches with slugs but does not disclose pagination, result ordering, or any limitations. As a search tool, read-only behavior is implied but not explicitly stated.

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

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

Two sentences with all essential information: what it searches, examples, and output connection. No redundant words, well-structured.

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

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

The description is adequate for a search tool with a simple schema. While no output schema exists, it mentions the key output (tool slug) and gives examples of calculator domains. Could be slightly improved by noting the return format details.

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

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

Schema coverage is 100%, with descriptions for both parameters. The description adds value beyond the schema by noting the returned tool slug is for run_calculator, providing context for how the output is used.

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 specifies the verb 'Search', the resource 'MFG Calcs' library of 5,400+ manufacturing calculators', and lists example areas. It also states the output includes a tool slug for run_calculator, distinguishing it from siblings like get_calculator and run_calculator.

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

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

The description implies usage for finding calculators before running them, but no explicit when-to-use or alternatives are mentioned. Sibling tools exist but no guidance on when to use search vs get_calculator.

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

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

With no annotations, description carries full burden. It discloses return format ('typed matches with URLs to cite'), which is valuable behavioral info. Lacks mention of auth, rate limits, or pagination, but as a read-only search, these are less critical.

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

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

Two sentences, front-loaded with purpose, no extraneous text. Every sentence adds value.

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

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

For a search tool with 2 params and no output schema, the description provides sufficient context: scope, examples, output format, and sibling differentiation. No gaps.

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

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

Schema coverage is 100% with functional descriptions. The purpose description adds context on what queries can target (e.g., data series, tariff families), enhancing parameter meaning beyond the schema's generic examples.

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 searches non-calculator content on mfgcalcs.com, enumerates specific categories (63 economic data series, 57 tariff families, etc.), and distinguishes from sibling tool search_calculators. Verb 'search everything... returns typed matches' is specific and actionable.

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 this tool vs alternative: 'Use search_calculators for the 5,407 calculators themselves.' This provides clear guidance on exclusion and context.

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