mfgcalcs

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

With no annotations, the description carries the full burden. It clearly notes the behavior is 'Deterministic — no LLM', which is valuable transparency that this isn't a general chatbot. It discloses what's returned (sentence, headline value, source, time series, URL) and advises citing the returned URL. This is strong behavioral disclosure for a tool with no annotation support.

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 and efficient: states purpose, notes deterministic behavior, lists the return bundle, gives four concrete examples, and ends with the citation guidance. Every sentence earns its place with zero waste.

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

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

The tool has a single simple param and no output schema, but the description thoroughly covers what the output looks like (sentence, headline value, source, time series, URL). It provides enough examples to guide the agent. Slight deduction because it doesn't mention failure behavior (e.g., what happens when a query is outside the covered domains), but for this scope it's near-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% and there's only one param (query) whose schema description ('A full question, e.g. ...') aligns with the tool description. The description reinforces the query type with examples but doesn't add substantially beyond what the schema plus description already establish. 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 has a specific verb+resource ('answer a natural-language question' about manufacturing costs, tariffs, etc.), clearly distinguishes it from siblings by noting it's the engine behind MFGSearch/MFGChat and returns cited numbers from live data. It also provides concrete example queries, making the purpose unmistakable.

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

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

The description gives clear context on when to use (natural-language questions with a single cited number) and what domains it covers. It doesn't explicitly say 'use get_* tools for structured lookups instead', but the scope is well-delineated from the sibling get_* tools that fetch specific indicators.

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 this is a read/inspection operation (getting inputs and formula, not executing), which is useful. However, it doesn't describe what the response consists of beyond inputs/formula, nor any auth or cost behavior, leaving some ambiguity for a no-annotation 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 concise sentences with zero waste. The first states the function and the second provides parameter sourcing guidance. Every sentence earns its place and the most important information is 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?

For a single-parameter inspection tool with full schema coverage, the description is reasonably complete. It tells the agent what to expect (inputs, formula), when to use it, and how to source the parameter. The only gap is not describing the response structure in more detail, but given no output schema and the tool being a simple getter, this is adequate.

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

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

Schema coverage is 100% for the single required param 'tool', which already has a clear description with an example. The description adds the guidance to use the slug 'from search_calculators', reinforcing parameter sourcing. This adds marginal value, hence 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 states a specific purpose: retrieve a calculator's inputs (labels, units, defaults) and formula before running it. The verb 'get' plus the resource 'calculator' clearly describes the action, and it distinctively complements siblings like run_calculator and search_calculators by being the pre-execution inspection step.

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 it: 'before running it', which contrasts it against run_calculator. It also references search_calculators as the source for obtaining the slug. It doesn't explicitly state when NOT to use siblings, but the 'before running' timing is 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?

With no annotations provided, the description carries the full burden. It discloses that this is a statistical regression relationship, not a causal claim, and that it takes no arguments. It also transparently notes the 0-6 month lag window and that it reports a coefficient, correlation, and lag values—good behavioral context for a read-only analytical 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?

The description is thorough but notably long—roughly seven sentences covering methodology, output fields, and questions. It is informative, but some detail (the full enumeration of input and output index components) could be trimmed without losing essential meaning. Reasonably front-loaded with the purpose, but not maximally economic.

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

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

Given zero parameters, no output schema, and no annotations, the description does strong work explaining what the tool returns (best-fitting lag, coefficient, correlation, unpassed inflation) and its methodological caveats. It covers the question space well. The only minor gap is not explicitly stating the output format/units beyond YoY points and months.

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?

With zero parameters and 100% schema coverage, the no-argument nature is fully documented. The description adds value by confirming 'Takes no arguments' and explaining what the tool computes with those no inputs, which is appropriate for a parameterless analytical tool that derives everything from internal data.

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, naming the exact object (MFG Calcs Cost Pass-Through Index) and the concrete questions it answers ('are input costs being passed through to prices?' and 'how long until material costs hit fabricated-goods prices?'). It clearly distinguishes purpose from siblings like get_cost_pressure_index and get_input_cost_diffusion by describing the specific regression methodology against a list of input and output 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 explicitly states the analytical questions it answers, which implies the use case (identifying whether price moves have flowed through). However, it does not name alternative tools or give explicit when-not-to-use conditions, so it slightly misses the highest bar for exclusionary 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?

No annotations are provided, so the description carries the behavioral disclosure burden. It is notably transparent: it explicitly flags the index as ILLUSTRATIVE, not official, describes the frozen/reproducible methodology, enumerates the five component drivers, and states the mathematical property (weighted sum, contributions add up with no residual). It also tells the user to cite the returned url. This is strong behavioral disclosure for a read-only analytic tool. Minor gap: it doesn't explicitly state this is a read-only/safe operation, but the descriptive nature makes that evident.

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 long (multiple sentences) but every sentence earns its place: it defines the index, lists the five drivers, explains the exact decomposition property, states the queries it answers, documents the points parameter behavior, and includes the crucial caveat about it being illustrative. Slightly dense with parenthetical detail, but well-structured with the parameter guidance and IMPORTANT caveat front-loaded appropriately near the end.

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 analytic tool with one optional parameter and 100% schema coverage, the description is complete. It specifies what is returned (current level, YoY/MoM change, monthly history, exact component decomposition), the parameter behavior comprehensively, and critical caveats (illustrative, base month, cite url). No output schema exists, so the description appropriately compensates by listing return components. This is genuinely comprehensive for the 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?

Schema description coverage is 100% for the single optional 'points' parameter, so the schema already documents it well. However, the description adds valuable semantics beyond the schema: it clarifies the 'latest' special value, explains that a number N returns the last N months, and that omitting returns full history. This enriches the meaning beyond the schema's minimal description. The baseline is 3 due to 100% coverage, but the additive guidance earns a 4.

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

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

The description specifies the exact resource (MFG Calcs Manufacturing Cost Pressure Index/MCPI), the verb (Get), and the scope (U.S. manufacturer input-cost pressure, base=100, five live drivers). It clearly distinguishes itself from siblings like get_input_cost_diffusion or get_cost_pass_through by describing it as the flagship one-number read with exact component decomposition. The purpose is unambiguous and specific.

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 it: 'Answers how much have U.S. manufacturing costs risen? and what is driving factory cost pressure?', which is direct usage guidance. It also provides the points parameter usage directions ('Pass points=latest for just the current reading... omit for the full history'). While it doesn't name specific alternative tools, the clear query-answering framing effectively guides when to invoke this tool versus the sibling toolset.

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 key behavioral nuance that a Chapter 99 overlay applies regardless of origin claim, explains that the board reports survivability proportions, and notes it is reference data citing USITC HTS as public domain (authority source). This is substantial behavioral disclosure for a reference-data 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?

The description is dense but front-loaded with the core purpose, then explains the CF79 overlay nuance, exclusions, and caveats in order of importance. It's moderately long but every sentence carries meaning — no filler or self-referential restatement. Slightly wordy in the middle section but structurally sound.

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 a single-parameter reference tool with no output schema, the description covers the question answered, the overlay nuance, exclusions, reference-data caveat, and citation guidance. The main missing element is what the returned data/fields look like (the board format), but for a full-board view tool this is reasonably complete for the agent to invoke it 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% for the single parameter, which is well-described in the schema ('Family key or label... Omit for the full board'). The description adds the example format ('aluminum-semis', 'powered hand tools') and the omit-for-full-board behavior, reinforcing but not substantially exceeding the schema. Baseline 3 is appropriate since the schema already does the heavy lifting.

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

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

The description is specific: it states the tool reports duty-free import routes for U.S. manufacturing families, distinguishing MFN-free lines from reciprocal FTA preferences, and explains the Chapter 99 overlay. It clearly answers 'can I import X duty-free?' and differentiates from the broad family of tariff-related sibling tools by its focus on the duty-free badge and chapter 99 overlay.

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?

Explicit usage instructions: 'Pass a family key or label for one family; omit it for the full board.' It also states clear exclusions ('Only reciprocal FTAs are counted; unilateral programs (GSP, AGOA, CBI) are excluded') and provides a caveat ('not a customs ruling'). This gives strong when-to-use and when-not-to-rely 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?

With no annotations provided, the description carries full burden and it responds well. It discloses the methodology (walk-forward-validated damped Holt-Winters), that it is extrapolation-only (no policy knowledge), that it returns both a forecast band and a MAPE, and instructs citation of the url and labeled uncertainty. This is rich behavioral context beyond what any schema could provide.

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

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

The description is dense and information-rich, front-loaded with the core purpose. Every clause adds value, and the methodological caveat and citation instructions are meaningful, not filler. Could arguably be trimmed slightly, but the content justifies the 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?

For a parameterless statistical-forecast tool with no output schema and no annotations, this is reasonably complete. It explains methodology, uncertainty handling (MAPE, labeled bands), usage caveats (not policy forecast), and output contents (url). Minor gap: it does not specify the time-unit format (months) explicitly beyond 'six-month', and pagination/format details are absent, but these are minor for the tool's simplicity.

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

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

There are 0 parameters, so the baseline is 4. The description's text about what the returned forecast contains (band, MAPE, url) adds context about how to interpret the result even though no params need documentation. This is appropriately handled for a parameterless 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?

Description names a specific resource (Effective-Tariff Index Outlook), a specific verb (get), and precisely states what it returns: a six-month statistical forecast band on the manufacturing effective-tariff rate with backtest MAPE. It directly answers a shared question ('where is the manufacturing tariff burden heading?') and distinguishes itself from siblings like get_forecast and get_tariff_index by specifying the ETI-specific statistical forecast.

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

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

The description clearly states what it is NOT (a policy forecast, knows nothing about pending Federal Register actions), which gives excellent exclusions. It implicitly signals it should be used when one wants a statistical shape-extrapolation answer. However, it does not explicitly name sibling alternatives (e.g., get_forecast for other forecast horizons, get_tariff_index for current values), which would push to a 5.

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

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

No annotations are provided, so the description carries full burden. It goes well beyond a bare read/write classification, disclosing that this is a read-only forecast computation, that output includes url/band/MAPE, and that the forecast is damped Holt-Winters extrapolation with explicit caveats about what it cannot capture (Fed decisions, OPEC actions). It even instructs the agent to cite specific returned fields. Minor gap: it doesn't detail pagination or rate limits, but for a forecast tool this is strong disclosure.

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 uses three tight sentences that front-load the purpose, then caveat, then cite-guidance. Every sentence earns its place. It's slightly dense with qualifications and numbers (>=12, <=35%, 6-month) but all are necessary filtering criteria. The only minor deduction is length — it packs a lot into a single paragraph, though it remains scannable.

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 the key dimensions: scope of data, filtering criteria, two invocation modes, prediction methodology, limitation caveats, and citation expectations. The return structure is described in prose (full history, forecast band, backtest track record, url, MAPE), compensating for the missing output schema. Could name additional sibling alternatives more explicitly, but this is quite complete for the 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?

Schema coverage is 100%, so the baseline is 3. The description substantially elevates this by explaining the semantic meaning of the 'series' parameter (one series slug for detailed forecast vs. omitted for the ranked board), providing real example slugs ('ppi-aluminum-mill-shapes', 'wti-crude-oil-spot'), and describing the difference in output structure depending on presence/absence. This adds meaning far beyond the schema's generic 'series slug' 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?

The description uses a specific verb+resource ('Get MFG Calcs Forecasts') and clearly states what it returns: a six-month statistical forecast for live U.S. manufacturing series with explicit criteria (>=12 monthly observations, MAPE <=35%). It also provides concrete example slugs and clarifies the two invocation modes (with/without series). This strongly distinguishes it from siblings like get_forecast_accuracy and get_eti_outlook.

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 tells when to use the tool ('where is copper / diesel / the 10-year treasury heading?'), how to invoke it (pass a slug for one series vs. omit for the ranked board), and what NOT to expect (it's statistical extrapolation, not a market or policy forecast — says it knows nothing about Fed/OPEC). It also names the sibling alternative (get_forecast_accuracy) implicitly by contrasting forecast shape vs. accuracy. This is exemplary usage 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?

No annotations are provided, so the description carries the full burden. It clearly discloses the self-grading nature ('self-graded'), the walk-forward backtest methodology (data the model had not seen), and the critical limitation that accuracy is short-horizon only. It also instructs citing the returned URL. This is strong behavioral transparency for a tool with no annotation support.

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-organized, front-loading the core statement of what the tool returns, enumerating metrics in a flowing list, then giving usage caveats and an instruction. It's longer than minimal but every sentence adds value; the trailing caveat about horizon and the URL citation instruction are meaningful. Slightly verbose in the metric enumeration but appropriate for the tool's complexity.

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

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

The tool has no output schema and no annotations, so the description must fully compensate. It enumerates all returned data categories (graded forecasts, observations, APE percentiles, hit rates, directional hit rate, category breakdown, best/worst series) and gives the critical interpretation caveat. For a no-parameter, no-output-schema tool this is strong coverage, though a note on typical result size or update cadence would push it to 5.

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?

With 0 parameters and 100% schema coverage, the description appropriately states 'takes no arguments' and focuses energy on value-add content. Since there are no parameters to document, the baseline is high; the description doesn't add parameter detail but doesn't need to.

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 has a specific verb ('Get') plus resource ('Forecast Accuracy Ledger') and explicitly defines what the tool measures with a detailed list of metrics. It distinguishes itself from the sibling get_forecast by focusing on accuracy/backtest history rather than the forecasts themselves, and clearly answers 'how accurate are these 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 explicitly states the tool takes no arguments, addresses the trust question ('should I trust the manufacturing forecasts?'), and provides critical usage caveats: it's one-step-ahead (short-horizon) accuracy while published forecasts run six months out, warning that error compounds with horizon. This tells the agent when reliance is appropriate vs. when to be cautious.

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 prominently discloses the critical caveat that the implied price is an average across every HTS line and origin, not a quoted market price, and that moves can reflect tariff pass-through, freight, currency, or mix shift. It also notes USITC public-domain sourcing and instructs to cite the returned url and caveat. With no annotations provided, the description carries the full behavioral burden and handles it well, though it could mention data freshness/pagination.

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

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

The description is somewhat long but every sentence earns its place: purpose, usage pattern, row composition, caveat, and citation requirement. It is front-loaded with the core purpose and answers. Slightly verbose in the middle but efficient overall for the behavioral nuance it needs to convey.

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

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

Given one optional param, no output schema, and no annotations, the description is reasonably complete: it explains the metric, ranking logic, per-row contents, caveat, and data source. It could add return-format details (since no output schema exists) to describe the row structure more explicitly, but it names the key fields carried per row 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% for the single optional 'family' parameter, so the schema already documents it well. The description adds value by explaining semantics beyond the schema: omitting yields the full ranked board, and passing a key OR label both work, with an example format. It enhances the parameter meaning even though the schema also covers 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 a specific verb+resource: gets import price movers for tracked U.S. manufacturing families, computing implied import prices and year-over-year moves ranked by biggest move. It explicitly answers the target questions ('which imported goods got more or less expensive?' and specific family queries), and it distinguishes itself stylistically from siblings like get_cost_pressure_index and get_tariff_index by focusing on implied import price per unit and price moves.

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: pass a family key/label for one family, omit it for the full ranked board. It also states what each row carries (latest effective tariff rate). However, it does not explicitly mention when NOT to use this tool versus specific alternatives like get_tariff_effect or get_cost_pass_through, so it lacks explicit exclusions despite offering solid usage direction.

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 tool is read-only in nature (returns diffusion readings), explains the index formula (100 x (risers + 0.5 x unchanged)/basket size) so the agent understands the semantics, details what the return includes (YoY and MoM diffusion, 3-month smoothed reading, each input's direction), and notes the citation requirement. It's transparent about the frozen basket of 16 series. Minor gap: doesn't state data vintage or update cadence.

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-organized: name, definition, construction details, return contents, sibling differentiation, and no-argument note all packed into three sentences. It's front-loaded with the tool's identity. Slightly longer than minimal but every sentence adds semantic value; no 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 0 parameters and no output schema, the description must carry all context. It fully explains the index's meaning, formula, basket composition, return fields, and relationship to MCPI. It could add return format/pagination or update cadence, but for a read-only no-arg tool the provided coverage is strong. The citation instruction is a useful operational detail.

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 takes zero parameters (schema coverage 100%), and both the schema and description confirm this. The description appropriately explains the basket composition and index methodology, which gives the agent full understanding of what the no-argument call returns. With 0 params, the baseline is 4 and the description fully compensates by explaining the data source basket.

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 gets the MFG Calcs Input Cost Diffusion Index (ICDI), explains it's a classic diffusion index measuring breadth of input-cost increases, and explicitly distinguishes it from the sibling MCPI tool (magnitude vs. widespread). The verb-resource pairing is specific and the index construction is fully explained.

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 differentiates this tool from the Cost Pressure Index (MCPI) by stating MCPI measures MAGNITUDE while this measures how WIDESPREAD cost increases are. This gives clear when-to-use guidance relative to its closest sibling. It also states it takes no arguments and instructs citing the returned URL.

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 key behavioral traits well: that provisional months will be revised, weights are renormalized, absent components are named in missingComponents, and the finalThrough field indicates last settled month. However, it doesn't describe return format details or error/pagination behavior since there are no arguments and no output schema.

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

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

The description is informative but verbose—roughly 150 words for a no-argument tool. It front-loads the core purpose and return values effectively, but could tighten the provisional-status explanation. The length is justified somewhat by the complexity of the return payload (headline, change, components, corroboration panel), but several clauses could be condensed.

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, no-output-schema tool of moderate complexity (multiple return sections: headline, components, corroboration panel), the description thoroughly covers what the agent receives and how to interpret it. The status-field warning, missingComponents behavior, and citation requirement are all critical operational details that are fully disclosed.

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?

With 0 parameters and 100% schema coverage (empty object), the schema provides no parameter documentation burden. The description explicitly states 'Takes no arguments,' so there is nothing to disambiguate. Baseline 4 is appropriate for a zero-parameter tool where parameter semantics are trivially satisfied.

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

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

Clear verb+resource: 'Get the MFG Calcs PMI' with a detailed explanation of what it measures (0-100 diffusion index, month-over-month change, components, corroboration panel). Distinguishes itself from siblings by explicitly noting it's built from public federal data unlike proprietary ISM/S&P PMIs, and directly answers the economic questions it addresses.

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?

Explicit guidance on when to use (answers 'is US manufacturing expanding or contracting?'), what the tool is NOT (illustrative hard-data composite, not the ISM survey), and critical usage warnings like checking the status field and interpreting provisional readings. Names an alternative (ISM) but notes it's unavailable, making this tool's distinct role 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 does reveal useful non-obvious behaviors: the full-board ranked output, the noBaseline separate bucket for families without a median, and the USITC public-domain + citation of returned url. However, it doesn't disclose whether this is a read-only operation (implied but not stated), performance characteristics, or potential edge cases with data freshness. Decent disclosure but not comprehensive.

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?

Densely informative in ~4 sentences with zero waste. Each sentence earns its place: concept definition, the exact question it answers, usage pattern, noBaseline edge case, and citation source. Front-loaded with the most important semantic 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?

For a lightweight tool with one optional parameter and no output schema, the description covers the essential behavior: single vs full-board, ranking, the edge case of missing baselines, and attribution. It could note whether the noBaseline bucket is included when filtering by a single family, but for a 1-param tool 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?

Schema coverage is 100% — the single family parameter is documented with example values ('steel-fasteners', 'aluminum-semis') and the omitted behavior. The description adds the ranking/full-board semantics but doesn't go beyond the schema for the parameter meaning itself. Baseline 3 is appropriate since schema handles the parameter documentation adequately.

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 has a specific verb+resource ('Get the Policy Premium') and clearly explains the concept with a mathematical definition (realized effective rate minus statutory MFN median, in percentage points). It clearly distinguishes from siblings (tariff-related tools) by framing the exact question it answers: 'how much of the tariff on X is policy, not the base schedule?'. The full-board vs single-family behavior is explicit.

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

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

Usage is well-specified: pass a family key for one family, omit it for the full board ranked by highest overlay. It also notes that families without a stated statutory median are returned separately as noBaseline. This provides clear behavioral context. No explicit exclusions or alternatives named, but the usage pattern is unambiguous and sufficient for an agent to select this tool.

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

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

No annotations are provided, so the description carries full burden. It discloses that the tool takes no arguments, returns hashes/provenance data rather than compute output, and is read-only in nature. It clearly states the semantic limits of the verification (proves integrity/reproducibility, not data correctness). It doesn't mention performance or failure modes, but given zero annotations, it does substantially better than baseline.

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 states what the tool returns, gives a concrete usage workflow, notes a caveat, and ends with an actionable instruction—all in four sentences. Nothing is wasted and the critical usage guidance is front-loaded after the initial purpose statement.

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-argument tool with no output schema and no annotations, the description is remarkably complete: it explains the return content (hashes, generator, page), provides the verification workflow, discloses limitations, and notes citation behavior. There are no ambiguity gaps for an agent invoking this 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% and there are zero parameters, so the description is not required to explain any. The description correctly states 'Takes no arguments,' preempting any agent confusion about input. The baseline for 0-param tools is 4, and the description's explicit confirmation elevates it further since there is nothing left ambiguous.

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 pairing ('Get the MFG Calcs Provenance Manifest') and clearly enumerates what the manifest contains: SHA-256 hashes, generator, page, and git history for every indexed/ledger artifact. It distinguishes itself from sibling data-retrieval tools by being specifically about provenance/verification rather than data values.

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 VERIFY a number before quoting it' and provides a concrete three-step workflow (re-hash for integrity, re-run generator for reproducibility, read git history for timestamp). It also gives an explicit caveat about what the tool does NOT prove (correctness of underlying government data) and instructs the user to cite the returned url.

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 full disclosure burden — and it does well. It explicitly flags this is an INDICATIVE signal, not a dollar quote, discloses the base-year price parity assumption (no domestic dollar-per-unit cost), and warns that import unit values shift with product mix. This is exactly the type of quantitative-limitation caveat an agent needs before trusting the output.

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 information-dense but front-loaded — the core purpose is in the first sentence, followed by the signal interpretation and caveats. It earns its length: purpose, usage, limitation caveats, and a final instruction all appear in a compact narrative. Slightly longer than strictly necessary but every clause contributes.

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 is remarkably complete: it explains the computation, the interpretation of positive/negative gaps, the applicable use-case question, the key limitations (indicative-only, base-year parity, mix sensitivity), and even tells the agent to cite the returned URL. Nothing material is left unexplained for the one optional parameter.

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 single 'family' parameter is documented in the schema with an example ('steel-fasteners') and omit behavior. The description adds modest value by reiterating the omit-for-full-board behavior and the example family, reinforcing the schema rather than substantially extending it. With 100% coverage, 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 computes the MFG Calcs Reshoring Break-Even Line — the tariff rate at which landed import price equals domestic price, per manufacturing family. It uses a specific verb ("Get"), names the exact resource, and explains the meaning of positive/negative gaps. It distinguishes well from siblings like get_tariff_effect, get_cost_pass_through, and reshoring_score by defining the exact computation.

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?

Explicit guidance is given: pass a family key/label for one family or omit for the full board. It states exactly when to use it by posing a representative question ('has the tariff made reshoring pencil out for fasteners / steel?'). It also gives an exclusion/alternative framing by naming sibling tools (get_calculator, reshoring_score) implicitly distinct. The 'Cite the returned url' instruction adds operational guidance.

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

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

No annotations are provided, so the description carries the full burden. It discloses that shares are computed against the year's true customs-value total (a meaningful methodological detail), states the base year (2018), and explains the output dimensions (source country now vs then, flip status, share change in percentage points). It does not disclose rate limits or failure behavior, but the transparency given is substantive for a read-only data 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?

The description is dense but front-loaded with the core purpose. Every sentence earns its place, though it is somewhat long with interleaved framing questions ('who replaced China for X?'). The trade-offs (time of under-specification vs slight verbosity) favor this length given the multi-dimensional output.

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

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

The tool has a single optional parameter, no annotations, and no output schema, so the description must carry the explanatory burden. It covers input behavior, output semantics (the #1 source flip, share changes, biggest gainer), and data provenance. The only gap is that the returned url format/citation convention isn't defined, but this is minor given the tool's simplicity.

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

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

Schema coverage is 100% and there is only one optional parameter. The description adds real meaning beyond the schema example ('powered-hand-tools', 'valves'), clarifies the omission behavior (full ranked board), and explains that family can be a key or label. This meaningfully enhances the schema's bare type declaration.

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 ('Get Source-Shift') with a clear resource ('U.S. manufacturing import families') and explicitly scopes the operation to tracking sourcing changes since the 2018 pre-Section-301 base year. It clearly distinguishes what it answers ('who replaced China for X?') from sibling tools like get_reshoring_break_even or get_sourcing_diversification by focusing on the #1 source country flip and China's share change.

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 usage guidance: pass a family key/label for one family, or omit it for the full ranked board. It also states the source (USITC public-domain) and asks the agent to cite the returned url, giving concrete caller instructions beyond mere when-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 provided, the description carries the full burden. It discloses that HHI rests only on named source countries (a floor on true concentration), that it is a 'supply-risk read, not sourcing advice', and instructs to cite the returned url. These are valuable behavioral disclosures beyond a bare read operation. It could mention response format but the explicit caveats and citation directive are strong.

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 tight sentences, front-loaded with what it does, then usage, then caveats. Zero filler. Every sentence earns its place—purpose, scope, usage, and disclosure all covered efficiently.

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-optional-parameter read tool with no output schema, the description covers purpose, scope, metric definition, usage, caveats, and citation instruction. It could add the response ordering/hierarchy detail (mentioning the full board is ranked 'most-concentrating first' covers this). Slight gap on explaining what fields the returned data contains, but complete for the tool's simple surface.

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 the family parameter documented. The description adds value by clarifying 'family key or label' and giving concrete examples and the omit-for-full-board behavior, which exceeds schema baseline. However, with only one parameter fully covered and the optionality made clear in the schema itself, the added value is moderate.

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

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

The description clearly states the tool returns the Sourcing Diversification Tracker with HHI values, base/latest readings, and a verdict. It explicitly scopes to 'tracked U.S. manufacturing families' and distinguishes itself by naming specific questions it answers ('is sourcing for X getting more concentrated...'). This is a specific verb+resource with clear 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 says to pass a family key or label for one family, or omit it for the full board. It names concrete example values. It doesn't explicitly name sibling alternatives, but the tool's question-framing ('which families lean on the fewest supplier countries') gives clear context on when it applies versus siblings like get_source_shift.

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 clearly discloses this is 'an illustrative composite of two live cost factors' and not a comprehensive model, and instructs the agent to 'Cite the returned url' — a useful behavioral instruction. It fully explains the indexing methodology (national average = 100) so the returned value's meaning is transparent. Minor gap: no description of the return format/ranking detail beyond 'board of the 50 states and DC.'

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

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

Front-loaded with the purpose and methodology, then the question-answering framing, then usage, then caveats, then a call to action ('Cite the returned url'). A few redundant phrasings ('how expensive is manufacturing in California / Texas?' restates the 'which state' idea) could be trimmed, but overall it is efficient and well-ordered for a tool of modest complexity.

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

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

Despite having only 1 optional parameter, no output schema, and no annotations, the description is thorough: it explains the metric's meaning, weighting, return modes (single state vs. full board), and honest caveats about what it excludes. The absence of output-schema information is somewhat mitigated by the clear explanation of the index scale. Could note the exact url field structure, but is otherwise complete for a single-parameter informational 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 description coverage is 100%, so the single 'state' parameter is already documented. The description adds value by explaining the accept value formats ('state code e.g. 'TX' or name'), that omitting returns the full board, and that only one state should be passed — going slightly beyond the schema's basic description but not dramatically, since there is only one simple parameter.

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

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

The description has a specific verb+resource ('Get the MFG Calcs State Cost-to-Manufacture Index') and immediately clarifies its meaning (national average = 100, higher = costlier), the weighting formula (75% wages, 25% electricity), and the exact questions it answers ('which state is cheapest...', 'how expensive is California/Texas?'). It clearly distinguishes from siblings like get_wage_board (wages only) and get_cost_pressure_index by specifying its composite nature.

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 (answering which state is cheapest/most expensive to manufacture in) and exactly how: pass a state code/name for one state, omit for the full ranked board. It also disclaims what it is NOT for ('not a full site-selection model — excludes taxes, land, and incentives'), which guides an agent away from over-applying it to site-selection decisions.

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 given, so the description carries full burden. It discloses the four decomposition drivers, the 0-100 scale, and importantly flags that FX volatility only applies under certain conditions. It also discloses this is an illustrative composite on frozen methodology, not an official statistic, which is important honesty. The only gap is not detailing the return shape (e.g., whether the returned url is a citation source).

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 information-dense and well-organized, covering the score scale, decomposition, use cases, parameter semantics, and caveats in about 150 words. The sentence about the family key vs omit behavior is slightly redundant with the schema but useful. It front-loads the core purpose and tucks caveats at the end, which is good structure.

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 but rich conceptual content, the description is quite complete. It explains the score scale, the four drivers, the two usage modes (single family vs full board), the FX limitation, and a caveat about methodology. It does not describe the exact response structure, but with a description this rich, the missing return-shape detail is a minor gap rather than critical.

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

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

Schema coverage is 100%, so the schema documents the 'family' parameter. The description adds value by giving concrete examples of valid values ('steel-fasteners', 'semiconductors') and explaining what omitting it returns, which is meaningful added context. But the schema already covers the core parameter meaning, so baseline 3 applies.

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

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

The description clearly states what the tool does: get a 0-100 fragility score per manufacturing family with a specific decomposition into four named drivers. It answers the specific questions 'which supply chains are most fragile?' and 'how exposed is the bearing/fastener supply chain?'. It distinguishes itself from siblings (get_cost_pressure_index, get_cost_pass_through) by its focused purpose on import fragility.

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 it ('which manufacturing supply chains are most fragile?') and when to omit the family parameter vs pass one. It gives concrete examples ('steel-fasteners') and clarifies behavioral constraints (FX volatility only for tracked-currency top sources). It's a clear, single-purpose tool distinct from siblings.

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

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

No annotations provided, so description carries full burden — and it does the work: discloses the metrics returned (dates, before/after rates, cumulative move, change in import customs value and tariff bill over 6-month windows), explicitly flags the ASSOCIATION-not-causation caveat, and acknowledges data limitations for recent episodes. Zero-parameter tool, so behavioral disclosure is the core value.

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?

Substantial but every sentence earns its place — scoping, deliverable list, interpretive framing, and citation instruction. Slightly dense in a single paragraph (no visual structure), but content is well organized and front-loaded with the purpose before caveats.

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, no-output-schema tool, the description is remarkably complete: it defines the data scope, the threshold for inclusion, all returned fields, the interpretation caveats, and the limitation on recent episodes. Covers everything an agent needs to select and trust the invocation without ambiguity.

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?

Tool takes no arguments and schema coverage is 100%, so there are no parameters to document. Description proactively notes 'Takes no arguments,' which removes any doubt and clarifies the tool is a fixed-purpose read. Baseline 4 for a zero-param tool 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?

Specific verb ('Get') + resource ('MFG Calcs Tariff Action Ledger') + precisely scoped: chronological git-timestamped record of tariff-rate episodes since 2014 where the rate stepped >=1pp month over month. Clearly distinguishes from siblings like get_tariff_index (a level/time-series) and get_tariff_effect, since this is an event-based ledger focused on what happened after each episode.

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 what it answers ('did the tariffs actually reduce imports?' and 'what happened after the 2025 tariff hike?'), signals it's an association not a causal claim, warns that recent accruing episodes lack after-data, and instructs the agent to cite the returned url. Gives clear context for when to reach for 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses that the tool returns the numerator in dollars only (not total customs revenue), defines the panel scope, states data provenance (100% USITC public-domain), and instructs citation. It doesn't disclose return format details or any edge behaviors (e.g., what happens with invalid points input), but the safety profile is inherently benign (read-only data retrieval), and the description covers the key scoping and attribution 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 information-dense but slightly long — it packs return-value enumeration, scope disambiguation, attribution guidance, and parameter usage into a single paragraph. There's some redundancy (the return components enumerated in the first half are fairly obvious for a 'bill' tool), but every sentence adds meaningful value. Slight opportunity to front-load the parameter hint earlier.

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 a single optional parameter with 100% schema coverage, no output schema required to explain return format beyond the enumerated components, and a read-only reporting tool, the description is largely complete. It specifies the monthly historical range (since 2014), the return list, the scope boundary, and citation requirement. The main gap is not describing the exact structure/format of the returned series and board, but that's minor given no output schema constraint.

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% — the single 'points' parameter is already fully documented in the schema ('all', 'latest', or positive integer). The description adds a small hint about trimming the series with points='latest' or a number, which is a marginal value-add beyond the schema. With full coverage, 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 is highly specific: it names the exact verb+resource ('Get the U.S. Manufacturing Tariff Bill'), defines the precise scope (dollars U.S. manufacturers paid, summed across a constant manufacturing panel monthly since 2014), and enumerates the exact return components (latest month's bill, YoY change, trailing-12-month total, monthly series, annual bill-by-family board). It clearly distinguishes from siblings like get_tariff_dollars_by_country and get_tariff_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 clarifies this is specifically the ETI's numerator in dollars, NOT total U.S. customs revenue, and scoped to the tracked manufacturing panel — clear context for when it's appropriate. It also dictates the source citation ('Cite the returned url') and explains the points parameter usage ('Use points='latest' or a number to trim the series'). It doesn't explicitly name alternative tools when the full customs total is needed, but the sibling set makes that inferable.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It does well: it explicitly discloses that totals are a FLOOR (only summing family-years where the country is a named top source), cites USITC public-domain sourcing, and instructs the agent to cite the returned URL. This is genuine behavioral context beyond the schema, though it doesn't detail things like data freshness or pagination.

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

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

The description is dense but not bloated; it front-loads the purpose, states outputs, gives the use-case question, param guidance, a key caveat (FLOOR), and sourcing in a compact paragraph. Every sentence earns its place. Slightly long but appropriately detailed for a data-returning tool.

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

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

Given no output schema and no annotations, the description compensates well by listing the returned fields (ranked, shipped value, effective burden, per-year duty trend) and warning about the FLOOR interpretation. For a single-optional-param tool, this is solid coverage. It could ideally add data recency, but the public-domain citation and caveat are strong.

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 there's only 1 voluntary parameter ('country'), which the schema already documents well. The description adds meaning beyond the schema by explaining the optionality semantics (omit for the full board) and the accepted forms (slug or name with examples like 'china', 'mexico'), reinforcing how the omission vs. presence changes 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 what the tool does: 'Get Tariff Dollars by Country' with a specific verb, resource (duties paid by origin country), and the exact outputs (ranked board, shipped value, effective burden, per-year duty trend). It even phrases the use case as a question ('who pays America's manufacturing tariffs, in dollars?'). It doesn't explicitly distinguish from siblings beyond being country-focused, but among the many tariff-adjacent sibling tools the country-origin framing is reasonably distinct.

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 instructions: pass a country slug/name for a specific origin, omit for the full ranked board. This is functional guidance. However, it doesn't explicitly say when to prefer this over sibling tools like lookup_tariff, get_tariff_bill, or get_tariff_effect, which deal with related but different tariff aspects. The use-case question helps infer fit, but no exclusions or alternatives are named.

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 full burden — and it excels. It explicitly warns this is OBSERVATIONAL co-movement, not causal (listing demand, FX, other policy, pandemic confounders), clarifies the metric is declared customs VALUE (price x quantity) not physical volume, and mentions a URL to cite. This is exemplary behavioral disclosure beyond the schema.

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

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

The description is dense and front-loaded with the core purpose, then the scope, then important caveats. It's a longer description but every sentence earns its place — the caveats and verb/volume clarifications are genuinely necessary for correct use. Slightly long but nothing is wasted.

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 one optional parameter and no output schema, the description is thorough: scope threshold, single-family vs full-board behavior, ranking behavior, metric definition, causal caveats, and the URL instruction. The response format (fell/held/rose verdict) is described. Nothing critical is missing for an agent to invoke and interpret this correctly.

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

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

Schema coverage is 100% with the 'family' param documented with examples ('steel-flat-rolled', 'hand tools') and the omit-for-full-board behavior. The description reinforces the parameter semantics by explaining that 'omit it' yields the full board ranked by biggest rate step, adding the ranking behavior not present 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 ('Get') with a clear resource ('Did the Tariff Work?' analysis) and precisely defines scope: tracked U.S. manufacturing families with a trailing-12-month tariff rate step-up of at least 5 points, comparing customs value before vs after. It distinguishes from siblings by the specific analytical question it answers.

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 how to use it ('Pass a family key or label for one family; omit it for the full board ranked by biggest rate step') and what question it answers ('did the tariff on X reduce imports?'). Clear entry criteria (5-point step threshold) and mentions the URL to cite.

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 discloses data sourcing (USITC public-domain), periodicity (monthly since 2014-01), the denominator formula, and that results are rebased to an index. However, it doesn't disclose what happens on empty data, freshness/update cadence expectations, or any error behaviors. Decent but not exhaustive disclosure.

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 dense sentences plus a return-value enumeration. Each clause earns its place. Front-loaded with the core definition, then return format, then citation guidance. Somewhat long but information-dense without 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 single-optional-param read tool with no output schema, the description covers the metric definition, data source, periodicity, return contents (latest reading + full series + download URLs), and citation instructions. This is about as complete as one could reasonably expect for a filter 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% and the points parameter is well-described in the schema ('all', 'latest', or integer N for last N months). The description adds the default behavior ('all' is default). Baseline 3 is appropriate since schema carries the meaning adequately.

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

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

Clear verb+resource: 'Get the U.S. Manufacturing Effective-Tariff Index' with precise definition of what it measures. Distinct from siblings (distinguishes itself as the 'citable benchmark' vs statutory MFN), but shares the get_ prefix used by many sibling tools so differentiation is only mild.

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?

Does not explicitly state when to use vs alternatives or when-not to use. The 'empirical counterpart to the statutory MFN column' hints at positioning but doesn't name specific alternative tools like lookup_tariff or get_tariff_effect that an agent might confuse it with.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses the data limitation (OEWS medians are a survey-year snapshot, not cost-of-living adjusted), the public-domain status (BLS), and the required citation behavior. This is comprehensive transparency for a read-only data retrieval tool given the zero 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 dense and front-loaded with specific value content, but it is somewhat long and packs in multiple data streams (per-trade wages, state index, pressure gauge) into a single run-on statement. It's efficient and every clause adds value, but a slightly tighter structure would improve scannability.

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-optional-parameter read-only retrieval tool with no output schema, the description is complete: it names the data source, the metrics returned, the parameter syntax and omission behavior, the caveats, and citation requirements. There are no gaps for an agent to misinterpret the tool's scope or output.

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 still adds significant meaning beyond the schema's bare definition. It clarifies that 'trade' accepts a key, label, or SOC code (matching the schema example), explains the omit-to-get-full-board behavior, and gives concrete examples ('machinist', 'welder', '51-4041'). This meaningfully supplements 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 ('Get') with a clear resource (Manufacturing Wage Board) and enumerates exactly what it contains: BLS OEWS median wages per trade, highest/lowest-paying states, a per-state wage index, and an earnings pressure trend. It even provides example questions it answers. This strongly distinguishes it from siblings like get_state_cost_index and get_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 explicitly states how to use the optional trade parameter ('Pass a trade key... for one trade; omit it for the full board plus the state index and pressure gauge'), clarifies the data caveats (survey-year snapshot, not cost-of-living adjusted), and instructs citation ('Cite the returned url'). This is excellent when/usage 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?

No annotations are provided, so the description carries the full burden. It does disclose that data comes from USITC rather than a customs ruling, which is a meaningful transparency note. However, it doesn't clarify response format, pagination, error conditions (e.g., invalid HTS code behavior, no-match queries), or rate-limits. For a read-only lookup tool, the disclosure is decent but not rich.

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

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

The description is a single dense paragraph covering purpose, query modes, data content, and authority caveat. It's information-rich and front-loaded with the core purpose. Slightly long for a lookup tool, but every clause adds value; it could benefit from minor restructuring into clearer sections but remains 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?

This is a moderately complex lookup tool with rich output (statutory rates, effective rates, import prices, source countries, HHI verdict). No output schema exists, so the description compensates by enumerating the return dimensions thoroughly. It covers query modes, data coverage, and authority. Could mention output shape/format, but given no output schema, the description does substantial compensation work.

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 both parameters (query, limit) are documented in the schema. The description adds query format guidance (keyword/family key/HTS code with examples) beyond what the schema provides, and clarifies limit's default (5) and max (10). This adds meaningful context on top of the schema, so a 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 what the tool does: look up current U.S. import tariff rates on manufacturing materials, with a specific verb ('look up') and named resource (U.S. import tariff rates, statutory HTS duties, effective rates, HHI verdict). It distinguishes itself from siblings by its focus on tariff lookup, reference data source (USITC), and explicit note that it's not a customs ruling.

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 how to query the tool ('Query by keyword, family key, or HTS code/prefix') with concrete examples ('fasteners', 'steel-fasteners', '7318'). It also clarifies the authority of the data ('Reference data from USITC, not a customs ruling — cite the returned url'), telling the agent when this tool is appropriate vs. when to defer to a ruling.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It transparently admits scope limits: only includes dollar landed cost where an implied unit price exists, otherwise ranks by uplift only. It also discloses the data source (USITC DataWeb) and the 'not a customs quote' caveat. It could add pagination/limit behavior and return structure, but for a non-mutating lookup tool the disclosure is strong.

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, tightly packed with functional information. Every sentence earns its place: methodology, return contents, usage call pattern, and caveat. Slightly dense in the second sentence with technical terms (uplift, HHI), but no wasted words; could be split for readability but remains efficient.

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

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

Given a 1-parameter tool with no output schema, the description comprehensively covers input semantics, return contents (duty, freight, uplift, unit price, HHI, FX direction), and interpretation caveats. It lacks explicit return shape/limits, but with no output schema and a simple lookup-style tool, the coverage is strong. Could mention result count or ordering but is otherwise 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%, so the baseline is 3. The description adds meaningful semantics beyond the schema by explaining what values to use (explicit examples 'steel-flat-rolled', 'bearings', 'aluminum-semis') and how omitting the parameter changes behavior (list all families). This elevates it above the baseline 3 because it explains the enumeration semantics and family-key format not captured 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: 'Rank the source countries for a U.S. manufacturing import family by fully-loaded landed cost' with concrete examples of family keys. It clearly differentiates from siblings like get_tariff_index, get_source_shift, and get_import_price_movers by emphasizing landed cost ranking across source countries, distinct from tariff-only or cost-index tools.

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

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

Explicitly states when to use ('to answer where is it cheapest to source X from'), how to call (pass family key or omit for all families), and the methodology (duty+freight uplift, HHI concentration, FX direction). It also adds an important exclusion/caveat: 'a sourcing indicator, not a customs quote — cite the returned url', guiding correct interpretation versus a precise customs valuation.

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 and delivers richly: it discloses the methodology formula (0.45 tariff + 0.30 import dependence + 0.25 concentration), versioned methodology, monthly series back to 2014, that it's a screening indicator built on USITC public data (not sourcing advice), and that it returns a url to cite.

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 efficient, front-loading the purpose and question it answers. It packs methodology, scope, and caveats into two sentences. Slightly long but every clause earns its place; the formula detail is valuable and not padded.

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-optional-param tool with no output schema, the description fully explains inputs, outputs (score components, monthly series, url), methodology transparency, data source, and use case. There's no ambiguity left for the agent regarding what it will get back.

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 single 'family' parameter, and the description adds concrete examples ('bearings', 'steel-flat-rolled', 'machine-tools-cutting') plus the omit-for-leaderboard behavior. It enhances the schema by explaining what omitting does and giving realistic key formats.

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 a specific verb-resource pair (get Reshoring Readiness Index) with a clear scope: a 0-100 monthly score for U.S. manufacturing import families. It explicitly answers the questions it serves and distinguishes itself from siblings like 'reshoring_break_even' and 'source_shift' by specifying what the index measures and how it's weighted.

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 guidance on when to use the tool ('should the US reshore X?') and explains the family-key vs. omit-for-leaderboard distinction. However, it doesn't explicitly name alternatives or state when NOT to use this tool versus the closely related reshoring_break_even or source_shift siblings.

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

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

No annotations are provided, so the description carries full burden. It discloses meaningful behavioral traits: input provision mechanics (field key or slugified label referencing get_calculator), default-fallback behavior for missing inputs, and the return format (labeled results with units, formula, citation URL that should be shared). This gives the agent a good sense of side effects and output expectations, though it doesn't describe side effects/state changes (none obvious for a calculation executor).

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, every one earning its place: how to execute, how to provide inputs, and what the return includes. No fluff, no redundancy with the schema or annotations. 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?

With a nested 'inputs' object parameter and no output schema, the description compensates well by explaining the input value format (field key or label param, e.g. availability) and describing output composition (labeled results with units, formula, citation). The description could be more explicit about the citation URL being required to share, but it does state it. It lacks some detail on edge cases (e.g., what happens when an unknown field key is passed), but is reasonably complete for a well-designed calculator execution 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 description coverage is 100%, so the parameters are already documented. The description adds meaningful context beyond the schema: how the 'tool' slug is sourced (from search_calculators, per schema, referenced), the input key formats ('field key or slugified label' referencing get_calculator), and what happens with missing inputs (use documented defaults). This adds value over the schema's basic key/type documentation.

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

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

The description uses a specific verb ('Run') with a clear resource ('a manufacturing calculation'), and explains the execution model (inputs by field key or slugified label, defaults for missing inputs, labeled results with units, formula, citation URL). This clearly distinguishes it from sibling tools like get_calculator (which retrieves calculator definitions) and search_calculators (which finds them).

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

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

The description explains how to provide inputs (by field key or slugified label, referencing get_calculator) and notes the behavior of missing inputs falling back to documented defaults. It also states results include a citation URL that should be shared with the user. It implies when to use this tool (to actually execute a calculator, versus get_calculator for definitions) but does not explicitly state what NOT to use it for or name alternatives/exclusions.

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 it returns 'matching calculators with their tool slug' — useful for understanding output — but doesn't mention what happens with no matches, result ordering, or any cost/rate concerns. For a read-only search tool with no annotations, the disclosure is reasonable but not comprehensive.

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, both substantive and task-relevant. The first defines scope and categories; the second explains the output (slug) and its downstream use (run_calculator). No filler or redundant phrasing. It earns a 4 for efficiency, slightly short of 5 because it could have packed in result-count or example detail, but there's zero waste.

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

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

This is a simple search tool with only 2 parameters and no output schema, so the burden is low. The description covers purpose, scope, and output use case for run_calculator. It lacks a note on error/empty-result behavior or whether fuzzy matching applies, but for a discovery-only tool the coverage is adequate and slightly above minimal.

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 both parameters (query, limit) are already documented in the schema itself. The description adds modest value beyond the schema by hinting at the query's purpose ('what to calculate') via the example 'injection molding cycle time', but this largely restates the schema. Baseline 3 is appropriate since the schema handles documentation.

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

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

The description clearly states 'Search MFG Calcs' library of 5,400+ manufacturing calculators' with a specific verb (search), resource (calculator library), and scope (5,400+ with enumerated categories). It purposefully distinguishes from sibling tools like get_calculator (which presumably retrieves a specific calculator) and search_site, positioning itself as the calculator-discovery entry point that returns slugs for 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 its usage context by stating it returns tool slugs for run_calculator, establishing a clear follow-on workflow. However, it doesn't explicitly state when NOT to use it versus alternatives like get_calculator or search_site. The workflow linkage gives adequate guidance but lacks explicit exclusions between sibling discovery 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 are provided, so the description carries the full burden. It discloses that the tool returns 'typed matches with URLs to cite,' which is useful behavioral context about output shape. However, it doesn't disclose pagination, ordering, case-sensitivity, or what happens with no matches. For a read-only search tool, this is modest but acceptable disclosure.

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, zero waste. Front-loaded with purpose, dense with useful specifics (exact counts of data series and tariff families), and ends with a crisp sibling-tool pointer. Every clause earns its place.

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

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

For a search tool with well-documented schema (100% coverage) and no output schema, the description provides ample context: scope, alternative tool, expected return type ('typed matches with URLs to cite'). The enumerated content categories set accurate expectations for what the agent will retrieve. This 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?

Schema description coverage is 100%, so both parameters (query, limit) are already documented, including the query example values. The description adds the semantic notion that query accepts free-form natural language ('Anything'), which complements the schema. Baseline 3 is appropriate since the schema handles the parameter documentation.

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

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

The description uses a specific verb (search) with a clear resource scope ('everything on mfgcalcs.com beyond calculators') and then enumerates concrete categories (64 economic data series, 57 tariff families, state cost data, categories, datasets). It explicitly distinguishes from sibling search_calculators, making the boundary unmistakable.

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

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

The description clearly states when to use this tool (search for non-calculator content on the site) and explicitly names the alternative search_calculators for the 5,407 calculators. It doesn't give explicit 'when not to use' beyond the calculator exclusion, but the alternative pointer is strong context for a search tool.

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