LeaveSheet: Davis-Bacon wage rates and WH-347 certified payroll

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so safety is covered. The description goes further by disclosing the actual computation path (all-hours divisor, over-credit and fringe owed on DBRA hours, defined-contribution pension exception checks), which tells the agent what the tool will decide rather than just that it is a safe read.

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

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

Three sentences, front-loaded with the usage condition, then the regulatory mechanics, then a compact example. The example earns its place by disambiguating the math, though the parenthetical plan list and the trailing example add density that could be trimmed slightly.

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

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

For a regulatory calculation with a nested plan object, the description supplies the formula, the exception logic, and a concrete example, and an output schema exists so return values need not be described. The nested plan booleans are the only real gap, left to the schema's enum and property names alone.

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 80%, so the baseline would be 3, but the worked example maps every top-level parameter to a concrete value and clarifies the key semantic relationship (dbraHours is a subset of totalHoursWorked used as the credit denominator). It stops short of explaining the nested plan flags (unfunded, exceptionGranted, vestsWithinFirst500Hours), which remain the agent's inference.

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: computing the hourly fringe credit a plan may take on Davis-Bacon payrolls, with the regulatory basis (29 CFR 5.25(c)) and the exact operation (plan cost divided by all hours worked). It is clearly distinguishable from siblings like reconcile_fringe_6b or build_certified_payroll, which concern reconciliation and payroll construction rather than deriving a single hourly credit.

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 gives a concrete triggering condition: a contractor pays a fringe plan for a worker who also does private work and needs the DBRA hourly credit. That is clear when-to-use guidance, but it never names an alternative tool or an exclusion case, so the agent must infer routing from siblings on its own.

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, and the description adds genuinely new behavioral context: it returns a link, files are generated in the browser, crew data travels in a URL fragment never sent to the server, and SSN digits are entered only client-side. This is exactly the extra context structured fields cannot convey.

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

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

Front-loaded with the trigger, followed by return behavior and the privacy constraint in tight sentences. No sentence is redundant with the schema or annotations, and every one carries actionable information.

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

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

Despite a complex two-parameter schema with deep nesting, the description plus an existing output schema cover the essentials: when to invoke, what is computed, what is returned, the privacy model, and the size limit. Nothing an agent needs to call 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 100%, so the schema baseline is 3. The description adds parameter-level constraints not in the schema — do not include SSNs or addresses in the arguments, and the 50-worker cap — which meaningfully shapes how the two top-level arguments are populated.

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 (build/produce) + resource (weekly WH-347 certified payroll) with the output format named (PDF or Excel). It is clearly distinguishable from siblings like check_crew_pay or reconcile_fringe_6b, which validate rather than build the export.

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?

"Use when the user is ready to produce the weekly certified payroll" gives a clear trigger condition, and "Do not put SSNs or addresses in the arguments" is a concrete precondition. It does not name alternative sibling tools or state when *not* to use it, 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/non-destructive/closed-world, yet the description still adds substantial behavioral depth beyond them: it enumerates the computations performed (base vs fringe due vs paid, overtime recompute on hours over 40, apprentice registration and daily ratio checks, restitution totals), cites the governing CFR sections, notes each amount carries its citation, returns WH-347 lines as paid, and flags the 50-worker cap.

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 trigger condition and the computed outputs, then the input-mode choice, then a worked example. Dense but every element (CFR citations, worker cap, example) informs invocation. The example string is long, slightly testing the length budget, but it is concrete and earns its space.

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?

An output schema exists, so return values need not be restated, and the description instead covers what matters for correct invocation: trigger, dual input paths, worker cap, and the regulatory checks executed. For a 4-parameter, nested-worker tool this is 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 75%, so the schema already documents most fields. The description adds the non-obvious semantics: the wdText/wdRowId linkage to get_wage_rates on the same text, the alternative direct 'rate' path, the 50-worker limit, and a worked example showing stByDay, paidBaseRate and segment structure. The one gap is that apprentice and overtimeClause inputs are not explained in the 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?

States a specific verb+resource ('check a crew's pay against the wage determination') and immediately narrows it to the Davis-Bacon question: was each worker paid at least the WD rate for a payroll week. This clearly distinguishes it from siblings like get_wage_rates (which supplies row IDs) and build_certified_payroll.

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?

Opens with an explicit when-to-use trigger ('Use when the user wants to know whether each worker ... was paid at least the WD rate') and resolves the key input decision: pass wdText with wdRowId from get_wage_rates on the same text, or supply rate directly as read in the contract. It names get_wage_rates as the upstream call, but does not state explicit exclusions or when a sibling tool is the better choice.

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 and closed-world, so the safety profile is covered. The description adds useful non-annotation context: the input is user-pasted raw WD text spanning 'General Decision Number' to 'END OF GENERAL DECISION', plus a worked example of what the inputs look like. It does not restate what the annotations already say.

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 lead sentence states the trigger, a second states the output, and the example is appended compactly. Front-loaded and mostly waste-free, though the example is somewhat long relative to the information it conveys.

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 an output schema present and rich annotations, the description need not explain return values or safety. It supplies the trigger, the input expectation and a concrete example, so an agent has everything required to select and call 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%, so the baseline is 3; the schema already documents the 400k limit, line-break preservation and the rowId-stability requirement. The description goes slightly beyond by showing a concrete example value for each text parameter, helping an agent recognize valid input, but adds no syntax or format detail the schema lacks.

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 (compare) plus a precisely scoped resource: two modifications of the same wage determination. The description also enumerates the output content (classifications added/removed, base/fringe changes with old and new amounts), which distinguishes it from sibling tools like find_wage_determination or get_wage_rates.

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 a concrete trigger ('use when the user asks what changed between two modifications of the same WD') and the precondition that both texts are pasted, with a real-world example of the two revisions. It implies the exclusion of different-WD comparisons but never names an alternative sibling tool explicitly.

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, closed-world behavior, so the safety profile is covered. The description adds real substance beyond that: it computes rather than mutates, evaluates three regulatory criteria each returning yes/no/to-verify, and depends on wdText being re-passed so rowIds remain valid. It does not discuss error or validation behavior.

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

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

The trigger condition is front-loaded in the first sentence and every following clause carries operational content (criteria, neighbour sourcing, worked example). It is dense but not padded, though the single long run-on sentences make it slightly harder to scan than it could be.

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 10-parameter tool with nested objects and an output schema, the description covers the workflow, the regulatory check, the two ways to supply related classifications, and a full example call. Return values are handled by the output schema, so the remaining 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?

With 60% schema coverage, the description compensates well: it names the three criteria semantics behind the answers object, explains that neighbourRowIds requires wdText while neighbours is supplied directly, and gives a concrete example object showing missingClassification, tasks, wd, wdText, neighbourRowIds and proposed together.

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 first sentence states a precise verb and resource with its trigger: drafting an SF-1444 when a worker performs a classification missing from the WD. It then enumerates exactly what the tool does (fills SF-1444 fields, compares proposed rate against related classifications, checks 29 CFR 5.5(a)(1)(iii)(A) criteria), which no sibling tool does.

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

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

It gives an explicit when-to-use condition (a missing classification that the contractor must ask the CO to add) and routes the agent to the sibling get_wage_rates to source neighbourRowIds from wdText. The relationship between neighbourRowIds and the directly-supplied neighbours alternative is spelled out.

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?

Beyond the annotations (readOnly, idempotent, openWorld=false), the description discloses a non-obvious behavioral trait: 'This tool makes no network call' — it explains and constructs a link rather than fetching the WD, which materially changes what an agent should expect. It also describes the conditional logic keyed on wdText plus awardDate. It does not cover error/empty-result behavior, so it falls short of 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 usage trigger, then flows through behavior, conditional logic, and an example without wasted sentences. It is dense but each clause carries distinct information (no-network behavior, link construction, CFR citation, conditional path, handoff). Slightly long, but nothing is 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?

With annotations covering safety/idempotency and a full output schema covering return values, the description supplies the remaining needed context: what the tool does, the no-network constraint, the conditional reading path, and the downstream get_wage_rates call. It is complete enough to call correctly; minor ambiguity remains around behavior when only state is supplied (the sole required param).

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, but the description adds real meaning: a concrete example (state="TX", county="Travis", constructionType="Highway", awardDate="2026-06-01") and the conditional relationship between wdText and awardDate that drives the modification-selection logic. The instruction to reuse the same wdText across calls ties into the rowId stability noted in the schema, adding connective value.

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

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

The description names a specific resource (the Davis-Bacon general wage determination) and precisely enumerates the four things the tool does: locate/explain where the WD is, build the sam.gov link with filters, quote the 29 CFR 1.6(c) revision rules, and resolve the applicable modification from pasted wdText. This distinguishes it from siblings like get_wage_rates and compare_wd_revisions, which operate on data rather than enabling discovery.

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 opens with an explicit trigger ('Use when the user needs the general wage determination ... for a federally funded construction project') and clarifies the conditional path (only reads the modification table if the user pastes wdText with awardDate). It also routes to the correct follow-up tool ('Then call get_wage_rates with the pasted text'). It stops short of stating when *not* to use it relative to siblings like compare_wd_revisions.

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 readOnly/idempotent/non-destructive, but the description adds genuinely useful behavior: it returns parse confidence, a verbatim excerpt and the sam.gov page for verification, and warns that rowId stability depends on re-passing identical text. It does not discuss size/rate limits or how partial parses are surfaced beyond the confidence field.

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 trigger condition and prerequisite, then return shape, then reuse rule, then example — a logical order with no filler sentences. The parenthetical asides ('craft, classification, zone, base and fringe $/h with the rule they come from') make the single paragraph dense but not wasteful.

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 3-parameter parsing tool with a full output schema, the description covers the prerequisite input format, the search semantics, the return contents, the verification affordance, and the cross-tool contract for rowId. An agent has everything needed to invoke it correctly and to know what to do with 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 description coverage is 100%, so the baseline is 3; the description adds value with a concrete invocation example (wdText="General Decision Number: TX20260291 …", search="welder") that shows the expected string format for both the required paste and the search term. That is real added meaning over the 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?

Specific verb and resource: reads pasted wage determination text and returns matching classification rows with base/fringe rates. It clearly distinguishes itself from find_wage_determination by requiring the user to already have the WD text, and names the downstream consumers (check_crew_pay, draft_conformance_request) of the rowId it produces.

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 trigger condition is given — 'when the user needs the prevailing base rate and fringe of one or more classifications and has the text of the WD' — which implicitly excludes the case where the text is unavailable (find_wage_determination territory). It also states the reuse rule (pass the same text again so rowIds stay valid). The alternative lookup tool is never named outright, so it falls short of a full when/when-not/alternatives statement.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safe, repeatable nature is covered. The description adds genuinely useful behavior beyond that: the exact reconciliation criterion (|sum 6B − sum plans| < 0.005), per-line and per-plan aggregation, and the 50-worker cap. Return format is not needed since an output schema exists.

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 triggering condition, then the computation contract and the limit. Three sentences with little waste, though the tolerance formula is dense and the cross-server reference adds noise without helping selection in this server.

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?

An output schema exists, so return values are covered elsewhere; annotations cover the safety profile. The description supplies the domain framing, the reconciliation tolerance and the worker limit, which is sufficient for an agent to call it correctly. Only the parameter-level detail is thin.

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?

Reported schema description coverage is 0% at the top level, and the description never explains the 'workers' array structure directly. It does implicitly map fields to WH-347 concepts (column 6B, the plan types) and states 'Up to 50 workers', which mirrors maxItems, so it adds marginal meaning, but the burden of documenting inputs largely falls on the well-described nested item fields 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 names a specific verb ('reconcile') and resource ('the fringe credited on the WH-347 (column 6B)' against 'what was paid to each plan'), and enumerates the plans involved (health and welfare, pension, vacation, training). This lets an agent distinguish it from siblings like annualize_fringe or check_crew_pay without opening the 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?

It gives a clear triggering condition ('Use when the user wants to check that... matches... for the week'), which is strong when-to-use guidance. However, it names an alternative from a different server (leavesheet-mcp) rather than differentiating from any of the seven sibling tools in this server, and gives no when-not guidance.

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