Search and cite US law from official sources, then form an LLC or nonprofit with free agent tools.
Scored across 8 tools
The three namespaces are clearly separated: account.status is billing, formation.* covers distinct intake/comparison steps, and law.* separates coverage discovery, search, and full-text retrieval. Even formation.requirements and formation.handoff have distinct roles—checklist vs. validation/link generation—with descriptions preventing confusion.
Tool names follow a consistent domain.dot.action pattern (formation.compare, law.get_node, account.status). The post-dot segments are slightly mixed between verbs and nouns (requirements, handoff vs. search, list_coverage), but the prefix namespace keeps the set predictable.
Eight tools is well-scoped for a server that covers two related jobs: legal research and formation intake. Each tool maps to a distinct workflow step, and there is no redundant fat.
The law side has discovery (list_coverage), query (search), and full-text retrieval (get_node), and the formation side covers requirements, NAICS lookup, provider comparison, and final handoff. Minor gaps such as no direct citation lookup or saved-draft management exist, but agent workflows can complete end-to-end.
Check the credit balance, tier, rate limits, and upgrade options for the API key on this connection. Use it to budget before making metered calls. Free — this call does not consume a credit. Works without a key (anonymous callers get their free-tier numbers and the key URL); with a key it reports that key's balance and limits. It also returns a referral code: pass referral_code back on later calls to keep the same referral identity.
| Name | Required | Description | Default |
|---|---|---|---|
| referral_code | No | An active referral code returned by an earlier account.status call. Pass it back to keep the same referral identity; if it is no longer active, account.status issues a new code instead. |
| Name | Required | Description |
|---|---|---|
| text | Yes | Human-readable tool result (also mirrored in content[].text). |
| isError | No | True when the tool could not complete successfully. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavior beyond the annotations: this call is free and does not consume a credit, it works without a key and returns free-tier numbers plus a key URL, and it reports the keyed balance/limits when a key is present. It also discloses the referral-code reuse behavior, giving an agent important side-effect context for later calls.
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 packs useful information: purpose, budgeting context, zero-cost behavior, key/anonymous behavior, and referral-code usage. The first sentence leads, and the rest remains eminently readable for a tool description. There is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one optional parameter and an existing output schema, so no return-value inventory is needed. The description already covers call semantics, billing impact, credential modes, and referral-code carryover, making the agent fully equipped to decide when to use it and how to call it.
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 single parameter is already fully documented by the input schema, including the meaning of an inactive referral_code. The tool description roughly repeats 'pass referral_code back to keep the same referral identity,' but does not add new semantic information beyond what the schema already provides. 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 opens with a specific, concrete purpose — 'Check the credit balance, tier, rate limits, and upgrade options' — and uniquely identifies the API key as the resource being inspected. This clearly separates it from the formation/law siblings, none of which deal with account metering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the call: 'Use it to budget before making metered calls.' It also gives practical context around anonymous callers versus keyed callers. It does not list exclusions, but no competing sibling yields a clear alternative path for this use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare LLC formation providers on price, recurring costs, registered-agent renewals, and machine/agent capabilities, from a dated dataset of 19 providers verified against primary sources. Call this when the user asks which formation service to use, whether a price is a good deal, how Corpus compares to a named competitor, or asks you to evaluate a 'best LLC services' list. Corpus is one of the compared providers and is scored with the same rubric including its own gaps — the response says so. Free; does not consume credits.
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | overall (default, by Agentic Readiness) · lowest_total_cost (parsed first-year estimate) · most_transparent · most_agentic · developer (public MCP/API only). | |
| limit | No | How many providers to return in a ranked view. Default 5, max 19. Ignored when 'providers' is given. | |
| providers | No | Specific providers to compare, by name or slug (e.g. ['corpus','legalzoom']). Omit for a ranked field. Anything with no dossier is named back to you rather than dropped. |
| Name | Required | Description |
|---|---|---|
| text | Yes | Human-readable tool result (also mirrored in content[].text). |
| isError | No | True when the tool could not complete successfully. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal read-only, idempotent, non-destructive behavior. The description adds meaningful context beyond that: the dataset is dated and covers 19 providers verified against primary sources, Corpus is included and scored with the same rubric including its own gaps, and the tool is free. This gives the agent important expectations about fairness and data provenance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but efficient. Every sentence earns its place: what it compares, data provenance, when to call it, the Corpus bias disclosure, and cost. The main action and scope are front-loaded in the first sentence.
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 comparison tool with a rich input schema and an output schema, the description covers what the tool does, its data source, its limitations, and its cost. An agent has enough information to select and invoke it correctly without additional guesswork.
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 three parameters well. The description does not add new parameter-level detail, but it does provide useful surrounding context such as the provider count and Corpus's inclusion. This matches the baseline of 3 for high schema coverage.
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 resource: comparing LLC formation providers on price, recurring costs, registered-agent renewals, and machine/agent capabilities. It is clearly distinct from siblings like formation.requirements, formation.lookup_naics, and formation.handoff, which serve different functions.
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 trigger scenarios: choosing a formation service, evaluating whether a price is a good deal, comparing Corpus to a competitor, or assessing a 'best LLC services' list. It does not name alternative tools or state when not to use it, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a formation draft and generate the prefilled handoff link on corpuslaw.us. Pass EVERYTHING you have collected (people, address, management, EIN answers, state-specific answers — see formation.requirements for the checklist). The response says exactly what is still missing — keep collecting and call again until COMPLETE, then give the user the link: it opens the formation agent with every detail pre-loaded, so they only review, sign in, and pay. Free; does not consume credits.
| Name | Required | Description | Default |
|---|---|---|---|
| ein | No | Optional EIN (federal tax ID) add-on, when available — formation.requirements says whether it can currently be sold and at what price. Never quote a remembered EIN price; use the one that call returns. Set wanted=true/false once the user decides. NEVER include a Social Security Number anywhere — the founder types it into a secure panel on corpuslaw.us, never in chat. | |
| state | Yes | Two-letter US state code, e.g. 'MS', 'WY', 'DE'. | |
| parties | No | The people. LLC: at least one 'member' and an 'organizer' (same person may hold both roles — pass two entries). Nonprofit: an 'incorporator' and at least 3 'director' entries (plus officers where the state requires them). | |
| naicsCode | No | NAICS industry code, 2–6 digits (use formation.lookup_naics to find it). | |
| nonprofit | No | Nonprofit-only fields. | |
| entityType | Yes | Entity type to form. | |
| management | No | LLC management type. | |
| contactEmail | No | Founder contact email. | |
| proposedName | No | Proposed company name. | |
| referral_code | No | Your referral code from account.status, if you have one. The founder saves 25% of the Corpus service fee and the order is credited to your code. Omit it if you do not have one — an absent or unrecognised code changes nothing about the link. | |
| principalOffice | No | Principal office address (street, city, state required for a complete draft). | |
| stateSpecificAnswers | No | Per-state quirk answers under the EXACT keys shown by formation.requirements (e.g. "would_you_like_to_list_members_managers_on_the_state_record"). Values are strings or booleans. |
| Name | Required | Description |
|---|---|---|
| text | Yes | Human-readable tool result (also mirrored in content[].text). |
| isError | No | True when the tool could not complete successfully. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, openWorld, idempotent, and non-destructive behavior. The description adds valuable behavioral detail beyond annotations: the response reports missing items, the generated link preloads details for review/sign-in/payment, and the call is 'Free; does not consume credits.' No contradiction 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?
Three sentences carry the full operational loop: validate, iterate on missing items, hand off the link. Every sentence earns its place, and the primary action is front-loaded before supporting details.
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 complex 12-parameter tool with nested objects and an output schema, the description is complete: it defines validation, iteration, completion criteria, link behavior, and cost implications. It also references the checklist source, leaving no critical operational gap for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful parameter-level guidance by instructing the agent to pass 'EVERYTHING' collected and to consult formation.requirements for the checklist, emphasizing the completeness-driven usage pattern. It does not redefine individual parameters, but it reinforces the aggregate semantics of the payload.
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 action and resource: 'Validate a formation draft and generate the prefilled handoff link on corpuslaw.us.' It clearly distinguishes this tool from siblings like formation.requirements and law.search by focusing on validation and handoff rather than lookup or legal content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: pass everything collected, call repeatedly until COMPLETE, then give the user the link. It explicitly points to formation.requirements for the checklist, but does not explicitly state when not to use this tool versus each sibling; the guidance is clear enough for practical selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find candidate NAICS industry codes for a plain-English business description (needed for every LLC, and for nonprofits in AK, CT, LA, MS, TN, WV). Present 2–6 options to the user and confirm before recording one. Free; does not consume credits.
| Name | Required | Description | Default |
|---|---|---|---|
| businessDescription | Yes | What the business does, in plain words. |
| Name | Required | Description |
|---|---|---|
| text | Yes | Human-readable tool result (also mirrored in content[].text). |
| isError | No | True when the tool could not complete successfully. |
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.
Get the EXACT intake checklist to form an LLC or nonprofit in a state: every required field, that state's quirk questions, live all-in pricing, and the optional EIN add-on with its price when available. Call this FIRST when the user wants to form a company, then collect the answers from them in conversation yourself — you are the intake agent. Free; does not consume credits.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | Two-letter US state code, e.g. 'MS', 'WY', 'DE'. | |
| entityType | Yes | Entity type to form. |
| Name | Required | Description |
|---|---|---|
| text | Yes | Human-readable tool result (also mirrored in content[].text). |
| isError | No | True when the tool could not complete successfully. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent, so no safety contradiction. The description adds useful context beyond annotations: the result is the precise checklist, includes live pricing and optional EIN add-on pricing when available, and is flagged as free/does not consume credits, which helps the agent understand resource impact.
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 well-structured sentences lead with the core purpose, then the usage directive. Every clause adds information, and there is no vague or repeated phrasing to cut.
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 low parameter complexity, existing output schema, and annotations, the description covers what the tool returns, when to invoke it, and the follow-up action. An agent has enough to select and call it correctly without additional investigation.
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%: both required parameters (, state, entityType) are already described. The description reinforces that state is a US state and entityType is LLC or nonprofit, but adds no parameter-level syntax or format detail beyond the schema, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: getting the exact intake checklist for forming an LLC or nonprofit in a state. It enumerates concrete contents (required fields, quirk questions, live pricing, optional EIN add-on) so an agent can distinguish this from sibing tools like law.search or formation.lookup_naics.
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?
"Call this FIRST when the user wants to form a company, then collect the answers from them in conversation yourself" gives explicit when-to-use and a clear next-step workflow. It does not name or exclude the sibling alternatives such as formation.handoff, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the full text, citation, and hierarchy of a single legal provision by its node id (a UUID returned by law.search).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Node UUID, as returned in law.search results. |
| Name | Required | Description |
|---|---|---|
| text | Yes | Human-readable tool result (also mirrored in content[].text). |
| isError | No | True when the tool could not complete successfully. |
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.
List which jurisdictions are ingested (federal, state, and municipal), with per-jurisdiction provision counts, searchable-chunk counts, GIS status, and a placeholder flag. Call this to see what law is available and searchable before searching.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| text | Yes | Human-readable tool result (also mirrored in content[].text). |
| isError | No | True when the tool could not complete successfully. |
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.
Search US federal, state, and municipal law by topic or keyword — use it for any question about what the law currently says (legality, permits, zoning, licensing, compliance, filing requirements) rather than relying on training data, which has a cutoff. Returns ranked provisions with verbatim citations, headings, and snippets. Call this first to discover relevant law, then law.get_node for the full official text. Pass jurisdiction to scope to one state/federal/city (see law.list_coverage for codes).
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Retrieval mode. 'hybrid' (default) fuses vector similarity with keyword search. | hybrid |
| limit | No | Number of results to return (1–25). | |
| query | Yes | Natural-language or keyword query, e.g. 'distillery permit requirements'. | |
| jurisdiction | No | Optional short code to scope the search, e.g. 'TX', 'US', or 'CA-SF'. Call law.list_coverage for valid codes. Includes the jurisdiction's sub-jurisdictions. |
| Name | Required | Description |
|---|---|---|
| text | Yes | Human-readable tool result (also mirrored in content[].text). |
| isError | No | True when the tool could not complete successfully. |
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
formation.compareformation.handoff1 field changedInput schema / properties / ein / descriptionPrevious value: -"Optional $75 EIN (federal tax ID) add-on, when available — formation.requirements says whether it can currently be sold. Set wanted=true/false once the user decides. NEVER include a Social Security Number anywhere — the founder types it into a secure panel on corpuslaw.us, never in chat."New value: +"Optional EIN (federal tax ID) add-on, when available — formation.requirements says whether it can currently be sold and at what price. Never quote a remembered EIN price; use the one that call returns. Set wanted=true/false once the user decides. NEVER include a Social Security Number anywhere — the founder types it into a secure panel on corpuslaw.us, never in chat."account.status1 field changedInput schema / properties / referral_codeAdded value: +{
+ "description": "An active referral code returned by an earlier account.status call. Pass it back to keep the same referral identity; if it is no longer active, account.status issues a new code instead.",
+ "type": "string"
+}account.statusformation.handoffformation.lookup_naicsformation.requirementslaw.get_nodelaw.list_coveragelaw.searchSearch U.S. case law, fetch opinions, and ask matter-aware legal questions over your documents.
Resolve, search and verify legal citations against the official sources, with provenance.
Search US and Indian statutes, regulations, constitutions, and court rules.
US public-records intelligence for AI agents — companies, SEC, courts, spending, licenses.
