ITC Prevailing Wage & Apprenticeship Guide

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

Annotations already establish the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds genuine behavioral substance by spelling out the rules the tool applies: the pre-January 29, 2023 exemption and which credits lack it, the 1 MW aggregation logic, and the ITC/PTC wage-continuation periods. It stops short of describing the answer format or how it behaves when dates are unknown or omitted.

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 content is substantive rather than padding, and the core purpose is front-loaded in the opening clause. But the entire description is a single run-on sentence of nested parentheticals (~150 words) that is hard to parse; it would benefit substantially from being split into scannable statements.

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 7-parameter determination tool with no output schema, the description covers the decision logic comprehensively across credits, dates, work type, technology, and size thresholds. Its main gap is that it never describes what the response looks like, which matters more given there is no output schema to fall back on.

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 four enums, so the baseline is 3. The description goes beyond the schema by tying parameter values to outcomes: which credits carry the construction-date exception, that apprenticeship applies to construction only while prevailing wages continue 5 years for the ITC and 10 for the PTC, and the 10/12.5/15% apprentice-percentage options. That interpretive linkage adds real meaning even though much of it echoes schema text.

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 and outcome: it says whether a project must meet prevailing wage and apprenticeship requirements to claim the increased (5x) credit. It is clearly the applicability gate among the PWA siblings, but it never names or contrasts itself with check_prevailing_wage, check_apprentice_hours, or pwa_overview, so sibling differentiation is left implicit.

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 only implied: an agent can infer this is the gating check to run before computing wage or apprentice-hour requirements. There is no explicit 'use this when' trigger, no when-not condition, and no routing to the alternative sibling tools that handle hours, ratios, or good-faith requests.

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

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

Annotations already establish readOnlyHint/idempotent and no side effects, so the bar for safety disclosure is low. The description adds substantive domain behavior beyond the annotations: the year-based percentage schedule, the categories of hours excluded from the denominator, the daily-ratio constraint on apprentice hours, and the $50/$500 cure rates.

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?

It is front-loaded with the core purpose and every clause is regulation-relevant rather than filler. The single dense paragraph with stacked parentheticals hurts scanability, but nothing extraneous is present.

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 calculation tool with no output schema, the description covers the rule, the inputs' meaning, and the shape of the return (required hours, shortfall, cure). It stops short of describing result formatting/rounding, but an agent has enough 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 description coverage is 100%, so the schema already documents all six parameters, including the good-faith-hours and participation-failure semantics. The description restates the underlying rule (exclusions, ratios) but adds no per-parameter syntax or format guidance beyond what the schema carries, making the baseline 3 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 names the exact task (the apprenticeship labor-hours requirement for one facility) with a regulatory cite and enumerates what comes back: required hours, shortfall, and the IRS cure. It is unambiguous what the tool computes, though it does not explicitly distinguish itself from the closely related sibling count_participation, which also concerns participation shortfalls.

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 implied rather than stated: it is clearly a per-facility computation used when testing the 1.45-8(b) requirement. The only routing hint ('Use check_daily_ratio to find them') appears inside a schema property, not the description, and there is no explicit when-to-use versus count_participation or check_good_faith_request.

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

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

Annotations already establish readOnly/idempotent/non-destructive, yet the description adds real behavioral substance: the regulatory test applied (1.45-8(c)(2)), what the return contains (countable apprentice hours vs excess hours), the consequence for excess hours (stay in total labor hours, paid full journeyworker prevailing rate), and honest flagging that the hours-only path is an interpretation rather than a strict result.

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

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

One dense paragraph, so the core rule and the controlling input are front-loaded, but heavy inline CFR citations and stacked parentheticals (1.45-7(b)(7)(iii), 29 CFR 5.5(a)(4)(i)) slow parsing. Every clause arguably earns its place, but readability suffers.

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

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

With no output schema, the description carries the return-value explanation itself (countable hours plus excess hours) and covers the hours-only edge case, which is the main complexity. The remaining gap is routing guidance relative to sibling compliance tools.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond it: journeyworker/apprentice headcounts are 'the controlling input', apprentice_hours_by_person lets the excess be measured per person, and the ratio parameters are defaults interpreted as the program ratio (1/1 or 2/1 examples).

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

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

The description states a concrete computation: given program ratio and daily headcounts/hours, return countable apprentice hours and excess hours. That is a specific verb+resource and an agent can tell it apart from generic siblings, though it never names check_apprentice_hours or other ratio-adjacent tools to sharpen the boundary.

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

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

It implies the input situation ('give the program ratio and, for each day, the headcounts...') and describes a fallback mode ('with hours only and no headcounts it prorates'), but it never states explicitly when to pick this tool over check_apprentice_hours or check_applicability, nor any 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?

Annotations cover the safety profile (readOnly, idempotent, non-destructive, closed world), and the description goes well beyond them by spelling out the legal model, the lead-time thresholds, the response-silence rule, the maximum exception length, and explicitly what is returned (lead-time check, response status, run length, next request date). That return-value disclosure is especially valuable given there is 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?

Two sentences, front-loaded with the core judgment and followed by the return content; each clause carries substantive criteria rather than filler. The first sentence is dense and run-on, which slightly costs readability, 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 high-complexity regulatory tool with no output schema, the description supplies the qualifying criteria, the timing rules, the coverage duration, and the shape of the result, which is close to complete. It stops short of describing the negative outcome (what an agent sees when a request fails to qualify), a minor remaining gap.

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

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

Schema description coverage is 100%, so the schema already documents all eight parameters including defaults and enum values. The description's mention of dates, occupation, location, number, expected hours and contact maps loosely onto the inputs but adds no per-parameter syntax or defaulting rules beyond what the schema carries, so the baseline of 3 is appropriate.

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

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

States a specific verb (judges) and resource (a request for apprentices) and scopes it to the Good Faith Effort Exception with a precise regulatory citation, so the agent can separate it from siblings like check_applicability. The listed criteria (45-day/14-day lead time, denial or 5-business-day silence, 365/366-day window) pin down exactly what is being evaluated.

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 thoroughly establishes the conditions under which the exception applies, which implicitly tells the agent when this tool is the right one. It does not, however, name an alternative or state a when-not case (e.g., pointing to check_applicability for prerequisite questions), so routing between siblings is left to inference.

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

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

Annotations already declare the read-only/idempotent/non-destructive profile, yet the description adds substantial behavioral detail beyond them: the multiplier for intentional disregard, the interest formula (Federal short-term rate + 6 points), the per-worker penalty amounts, the two waiver paths, and the governing regulation. This is well beyond the annotation bar.

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 core purpose is front-loaded, and for a 16-parameter computational tool the length is justified. However, the bulk is delivered as one very dense run-on sentence, which is harder to parse than a short opening plus terse bullets.

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 complex 16-parameter tool, no output schema, and annotations that already cover safety, the description is complete: it explains what is compared, what is computed, the penalty/waiver logic, and the regulatory basis. Nothing an agent needs to invoke it correctly is missing.

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 already 100%, so the baseline is 3. The description adds genuine meaning by stating the substantive rule behind the parameters — cash plus bona fide fringe must together reach base plus fringe (29 CFR 5.31) — and by directing the agent to lookup_wage_determination to populate the required rates.

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 names a specific operation — comparing one classification's pay against the Davis-Bacon prevailing rate and computing the IRS cure for any shortfall. It explicitly routes the agent to the sibling lookup_wage_determination for the rate, so it is distinguishable from the other 'check_*' 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?

Usage context is clear (a compliance check that also prices a shortfall) and it names lookup_wage_determination as the source for the required rate. It gives no exclusions or explicit routing against alternatives like check_daily_ratio or check_apprentice_hours, but the scenario it serves is unambiguous.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description goes further by disclosing the substantive counting rules, the 20% manual-share and 541-exemption logic, and even flags that this reflects "this server's reading" of the rules. That interpretive disclosure is valuable, but it says nothing about output shape beyond prose, limiting it to a 4.

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?

Every sentence carries substantive regulation-derived content with no filler, and the regulatory basis is front-loaded. The second sentence is an extremely dense run-on that nests multiple conditions, which strains readability, keeping it from a 5.

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

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

With no output schema, the description must carry the return semantics, and it does describe the three things the tool reports. Input semantics are fully covered by the schema, and annotations cover safety, so an agent has what it needs; only a cleaner statement of the return structure is missing.

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

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

Schema coverage is 100%, so baseline is 3; the description nonetheless adds real meaning by mapping role values to the counting rule (laborers/mechanics/apprentices count; supervising foreperson, exempt 20%+ owner, office staff do not; working foreperson over 20% manual duties does). This links the enum choices to the legal test rather than restating them.

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 precise verb and resource — counting whether an employer hits the four-worker threshold that triggers the apprentice requirement (26 CFR 1.45-8(d)) — and enumerates what the tool returns (who counts, whether an apprentice is required, whose hours leave the denominator). It is far from a tautology, though it never names a sibling tool to contrast against, so it stops short of the top mark.

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

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

It tells the agent what input to supply ("Give the people one employer used on this facility with their roles") and implies the goal is deciding whether an apprentice is required, which is useful context. But it gives no explicit when-to-use vs when-not, and does not route to check_apprentice_hours, check_daily_ratio, or other siblings that address adjacent questions.

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

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the bar is lower. The description adds a genuinely useful trait beyond them: reg: content is "read live from the eCFR," telling the agent results are freshly fetched rather than cached. It does not mention failure behavior for invalid ids or any rate limiting.

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

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

A single dense sentence with the verb front-loaded and no filler. Every clause (return value, provenance, id formats, live-read note) carries information.

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

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

With no output schema, the description correctly states the return value (full text) and where valid ids originate, which is what a one-parameter read tool needs. Minor gaps remain around invalid-id handling and the overlap with read_regulation, but nothing essential to invocation is missing.

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 schema only says "A document id from search," but the description supplies the actual id grammar: overview:<topic>, records:<requirement>, form7220, law2025, tennessee, reg:<section>[(paragraph)], plus a concrete example (reg:1.45-8(d)). This is meaningfully more than the schema provides and is enough to construct a valid id.

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?

States a specific verb and resource ("Returns the full text of a document") and ties it to the discovery step ("found with search"), so an agent knows this is the retrieval counterpart to search. It stops short of differentiating from the sibling read_regulation, which also deals with regulation content and could be confused with the reg:<section> ids this tool accepts.

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 phrase "found with search" implies the intended workflow (search first, then fetch by id), but there is no explicit when-to-use statement, no when-not-to-use, and no named alternative such as read_regulation. Usage is inferable rather than stated.

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

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), yet the description adds substantial behavior: TN reads a live State Apprenticeship Agency list returning program/occupation/employers/county, while other states return only pointers (apprenticeship.gov finder and a State office to contact). That output-shape divergence by state is exactly the kind of context an agent needs and cannot get from annotations.

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

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

Purpose and legal grounding lead; the TN behavior, the non-TN fallback, and the text-matching caveat follow in dense clauses with no filler. Roughly 70 words, all of which carry information.

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

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

With no output schema, the description still describes what comes back for each state branch and how filters behave, and annotations cover the safety profile. An agent has enough to call it correctly and interpret the result.

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, but the description goes beyond it by disclosing that occupation is matched as free text rather than an enum ('"electric" finds Electrician programs') and that counties narrow results with an all-state default. That matching semantic is not derivable from 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?

States a specific verb and resource ('Find registered apprenticeship programs'), names the legal basis (26 CFR 1.45-8(f)(1)), and defines the qualifying criteria (area covers facility, trains the occupation). An agent can distinguish this from siblings like check_good_faith_request or check_apprentice_hours without opening a schema.

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?

Places the tool in context ('a contractor can send a good-faith request to'), implicitly routing agents here before the good-faith-request workflow, and explains the state-dependent behavior. It does not explicitly name an alternative tool or state when NOT to use this one, so it stops short of a 5.

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

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

Annotations already declare readOnly/idempotent/openWorld, so the safety and network profile is covered. The description adds genuine behavior beyond that: data is fetched 'live' (not cached), defaults to the newest modification unless a revision is supplied, supports optional classification filtering, and returns a citable SAM.gov page.

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?

Dense but front-loaded: the fetch mode and lookup axes come first, then return shape, then applicability and fallback. The CFR citation and DOL email are long tail but each carries actionable information; the single-block format is slightly heavy 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?

With no output schema, the description still outlines the return payload (counties, modifications, per-classification basic rate and fringe, source page), covers the default/override behavior, and handles the missing-classification edge case. Nothing an agent needs to call it correctly is absent.

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, but the description adds meaning the schema does not: revision defaults to the newest modification, the number format (TN20260124), and the interpretive nuance that utility-scale solar and wind farms count as Heavy. Those mappings go beyond the enum labels.

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?

States a specific verb and resource (fetches a Davis-Bacon general wage determination) and names the live source (SAM.gov), with the two lookup axes spelled out: by number or by state/county/construction type. That level of specificity separates it from the check_* siblings that consume the data rather than fetch it.

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?

Gives real domain guidance on which determination applies ('use the determination in force when the contract was executed, 26 CFR 1.45-7(b)') and what to do when a classification is absent (email DOL). It never names an alternative sibling such as check_prevailing_wage, so tool-selection guidance is implied rather than explicit.

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

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

Annotations already declare readOnlyHint, openWorldHint=false, idempotentHint, and destructiveHint=false, so the safety profile is fully covered structurally. The description adds the useful detail that the output is a static reference set with 'one line on what each is for,' but says nothing about how the content is returned or whether it is fixed.

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?

It is a single compact sentence with no filler, and the framing ('the primary sources behind every answer here') is front-loaded. The long parenthetical source dump is dense but each item earns its place by telling the agent what to expect in the result.

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

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

With no parameters, no output schema, and annotations covering the safety profile, the remaining burden is to say what the tool returns, which the enumeration supplies. It is close to complete for a zero-argument reference tool, though it could state the return shape more explicitly.

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 accepts zero parameters, which sets the baseline at 4. Nothing in the schema needs clarification and the description correctly implies a no-argument, listing-style call.

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 names the specific resource it surfaces (the primary sources behind every answer here) and enumerates the concrete items returned (IRS pages, Form 7220, eCFR regulations, SAM.gov wage determinations, etc.), so an agent knows this is a catalog of source references. It stops short of a verb-led statement of what the tool actually does or how it differs from siblings like read_regulation or fetch.

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

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

There is no when-to-use guidance, no exclusion, and no alternative named. The description never tells the agent when to consult this list versus search, fetch, or read_regulation, even though several siblings surface overlapping source material.

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

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

Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, so the safety burden is off the description. The description adds useful scope context: it discloses that every figure is tied to a regulation paragraph and that penalties, cures, and Form 7220 records are included in 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?

Front-loads "Start here" and then dense enumerated scope in a single paragraph; every clause conveys coverage, so little is wasted. It is still long enough that skimming the topic list takes effort.

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

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

With no output schema, the description carries the return-content burden and does so well by enumerating what each topic covers. For a single optional-enum, read-only orientation tool this is nearly complete, missing only explicit routing to sibling computation tools.

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

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

Schema coverage is 100% and the enum values are fully documented, so the baseline is 3. The description adds a little beyond that by clarifying the default ("all") and the one-topic-or-all invocation pattern, though it does not map its listed topics cleanly onto the enum values.

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?

Names a specific verb (explains) and resource (IRS prevailing wage and apprenticeship requirements), and scopes it to specific credits (IRC 48/48E). "Start here" plus the enumerated content clearly separates it from the check_*/lookup_* siblings that compute individual tests.

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?

"Start here" gives a strong positioning cue for first use, and "Ask for one topic or all of them" sets expectations for how to invoke it. It never explicitly says when NOT to use it or names the sibling tools (e.g. check_prevailing_wage) that handle cases where a concrete determination is needed, so it falls short of a 5.

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

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

Annotations already declare readOnly, idempotent, openWorld, non-destructive, so the safety bar is low. The description adds real behavioral context: the text is fetched live from the eCFR, and results carry citation and URL. It does not mention fetch failures, rate limits, or what happens if a paragraph citation is invalid, which keeps it below a 5.

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 usage rule in the first two sentences, then a dense but justified enumeration of ten sections. There is mild redundancy: the CFR section numbers are listed twice, once in the opening sentence and again in the per-section breakdown.

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

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

With no output schema, the description correctly notes that citation and URL are returned, and it fully maps what each of the ten enum values will yield, which is what an agent needs to pick a section. It omits failure modes such as invalid or malformed paragraph citations on a live fetch, leaving a minor gap.

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

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

Schema coverage is 100%, so the baseline is 3, but the description meaningfully enriches the section enum by describing what each value contains (e.g. 1.45-8 covers labor hours (b), ratio (c), participation (d); 541.101 covers the 20% owner exemption). The paragraph guidance (shorthand g7, omit for whole section) largely restates the schema, so it lands at 4 rather than 5.

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?

States a specific verb and resource: returns the current text of a regulation paragraph live from the eCFR, with citation and URL. The named sections (26 CFR 1.45-6 through 48E-3, plus 29 CFR 541.101/5.5/5.31/29.5) make the scope unambiguous and distinguish it from the check_*/count_* siblings that compute rather than read.

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?

Gives concrete usage context: pass a paragraph like '(d)' or '(g)(7)' to read one part, omit it for the whole section. The 'live, eCFR' framing implies when to reach for authoritative source text versus derived tools, but it never explicitly names an alternative (e.g. pwa_overview or official_sources) or states when NOT to use it.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, yet the description still adds real substance: how records may be held, the redaction option, and that unredacted records go to the IRS on request. That is genuine operational context beyond the annotations.

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

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

One dense sentence with heavy parentheticals, but every clause carries information useful to an agent, and the core purpose is front-loaded before the record-keeping and Form 7220 details. Slightly run-on, 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?

Two optional enum parameters, no output schema, and a rich annotation set — the description supplies the domain context (regulation cite, retention/redaction rules, Form 7220 linkage) an agent needs to call and explain the tool. It does not describe the checklist's structure, but with no output schema that gap is minor.

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

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

Schema coverage is 100% with both enums and their default values documented in the schema. The description restates the role options ('a taxpayer, a prime contractor or a subcontractor') and the two requirement areas, but adds no format or edge-case semantics beyond the schema. Baseline 3.

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

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

States a specific resource — the record-keeping checklist for prevailing wage and apprenticeship requirements under 26 CFR 1.45-12 — and scopes it by role and requirement. It is clearly distinguishable from siblings like check_applicability or check_prevailing_wage, though the noun-phrase framing ('The records ... as a checklist') is less verb-forward than ideal.

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 implied rather than stated: the reader infers this is the tool for 'which records must we keep and who holds them.' No explicit when-to-use, when-not-to-use, or named alternative among the many check_* siblings is given.

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

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

The annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the return value is ids for fetch, and queries may be paragraph references like '1.45-8(d)'. It omits result limits or pagination behavior.

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

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

Front-loads the core action and the id-to-fetch contract, then lists corpora and the query-syntax example. The regulation enumeration is long but serves selection by telling the agent what is indexed; minimal waste overall.

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 one-parameter search tool with no output schema, the description covers what is searched, what is returned (ids for fetch), and query syntax. The remaining gap is disambiguation from content-specific siblings like read_regulation or pwa_overview.

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 query param, but the description goes past the schema by showing how a query can be formed (a regulation paragraph reference such as '1.45-8(d)') and that it is a single query string. That is more than restating 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?

States a specific verb and resource ('Full-text search over this guide's documents') and then enumerates the actual corpora covered, so an agent knows exactly what is searchable. It also distinguishes itself from sibling families by routing calculations to the check_* 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?

Gives an explicit exclusion ('For calculations use the check_* tools instead') and implies the search-then-fetch workflow via 'Returns ids to pass to fetch'. It does not, however, clarify how it differs from overlapping siblings such as pwa_overview, read_regulation, or records_checklist.

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