Search and cite US law from official sources, then form an LLC or nonprofit with free agent tools.
Scored across 10 tools
Each tool targets a distinct action or resource: formation tools handle requirements, checkout, payment status, etc., while law tools separate search, fetch, and coverage listing. No overlap in responsibilities; even related tools like checkout and payment_status are clearly separated by purpose.
All tools follow a consistent domain.action pattern using snake_case (e.g., formation.checkout, law.search, account.status). The domain prefixes group related functionality, and action verbs are precise and consistent across the set.
10 tools is within the ideal range for this server's dual scope (formation and legal research). Each tool earns its place, covering distinct lifecycle steps without redundancy or unnecessary bloat.
The formation tools cover the full user journey: requirements, NAICS lookup, draft validation, checkout, payment status, provider comparison, and account status. The law tools provide search, retrieval, and coverage discovery. No obvious gaps that would cause agent failures in the indicated use cases.
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.
Create the founder's formation order and get a USDC (Solana) payment request — no API key, no Corpus sign-in. Payment is USDC on Solana ONLY. First call: pass the COMPLETE draft (the same fields formation.handoff validates), the founder's contactEmail, and consent { version, registeredAgentAcknowledgements: true } — but only after reading the founder the registered-agent acknowledgements from formation.requirements word for word and getting an explicit yes. Pass an idempotencyKey and reuse it on retry. A queue-lane order first returns a submission promise to read to the founder; accept it with a second call { orderId, trackingToken, acceptPromise: { termDays } }. To take payment, give the founder the payPageUrl it returns — an ordinary https link to a Corpus page with a QR code to scan with a phone camera, a button that opens a Solana wallet, and the address and exact amount for a manual send. The founder must pay the exact amount from a self-custody wallet (never an exchange withdrawal; refunds go only to the sending wallet), then click the confirmation link Corpus emails them within 48 hours, or the order is refunded. Nothing is filed before that confirmation and human review. The tax-ID add-on cannot be bought here. Free; does not consume credits.
| Name | Required | Description | Default |
|---|---|---|---|
| draft | No | First call: the complete formation draft, the same shape formation.handoff takes. | |
| consent | No | First call: the founder's attestation to the registered-agent acknowledgements, read to them verbatim. `version` is the consentVersion formation.requirements shows. | |
| orderId | No | Second call (or to refresh an expired charge): the orderId returned earlier. | |
| contactEmail | No | First call: the founder's email. The confirmation link is sent here; nothing files until they click it. | |
| acceptPromise | No | Second call, queue lane only: the founder accepted the submission promise with this many days. | |
| trackingToken | No | Second call: the trackingToken returned with the orderId. | |
| idempotencyKey | No | A random id you generate once per order and reuse on every retry; the same order is returned for 24 hours. |
| 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 only provide basic flags (readOnlyHint false, idempotentHint false). The description adds deep behavioral context: payment is USDC on Solana only, the founder must use a self-custody wallet, nothing files until confirmation and human review, refund policy, and the 48-hour confirmation link. It even warns against exchange withdrawals. This far exceeds the annotation coverage without contradiction.
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 lengthy but densely packed with essential operational details for a complex flow. It is front-loaded with the core purpose and then structured sequentially (first call, second call, payment, exclusions). While not terse, every sentence contributes; minor redundancy exists (reiteration of USDC-only) but it's justified for emphasis.
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 complexity (7 params, nested objects, two-call protocol, payment nuances) and that the output schema exists (though not shown), the description covers all necessary context: prerequisites, consent handling, payment mechanics, retry behavior, and restrictions. An agent would have everything needed to execute the correct multi-step flow.
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 schema already covers 100% of parameters with detailed descriptions, so the baseline is 3. The description adds value by explaining lifecycle semantics: which parameters belong to the first call vs second, the meaning of consent.version (from formation.requirements), and the idempotencyKey reuse rule. It doesn't add syntax details but clarifies usage context 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 opens with the exact outcome: 'Create the founder's formation order and get a USDC (Solana) payment request' and differentiates it from siblings (formation.handoff validates, this one creates and takes payment). It also notes exclusions like the tax-ID add-on and the no-sign-in aspect, making the tool's role 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 lays out a precise two-call flow: first call with complete draft+consent+idempotencyKey, second call with orderId/trackingToken/acceptPromise. It states when to use it (after reading acknowledgements), when not to (tax-ID add-on), and how to retry (reuse idempotencyKey). It also gives the external alternative for validation (formation.handoff), leaving no ambiguity.
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). | |
| businessActivity | No | In one plain sentence, what the business actually does, in the founder's words (not the company name). Corpus researches the licenses and permits that apply from this. | |
| 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 cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), and the description confirms consistency by framing this as a validate-and-generate-link step. It adds genuinely new behavioral context: the call is free and consumes no credits, the response reports exactly what is missing, and the returned link opens the formation agent with details pre-loaded for review/sign-in/payment.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the first clause, followed by collection instructions, the iterative loop, and the cost note; every sentence carries operational value. It is dense with parentheticals and reads as a run-on, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 13-parameter, nested, open-world tool with an output schema, the description supplies the workflow (iterate until COMPLETE), the cost model, the checklist dependency (formation.requirements), and the downstream UX of the link. The sensitive-data constraint (never pass an SSN) is handled in the schema, so 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?
Schema description coverage is already 100%, so the baseline is 3. The description adds useful framing beyond the schema by enumerating the categories to pass (people, address, management, EIN answers, state-specific answers) and by tying state-specific keys to formation.requirements rather than leaving the agent to guess key names.
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 two-part verb+resource: validate a formation draft and generate the prefilled handoff link. It situates itself against siblings by pointing to formation.requirements for the checklist, so an agent can tell what this tool does that the others do not.
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 clear usage loop — pass everything collected, read the missing-items response, keep calling until COMPLETE, then hand the link to the user — and routes the agent to formation.requirements for the checklist. There is no explicit 'when not to use' or preconditions (e.g. minimum draft state), so it falls just 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.
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.
Poll the USDC payment for an order created by formation.checkout: awaiting, paid, expired, underpaid or held, plus whether the founder has confirmed by email (required within 48 hours of payment). Reading the chain also records a payment that just arrived. Free; does not consume credits.
| Name | Required | Description | Default |
|---|---|---|---|
| orderId | Yes | The orderId formation.checkout returned. | |
| trackingToken | Yes | The trackingToken formation.checkout returned. |
| 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 give the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), but the description explains the surprising part: that polling 'also records a payment that just arrived,' which reconciles the non-read-only hint with an apparent read operation. It also discloses the 48-hour email confirmation window. It does not cover auth/token requirements, which the schema implies.
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 dense sentences, front-loaded with the action and the state set, followed by the notable side effect and the cost note. No filler and nothing repeated from the schema or annotations.
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 formatting need not be described; the description instead supplies the status vocabulary, the side-effect caveat, and the confirmation deadline. Together with the two required params from formation.checkout, an agent has everything needed to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters are documented as values returned by formation.checkout, so the schema already carries the semantics. The description adds no per-parameter detail (e.g., token lifetime or error behavior on mismatch), leaving this at the baseline when the schema does the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb (poll/check) and resource (USDC payment status for a formation order), enumerates the possible states (awaiting, paid, expired, underpaid, held), and anchors itself to the sibling that creates the order, formation.checkout. An agent can distinguish it from formation.checkout, formation.compare, and account.status without opening any 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?
Clearly scopes usage to orders created by formation.checkout and signals cost ('Free; does not consume credits'), which helps route against credit-consuming siblings. However, it states no explicit when-not condition or named alternative for other payment questions, 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.
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.checkoutformation.payment_statusformation.handoff1 field changedInput schema / properties / businessActivityAdded value: +{
+ "description": "In one plain sentence, what the business actually does, in the founder's words (not the company name). Corpus researches the licenses and permits that apply from this.",
+ "maxLength": 500,
+ "type": "string"
+}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.
Search and read U.S. Code statutes with legal and inline citations linking to uscode.ecfr.io.
Resolve, search and verify legal citations against the official sources, with provenance.
Search US and Indian statutes, regulations, constitutions, and court rules.
Add one secure layer between your agents and this server.
