Corpus Law

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

The description goes beyond the annotations. Annotations include readOnlyHint=false and idempotentHint=false, but the description adds crucial details: 'Free — this call does not consume a credit' and 'Also mints your referral code on first use, so it is the one Corpus tool that writes.' This explicitly discloses the write side-effect and the cost behavior, which the annotations alone do not communicate. No contradiction; the description aligns with readOnlyHint=false.

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 paragraph but stays focused and efficient. Each sentence adds value: purpose, usage timing, cost behavior, anonymous mode, and the write side-effect. It front-loads the main action and avoids redundancy. The length is justified by the need to convey the non-obvious write behavior and free nature.

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 params) and the existence of an output schema, the description covers all necessary aspects: what it checks, when to use it, cost (free), authentication modes, and the explicit write side-effect that might surprise callers. An agent can confidently decide to call it and understand the implications. No missing critical information.

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 schema covers 100% of them (none). The baseline for 0 params is 4. The description explains what the tool reports (balance, tier, limits, upgrade options) and clarifies that no input is needed, which is sufficient given the empty schema.

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

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

The description clearly states the tool's function: 'Check the credit balance, tier, rate limits, and upgrade options for the API key on this connection.' It uses a specific verb ('check') and a well-defined resource (the API key context). It also distinguishes itself from the sibling tools (formation, law) by focusing on account status, and even differentiates within the tool family by noting it is 'the one Corpus tool that writes.' No ambiguity.

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

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

The description provides explicit guidance on when to use it: 'Use it to budget before making metered calls.' It also explains the two scenarios (with/without a key) and that it works anonymously. However, it doesn't explicitly say when *not* to use it or mention alternative tools for similar actions, though the siblings are clearly different domains. Given the clarity of the context, this is strong guidance, though not exhaustive.

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 adds useful behavior beyond the read-only and idempotent annotations: it explains the tool returns a list of missing items, must be re-invoked until COMPLETE, generates a link with all details pre-loaded, and is free/does not consume credits. This clarifies the exact expected loop and downstream user actions.

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 bit long but every section earns its place: purpose, required payload, iterative workflow, final handoff behavior, and cost. It is front-loaded with the core action. Minor redundancy exists in the list of 'people, address, management, EIN answers' when 'pass everything' already covers it.

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 12 parameters, nested objects, and an output schema, the description provides a complete operating contract: how to start, how to handle incomplete responses, when to stop, what the final link does, and that it costs no credits. The existing schema covers parameter details and the output schema covers return structure.

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

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

The input schema has 100% description coverage and includes rich per-property explanations, so the description does not need to repeat them. The tool-level description contributes general 'pass EVERYTHING' advice and points to the checklist, but adds no direct parameter-by-parameter meaning beyond the schema.

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

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

The description clearly states it 'validates a formation draft and generates the prefilled handoff link', which is a specific verb plus resource. It also distinguishes itself from formation.requirements by referencing that tool as the checklist source, and from the law.* siblings by its explicit handoff goal.

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 strong contextual usage guidance: pass everything collected, keep calling until COMPLETE, then hand off the link. It references formation.requirements for the checklist, but does not explicitly state when not to use the tool or compare directly with sibling tools.

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

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

Annotations already communicate read-only, idempotent, and non-destructive behavior. The description adds useful behavioral guidance: present 2–6 candidate options to the user and confirm before recording one, plus the fact that it is free and does not consume credits. No contradiction with 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 two sentences with the main purpose front-loaded, followed by necessary usage context and an important interaction note. No filler or redundant detail.

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 lookup with an output schema and safety annotations already provided, the description covers the purpose, when it is needed, the expected user-confirmation workflow, and cost behavior. Nothing essential 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?

The input schema already fully describes the single parameter with 100% coverage, and the description essentially repeats that it takes a plain-English business description. There is no significant additional parameter-level meaning, so the baseline score of 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?

Description states a specific verb and resource: 'Find candidate NAICS industry codes for a plain-English business description.' It also adds the business-formation context, which clearly separates this tool from the sibling tools. The resource and action are 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 for when to use the tool: needed for every LLC and for nonprofits in specified states. It does not explicitly name alternatives or when-not-to-use it, but no sibling tool is a direct NAICS competitor, so the context is adequate.

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, and non-destructive. The description adds value beyond annotations by stating it is free and does not consume credits, and by detailing the retrieval nature of the tool. No contradiction with 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 a single, information-dense sentence that front-loads the core purpose ('Get the EXACT intake checklist') and includes actionable guidance. While packed, it remains structured and clear, with no redundant fluff. Minor length is justified by the amount of useful context.

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?

Combined with the output schema and annotations, the description provides comprehensive context: what it returns, the expected workflow (call first, then intake), and cost implications. Nothing essential is missing for an agent to correctly invoke the tool and proceed with the intake process.

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 both parameters (state and entityType), so the schema fully documents parameter meanings. The description does not add additional parameter-level detail; it only mentions the output content, which is not about input parameters. 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?

States a specific verb ('Get') and resource ('intake checklist to form an LLC or nonprofit in a state'). Clearly differentiates from siblings by positioning itself as the first call for formation and describing the exact content (required fields, quirks, pricing, EIN add-on).

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

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

Explicitly instructs 'Call this FIRST when the user wants to form a company' and directs the agent to collect answers in conversation. Also notes it is free and consumes no credits, providing clear context for when and how to use it versus other 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?

Annotations already carry the safety profile (readOnlyHint, idempotentHint, non-destructive, openWorldHint). The description adds what the tool returns (full text, citation, hierarchy) but does not add deeper behavioral context such as failure behavior or handling of missing/invalid IDs. This is acceptable but modest given 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?

A single, focused sentence that front-loads the purpose and input origin. No filler or redundant phrases; every part contributes to understanding the 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?

The tool is simple, has one required parameter, a rich schema description, strong annotations, and an output schema. The description tells the agent exactly what it will retrieve and how to identify the provision, which is sufficient for correct invocation.

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

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

Schema description coverage is 100%, so the description's mention of 'node id (a UUID returned by law.search)' largely restates the schema's parameter documentation. It reinforces the source of the ID but adds no genuinely new meaning beyond structured metadata.

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 ('Fetch'), a clear resource ('full text, citation, and hierarchy of a single legal provision'), and the key identifier type ('node id' UUID). It also ties the input to law.search, which helps distinguish this single-provision lookup from search and coverage siblings.

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 makes the usage context clear: call this when you already have a node UUID from law.search. It does not explicitly state when not to use it or name alternatives, but the workflow implication is strong enough for an agent to select it correctly.

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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond those annotations by disclosing the specific kinds of information returned, including a placeholder flag that signals incomplete or stub coverage. This is genuinely useful transparency.

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

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

Two front-loaded sentences carry substantial meaning without any waste. The first sentence states the operation and its returns; the second sentence gives the practical usage trigger. Every part 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?

The tool is a simple zero-parameter list operation, the output schema exists and can define return values, the annotations cover safety, and the description communicates what the operation is for and when to invoke it. Nothing essential for calling 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?

The tool has zero parameters and the schema coverage is 100%, so there is no parameter ambiguity. With 0 params, the baseline is 4, and the description appropriately needs no parameter-level explanation.

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

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

The description clearly states a specific action ('List') and resource ('jurisdictions'), and further specifies exactly what is included: federal, state, and municipal jurisdictions, provision counts, searchable-chunk counts, GIS status, and placeholder flags. It also distinguishes itself from the search-related siblings by framing this as a coverage-discovery tool.

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

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

The description gives explicit usage context: call this before searching to see what law is available and searchable. It implies contrast with law.search and law.get_node, but does not explicitly state when not to use it or name the alternative tools, so it stops just 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations by stating it 'returns ranked provisions with verbatim citations, headings, and snippets,' informing the agent about output shape and ranking behavior. It does not discuss pagination or rate limits, but for a search tool with an output schema this is sufficiently transparent.

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

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

Every sentence earns its place: purpose, usage rationale, return format, workflow sequencing, and jurisdiction scoping are all packed into a compact description. The most important information is front-loaded, and the reference to sibling tools is woven in naturally. No filler or redundant repetition of the schema.

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 annotations, full schema coverage, and presence of an output schema, the description covers everything needed to select and invoke the tool correctly. It explains what the tool returns, how it relates to law.get_node, and how to scope with jurisdiction. There are no significant gaps that would leave an agent uncertain.

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 because the schema already documents all four parameters well. The description reinforces the jurisdiction parameter by pointing to law.list_coverage and mentioning sub-jurisdictions, which is already in the schema. It adds no fundamentally new parameter meaning beyond what the schema provides, 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 opens with a specific verb and resource: 'Search US federal, state, and municipal law by topic or keyword.' It clearly distinguishes itself from the sibling law.get_node by stating it discovers relevant law first, while law.get_node retrieves the full official text. An agent can immediately tell this is the search-and-discover tool among the siblings.

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 provided: use it for any question about current law rather than relying on training data, and call it first before law.get_node. It also instructs the agent to pass jurisdiction and consult law.list_coverage for valid codes, naming the exact alternative for scoping. This leaves no ambiguity about when or how to invoke the tool.

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