subproof

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It mentions the action and output format but does not disclose any side effects, authorization requirements, data volume, or return behavior (e.g., whether the CSV is always available, if it may be truncated, or if it requires specific permissions). This is a significant gap for a tool with 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 a single, well-structured sentence that front-loads the action and resource, then lists the specific fields. It contains no redundant or vague phrasing, and every word earns its place.

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

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

Given the tool's simplicity (no parameters, no output schema), the description covers the output format and fields, but it omits practical caveats such as data size limits, authentication requirements, or whether the export is always available. With zero annotations and no output schema, a bit more detail about the return type or potential risk (e.g., large data) would improve completeness.

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

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

The tool has no parameters, so there is nothing for the description to add beyond the schema. The baseline of 4 is appropriate because the description correctly omits parameter details that are irrelevant.

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 ('Export') and a defined resource ('the full subcontractor compliance report') along with the output format (CSV text) and the included fields. This makes the tool's purpose unmistakable and distinguishes it from sibling tools that retrieve summaries or specific subsets.

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 that this tool should be used when a complete, exportable report is needed, but it does not explicitly mention when to use this tool versus the siblings (e.g., get_compliance_summary for a summary, list_uninsured_subs for uninsured subs). No exclusion criteria or alternatives are given, leaving usage 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?

No annotations are provided, so the description carries the burden of behavioral disclosure. It clearly states the tool returns a summary of totals, which implies a read-only aggregation operation. However, it does not disclose whether the data is real-time, cached, or computed on demand, nor does it describe the output format. The description is accurate but minimal.

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

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

The description is a single, well-structured sentence that front-loads the resource and then lists the exact data points. Every word earns its place; there is no fluff or repetition.

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

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

For a zero-parameter, no-output-schema tool, the description is nearly complete. It tells the agent exactly what data will be returned. The only minor gap is the lack of explicit output format details (e.g., whether it's a JSON object with named fields), but the listed categories are sufficient for an agent to understand 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?

The tool has zero parameters, so there is no parameter semantics burden. The description fully explains what the tool returns, which is the only semantic content an agent needs. Baseline 4 is appropriate for a no-parameter tool.

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

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

The description uses a specific verb ('Get') and a specific resource ('subcontractor compliance summary'), and enumerates the exact data points returned (totals for tracked, not received, lapsed cover, lapsing this week, awaiting check). This clearly distinguishes it from sibling tools like export_compliance_report or get_expiring_cover, which have different purposes.

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 this is the tool to call when you need a summary of compliance statuses, but it does not explicitly state when to use it versus alternatives like get_expiring_cover or list_uninsured_subs. The listed data points help an agent infer the use case, but there is no explicit when/when-not 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, the description carries the full burden. It clearly discloses the core filtering behavior and the default look-ahead window, but does not specify what fields are returned, whether already-expired documents are included, or whether the operation is purely read-only.

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

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

One tightly worded sentence that places the core behavior first and adds a meaningful purpose clause. No filler or redundant restatement.

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

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

For a simple tool with one optional parameter and no output schema, the description is nearly complete: it conveys the action, the parameter semantics, and the reason to call it. A brief note on expected return contents would make it fully complete.

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

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

Schema description coverage is 100% for the single 'days' parameter, and the schema already explains the look-ahead window and default. The description restates this without adding deeper semantic context, matching the baseline.

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

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

The description uses a specific verb ('List') and resource ('subcontractor documents expiring within the next N days') and states the operational intent (renewal before coverage lapses). It is immediately distinguishable from siblings like list_uninsured_subs because it targets upcoming expirations rather than currently uncovered subs.

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 for when to call the tool: when proactively identifying documents that need renewal before a sub goes uncovered. It does not explicitly name alternatives or state when not to use it, so it stops short of full routing 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, the description carries the full burden of behavioral disclosure. It does disclose a key behavioral trait (ordering: 'most dangerous first') as well as the scope of items included (lapsed or missing insurance), which is useful. However, it does not mention whether the tool will also return sorted-by-danger or any other read-only guarantee, return format, or whether the data is live. The description is acceptable but not rich enough to carry the full burden with no annotations.

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

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

The description is one sentence with a front-loaded verb and resource, followed by a single, purposeful clause about ordering. Every word earns its place—it identifies the subject, defines the selection criteria, and highlights the output ordering. No filler, no repetition of the tool name.

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 read-only list tool without an output schema, the description captures the essential behavior: what is listed and the ordering. It does not describe the response shape or limits, but the simplicity of the operation makes that less critical. It might benefit from a brief note on whether 'lapsed' means expired in the insurance context, but it is otherwise sufficient for an agent to 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?

The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific semantics (there are none to document), but it reinforces the conceptual basis that the tool is a self-contained listing operation with no inputs. No additional parameter clarification is necessary.

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 identifies a specific verb ('list') and resource ('subcontractors with lapsed or missing insurance documents'), and adds a clear scoping criterion ('the ones creating liability exposure right now') that distinguishes it from siblings like get_expiring_cover or get_compliance_summary. The ordering ('most dangerous first') adds further precision. An agent can distinguish this tool from its siblings without inspecting 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?

The description implies a usage context — when you need to see subcontractors that currently pose liability risk — but does not explicitly name alternative tools or provide when-not-to-use guidance. It clearly telegraphs that this is for identifying immediate exposure, which is helpful, but it leaves the distinction from get_expiring_cover to be inferred. This is clear context without explicit exclusions, so 4 rather than 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?

With no annotations provided and no output schema, the description carries the disclosure burden. It does this well by stating the search behavior and enumerating the returned status values ('on file, needs check, not received, lapsed'), which are not present in the input schema. It does not mention pagination or edge-case behavior, but for a simple search tool this is acceptable.

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 compact two-sentence definition, front-loading the search criteria and then listing the output fields. Every clause adds value and no filler or irrelevant detail 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 single-optional-parameter search tool with no output schema, the description is mostly complete: one parameter is covered by the schema, and the description explains what will be returned. It is missing only minor conveniences such as return size or ordering, which are not necessary for making a correct call.

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 'query' parameter already has a thorough schema description covering case-insensitivity, shorthand, and omitted-query behavior. The tool description repeats some of that information but doesn't need to add much, 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?

The description uses a specific verb ('Search') with a clear resource ('subcontractor documents') and the two matching criteria ('sub name or document type'). It also states the returned fields, making its objective and scope immediately distinct from siblings like get_compliance_summary, export_compliance_report, get_expiring_cover, and list_uninsured_subs.

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 the tool should be used when an agent wants to find subcontractor documents by name or document type, but it does not explicitly route to alternatives such as get_expiring_cover or list_uninsured_subs. There is no 'when to use instead' guidance, so the agent must infer the boundary from sibling names and the schema.

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