Make a contract in one call, or negotiate it clause by clause with a published compromise formula.
Scored across 18 tools
Most tools target distinct resources, but there is a real cluster of overlapping template tools (find_template, list_templates, get_template, list_contract_types) whose boundaries will confuse an agent deciding where to look. find_template vs list_templates in particular both search/return templates. Descriptions help but the overlap is notable.
Every tool follows a consistent snake_case verb_noun pattern (buy_credits, create_playbook, delete_deal, download_contract, get_deal, list_templates, initiate_negotiation, etc.). Verb style is uniform and predictable throughout.
18 tools is slightly heavy but the domain (template discovery, negotiation, contract generation, credits, deadlines, playbooks, attorney review) genuinely justifies breadth. A couple of tools, such as the template cluster and the legacy get_subscriptions, feel consolidatable.
The lifecycle is well covered: discovery (find/list), generation (generate_contract), negotiation (initiate/join), retrieval (get_deal/download_contract), deletion (delete_deal), plus credits, obligations, playbooks and attorney review. There is no list_deals operation to enumerate one's deals, and no direct update, though negotiation partially covers modification.
Open a hosted checkout for a pack of ten contract credits for this API key's customer (any of its keys can spend them). Returns checkoutUrl for a person to open in a browser; the credits arrive when the payment succeeds. Answers 409 where payments are off.
| Name | Required | Description | Default |
|---|---|---|---|
| currency | No | usd | |
| returnUrl | No | URL to return to after checkout |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only readOnlyHint=false and openWorldHint=false in annotations, the description carries real behavioral detail: the operation returns a checkoutUrl rather than completing payment, credits are asynchronous (arrive on payment success), any key of the customer can spend them, and a 409 is returned where payments are disabled. That is exactly the kind of failure-mode and lifecycle disclosure annotations cannot express.
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 tight sentences, each earning its place: what it does, what it returns and when credits land, and the failure case. The checkout/return information is front-loaded rather than buried.
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?
No output schema exists, yet the description names the key return value (checkoutUrl) and the async fulfillment model, plus the 409 condition, which is enough for an agent to call this correctly. Minor gaps remain around currency handling and what the customer sees on return.
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 only 50% (returnUrl is documented, currency is not) and the description says nothing about either parameter – no mention of currency choice or how returnUrl interacts with the hosted checkout flow. It fails to compensate for the coverage gap.
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 ('Open a hosted checkout') and resource ('a pack of ten contract credits'), including the scope of whose credits they are. It is clearly distinguishable from siblings like get_credit_balance, which only reads a balance.
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 clear context for when this applies: a human opens the checkoutUrl in a browser and credits arrive only when payment succeeds. It does not explicitly name alternatives such as get_credit_balance or state when not to call it, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a negotiation playbook defining preferences for each clause: preferred option, priority (1-5), flexibility (1-5), red lines, and acceptable alternatives.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Unique playbook name | |
| entries | Yes | ||
| contractType | Yes | Contract type code: one from list_contract_types, or an A2A_ agent-to-agent protocol type from list_templates (those are negotiated only, never made with generate_contract) | |
| governingLaw | Yes | ||
| contractLanguage | No | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=false and openWorldHint=false, so the description carries the behavioral burden. It never says whether the playbook persists, whether it can be edited later, whether the name must be unique at creation time, or what happens on validation failure for red lines or duplicate clauseIds.
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 dense sentence that front-loads the action and lists the meaningful clause-level fields with their ranges. No filler, though the enumeration is a bit list-like rather than prioritizing what matters most.
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 mutation tool with no output schema and only weak annotations, the description omits when to use it, whether playbooks are reusable or editable, and how the required top-level parameters interact with the entries array. An agent can form the call but lacks context to use 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 only 40%, but the description usefully expands the nested 'entries' semantics (preferred option, priority 1-5, flexibility 1-5, red lines, acceptable alternatives) beyond the bare schema. It says nothing about name, contractType, governingLaw, or contractLanguage, so it only partially compensates for the coverage gap.
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 ('Create a negotiation playbook') and enumerates the per-clause content it captures. However, it never distinguishes this tool from negotiation-oriented siblings like initiate_negotiation or explain_options, so an agent gets no routing help.
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?
There is no statement of when to create a playbook versus alternatives, no prerequisites, and no exclusions. The agent must infer usage entirely from the verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete one of your single-party deals and its data: the parties, the other side's details, the clause choices, the inputs and the contract (documents are made on request and never stored). This cannot be undone. Only the account that made the deal can delete it; for any other account it does not exist (HTTP 404, also when it was already deleted). A deal another party takes part in, such as a two-party negotiation, is refused with HTTP 409 and nothing is deleted. The payment record is kept for billing (amount, date, account and deal id, no names or contract text), and a spent credit is not given back.
| Name | Required | Description | Default |
|---|---|---|---|
| dealId | Yes | Agent deal id (dealId from generate_contract) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true, but the description goes well beyond them: it states irreversibility, the exact data cascade, ownership-based authorization, the 404/409 failure semantics, and the billing side effects (payment record retained, spent credit not refunded). That is precisely the extra context an agent needs before an irreversible call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the action and its destructive scope, then layered constraints in escalating order (authorization, refusal, side effects). Every clause carries a distinct operational fact; nothing is redundant across the four sentences.
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 destructive, irreversible tool with no output schema, the description covers everything an agent needs: what is destroyed, what survives (payment record, non-refunded credit), who may call it, and how failures manifest via HTTP codes. Nothing material is left to inference.
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?
There is a single parameter and schema description coverage is 100%, with the schema already explaining that dealId comes from generate_contract. The description adds no format, source, or constraint detail for dealId beyond what the schema provides, so the baseline 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?
States a specific verb and resource (delete a single-party deal) and immediately enumerates the scope of what is removed (parties, other side's details, clause choices, inputs, contract). The single-party scoping distinguishes it from any deal operation that involves other parties, and no sibling tool performs deletion.
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 clear conditions for when the call succeeds versus fails: only the creating account may delete, others get 404 (also when already deleted), and deals involving another party are refused with 409. No alternative sibling is named because none exists for deletion, so explicit when-not guidance without an alternative is the right level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download the agreed contract as Markdown, HTML, PDF, DOCX or TXT (Markdown by default: agents read it best). Negotiation is free; the contract is paid when its document is first fetched: one prepaid credit of the customer is spent (any of its keys draws on the one balance). Later fetches of the same deal are free. With no credit left the answer is HTTP 402 with code PAYMENT_REQUIRED and the link to buy credits.
| Name | Required | Description | Default |
|---|---|---|---|
| dealId | Yes | Agent deal room ID | |
| format | No | md (Markdown) or html for agents and tools; pdf, docx or txt for people and printers | md |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations covering only readOnlyHint/openWorldHint, the description carries real weight: it discloses the credit-spend model, that any key draws on one balance, that repeat fetches are free, and the exact failure contract (HTTP 402, code PAYMENT_REQUIRED, link to buy credits). That is far more than the annotations provide and is exactly what an agent needs before triggering a paid action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the action and formats, then the billing and error semantics. Dense but every clause carries information; the parenthetical aside about agents reading Markdown is mildly redundant with the schema but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no output schema, the description covers the return artifact (the document in the chosen format) and the payment/error outcomes. It does not say what happens if the deal is not yet agreed or the dealId is invalid, a minor gap given the paid-fetch path is well documented.
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 both parameters are already documented, including the format enum and md default. The description adds only a soft recommendation ('Markdown by default: agents read it best') that largely restates the schema's own 'md or html for agents' note, so the baseline 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?
The description opens with a specific verb and resource ('Download the agreed contract') plus the exact output formats, which cleanly separates it from sibling generate_contract (which produces the contract in the first place). An agent can tell what it gets and in what forms without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear situational context: the contract must already be 'agreed', negotiation is free, and the fetch is the point of payment, with later fetches free. It does not explicitly name alternatives (e.g. generate_contract or get_deal) or state the precondition as a when-not rule, so it stops short of a full routing instruction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The options of one clause, each with its description and its pros and cons for each party, plus the clause's trade-off text, exactly as the template holds them. Nothing is ranked or recommended; when the template has no such text, the answer says so. Free (no credit).
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | en | |
| clause | Yes | Clause id (from get_template) or the clause title | |
| contractType | Yes | Contract type code: one from list_contract_types, or an A2A_ agent-to-agent protocol type from list_templates (those are negotiated only, never made with generate_contract) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real value beyond that: it discloses that nothing is ranked or recommended, defines the empty-template behavior ('the answer says so'), and states cost ('Free (no credit)') — a meaningful detail given credit-related siblings. It stops short of describing pagination or size limits.
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 compact sentences, front-loaded with the return content before the behavioral caveats and the cost note. No filler, though the phrasing around 'pros and cons for each party' is slightly dense.
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?
There is no output schema, so the description carries the return-value burden and does so well: it enumerates what comes back and handles the empty case. Annotations cover safety. The only shortfall is the absent parameter coverage, particularly the lang option.
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 67%, and the description contributes nothing about any of the three parameters — no mention of lang, clause, or contractType. The undocumented lang enum/default is left entirely to the schema, and the description does not compensate for that gap. Below the 3 baseline because it adds zero parameter meaning.
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 resource and its scope: the options of a single clause, each with description, per-party pros/cons, and the clause's trade-off text, drawn 'exactly as the template holds them.' That is clearly distinguishable from get_template/find_template, though it never names those siblings, so sibling differentiation is only implicit.
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?
Usage is implied (call this to learn a clause's options and trade-offs) but there is no explicit when-to-use, no condition selecting it over get_template, and no prerequisites. The behavioral caveats are not usage guidance. Adequate but with a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describe the matter in your own words; Dealroom answers with the contract types whose names or usual terms appear in the description (code, title, guide link), or "No template covers this. Such matters are usually handled by a lawyer." The matching is by words, with no AI model. A lawsuit or claim received, a subpoena, a data breach or a letter from a regulator is flagged as a time-sensitive matter outside the templates (outsideTemplates). It does not say what the user needs and names no lawyer. Free; no API key needed.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of titles, links and the message | en |
| query | Yes | The matter in plain words, in English or Spanish |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint and openWorldHint; the description adds substantive behavior beyond that — matching is keyword-based with no AI model, the call is free with no API key, time-sensitive matters (lawsuits, subpoenas, data breaches, regulator letters) are flagged via outsideTemplates, and the return fields are named. This is real added context.
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 rambling and awkwardly structured, quoting the tool's own output messages verbatim ('code, title, guide link', 'No template covers this...') rather than front-loading the essential purpose. Sentences like 'It does not say what the user needs and names no lawyer' are confusing and read as describing a response payload rather than 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?
There is no output schema, so the description usefully names what comes back (contract types with code, title, guide link) and describes the no-match fallback and the time-sensitive flagging. It is fairly complete for a read-only lookup tool, though the tangled prose slightly reduces clarity.
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 both 'query' and 'lang'. The description reinforces that the query is a free-text matter in English or Spanish, but adds little syntax or constraint detail beyond the schema; baseline 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?
The description does convey the core verb+resource: it matches a plain-language description of a matter against contract types by keyword. It is distinguishable from siblings like list_templates and get_template. However, the phrasing is roundabout, and sentences such as 'It does not say what the user needs and names no lawyer' have an ambiguous subject that muddies the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage ('Describe the matter in your own words') and reveals that a fallback path exists when nothing matches. But it never explicitly says when to choose this over list_templates, list_contract_types, or get_template, leaving the agent to infer the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make a finished contract in one call: give the contract type, your side's details and, if you know them, the other side's. Clauses you leave out take the template's middle-ground option (the most neutral one; for an optional clause such as non-solicitation, none), never simply the first option listed. One prepaid credit is spent (the same price as any contract); with no credit the answer is HTTP 402 with code PAYMENT_REQUIRED and nothing is created. Returns the contract as Markdown, then the deal id, the link where the person can read it in Dealroom and the Markdown, HTML, PDF, DOCX and TXT links (free to fetch again).
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | DPA and BAA only: the role you take (see roles in list_contract_types) | |
| party | Yes | Your side (the side the API key acts for). Send every detail you have: only what you send is written into the contract. | |
| terms | No | Inputs by id (see inputs in list_contract_types). Send every required input in terms. A required input with a default can be left out: the default is applied. | |
| title | No | Name of the deal; made from the parties when left out | |
| inline | No | The contract itself in the answer: md (Markdown, the default here), html or txt | md |
| clauses | No | Optional clause choices: clause id to option code (see get_template) | |
| language | No | en | |
| contractType | Yes | Code (for example NDA) or guide slug (for example nda), from list_contract_types | |
| counterparty | No | The other side, with its address and jurisdiction of incorporation when you know them. Left out: its block stays blank for it to complete. | |
| governingLaw | No | Required when the contract type offers more than one | |
| idempotencyKey | No | Send the same value when retrying, so a retry never makes or charges a second contract |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations only declaring readOnlyHint=false and openWorldHint=false, the description carries the interesting behavioral load and does so well: it discloses that one prepaid credit is spent, that a missing credit yields HTTP 402 PAYMENT_REQUIRED with nothing created, that omitted clauses take the template's neutral option (not the first listed), and that re-fetching the other formats is free. That is exactly the side-effect, cost, and failure information an agent needs before invoking a mutating tool.
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?
It is one dense paragraph, but it is front-loaded with the core action before cost and return details, and every sentence carries an operative fact (fallback semantics, credit cost, 402 behavior, return payload). The parenthetical clauses make it slightly heavier to parse than ideal, but there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 11-parameter tool with nested party objects and no output schema, the description covers the essentials: what to supply, how omissions are resolved, what it costs, what happens on insufficient credit, and precisely what is returned (Markdown, deal id, read link, format links). The remaining gaps (role, governingLaw, idempotencyKey) are documented in the schema at 91% coverage.
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 91%, so the baseline is 3, but the description adds genuine semantics on top: the rule that omitted clauses resolve to the most neutral template option (never the first option listed), the optional nature of the counterparty block, and the distinction between what the caller sends versus what is written into the contract. It does not add anything about language, governingLaw, or role selection beyond what the schema already says.
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?
It names a specific verb and resource ("make a finished contract in one call") and the required inputs, so the agent immediately knows this is a generation action rather than a lookup. It distinguishes itself from the template-discovery siblings implicitly through "in one call" and "finished", but never names an alternative tool, which keeps it short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear conditions for supplying data (contract type, your side's details, other side only "if you know them") and explains the clause fallback rule, which is real usage guidance. It lacks explicit when-not/exclusion guidance and does not route the agent to buy_credits when a 402 is returned, so it is strong but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remaining contract credits of this API key's customer (one balance shared by all of its keys) and the latest ledger entries.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real value by clarifying that the balance is customer-scoped and shared across all of the customer's keys, and that ledger entries are bundled into the response.
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 sentence with the scoping caveat in parentheses, front-loading the primary return value and appending the secondary one. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description reasonably covers what comes back (balance plus latest ledger entries). It is complete enough for a no-argument read tool, though it does not say how many ledger entries 'latest' means or in what unit credits are expressed.
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 takes zero parameters, so there is nothing for the description to compensate for. Baseline 4 applies; schema coverage is 100% and no parameter meaning is needed.
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 the specific resource (remaining contract credits) and the scope (this API key's customer, shared across keys) plus secondary content (latest ledger entries). An agent can distinguish it from the write-oriented sibling buy_credits, though the differencing is implicit rather than stated.
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?
No when-to-use guidance, no mention of alternatives such as buy_credits, and no prerequisites. The read intent is only inferable from the wording 'remaining' and the annotations, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A small public calendar of statutory dates: the Section 83(b) election (30 days after the stock is transferred), the SEC Form D notice (15 calendar days after the first sale) and the Delaware annual report and franchise tax (1 March). Give grantDate or firstSaleDate to count the due date. Each item carries its official source and is marked "Verify with the official source." General public dates, not advice. Free; no API key needed.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | en | |
| year | No | Year of the Delaware due date; left out, the next 1 March | |
| grantDate | No | Date the stock was transferred or granted (YYYY-MM-DD), for the 83(b) election | |
| firstSaleDate | No | Date of the first sale of securities (YYYY-MM-DD), for Form D |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description adds real context beyond them: no API key, no cost, public non-advisory nature, and that every item carries its official source and a 'Verify with the official source' marker. That is meaningful disclosure about result trustworthiness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense paragraph, front-loaded with the resource and contents, then inputs, then caveats. Every clause carries information, though the source/verify/disclaimer tail is slightly repetitive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does the work of describing returns (items with source and verify marker). Inputs, deliverable, and limits are covered for a simple read-only lookup; minor gap is no explicit statement of what happens when no date is supplied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 75% schema coverage the baseline would be 3, but the description adds the causal link between inputs and output ('give grantDate or firstSaleDate to count the due date') and clarifies which parameter maps to which deadline. It goes beyond restating 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?
States a concrete verb+resource ('A small public calendar of statutory dates') and enumerates the three exact items returned (83(b), Form D, Delaware franchise tax), which no sibling covers. It's clear and specific, though the framing is more content-list than action statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It tells the agent what to supply ('Give grantDate or firstSaleDate to count the due date') but never states when to reach for this tool versus other lookups or what it is not for, beyond the generic 'not advice' disclaimer. Usage is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get deal details including per-clause agreed options, satisfaction scores, and reasoning.
| Name | Required | Description | Default |
|---|---|---|---|
| dealId | Yes | Agent deal room ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the agent knows this is a safe, closed-world read. The description adds that it returns per-clause agreed options, satisfaction scores, and reasoning, but doesn't disclose pagination, response limits, or error behavior. With annotations covering the safety profile, this is adequate but not rich.
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, tightly focused sentence that front-loads the verb and resource, then enumerates the key return values without any filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one fully documented parameter and annotations covering safety, the description is almost complete. It could benefit from mentioning usage context or return format, but nothing critical is missing given the tool's simplicity and the absence of an output schema.
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% (the only parameter dealId is fully described). The description adds no parameter detail, but with complete schema coverage the baseline is 3; the description's listing of returned data indirectly confirms the parameter's role, nudging it to 4.
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 clear verb (get) and resource (deal), specifying the returned content: per-clause agreed options, satisfaction scores, and reasoning. This distinguishes it from siblings like download_contract or get_template, though no sibling is explicitly named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by outlining the returned data, but offers no explicit guidance on when to use this tool versus alternatives (e.g., download_contract). Usage is contextually implied but not specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List earlier per-skill subscriptions and their status. Skills are no longer sold one by one; every template is included.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely useful context that these subscriptions are legacy and no longer sold individually, but says nothing about return format, volume of historical records, or pagination.
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 short sentences, zero waste, with the primary action front-loaded and the legacy explanation following. Nothing is repeated from the title 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?
For a zero-parameter, read-only list tool with annotations covering the safety profile, the description is nearly sufficient. It could say slightly more about what a returned subscription record looks like, but no output schema is needed for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the schema-side burden is nil and the baseline is 4. The description correctly implies the call is unfiltered, returning all earlier subscriptions.
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 gives a specific verb and resource ('List earlier per-skill subscriptions and their status') and the second sentence clarifies these are legacy items, which separates it from siblings like list_templates and get_template. It does not explicitly name an alternative tool, but the resource is distinct enough for an agent to route correctly.
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?
Usage is only implied: the note that 'Skills are no longer sold one by one' signals this is a historical/legacy lookup rather than something used in normal purchase flows. There is no explicit when-to-use statement, no exclusion, and no named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details for a specific contract template including all clauses and their options with bias values.
| Name | Required | Description | Default |
|---|---|---|---|
| contractType | Yes | Contract type code: one from list_contract_types, or an A2A_ agent-to-agent protocol type from list_templates (those are negotiated only, never made with generate_contract) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that the payload includes clauses, options, and bias values, which is useful, but it says nothing about auth needs, rate limits, or behavior for unknown contract types.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence that names the resource and the return payload with zero filler 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?
For a read-only single-parameter lookup with no output schema, the description covers purpose and return contents adequately; only the routing relationship with list_templates/list_contract_types is left implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter is thoroughly documented in the schema, including the A2A negotiated-only caveat. The description adds no parameter-level detail beyond what the schema already provides, so the baseline 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?
States a specific verb (get) and resource (contract template) and enumerates the returned content (clauses and their options with bias values), so an agent knows exactly what it fetches. It does not explicitly distinguish itself from list_templates or list_contract_types, which is the only thing keeping it from a 5.
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?
Usage is only implied: the schema notes contractType must come from list_contract_types or list_templates, hinting this is a follow-up call, but the description itself gives no when-to-use, when-not-to-use, or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a new contract negotiation. Returns a negotiation token for the respondent to join.
| Name | Required | Description | Default |
|---|---|---|---|
| dealName | Yes | Human-readable deal name | |
| playbookId | Yes | ID of your playbook | |
| initiatorEmail | Yes | ||
| respondentEmail | No | ||
| initiatorCompany | No | ||
| respondentCompany | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and openWorldHint=false, so the agent already knows this is a closed-world write. The description usefully adds that a negotiation token is returned for the respondent to join. It says nothing about permissions, whether emails are dispatched to initiator/respondent, or reversibility.
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 short sentences with zero waste; the core action is front-loaded and the return value follows immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should carry return-value detail — it only partially does via the negotiation token mention. It never clarifies the three optional parameters or what respondentEmail does at initiation time, leaving an agent under-informed for a 6-parameter creation tool.
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 only 33% — dealName and playbookId are documented, while initiatorEmail, respondentEmail, initiatorCompany and respondentCompany have no descriptions. The description adds no parameter meaning at all, so it fails to compensate for the coverage gap on a 6-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Start a new contract negotiation') and hints at its counterpart role by mentioning the respondent joining. It does not explicitly name the sibling join_negotiation, but the purpose is unambiguous.
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?
Usage is only implied: the tool begins a negotiation and hands a token to the respondent, which contrasts with join_negotiation. There is no explicit when-to-use guidance, no statement of prerequisites (e.g., needing an existing playbook), and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Join an existing negotiation as the respondent. Triggers automatic compromise resolution and returns the result.
| Name | Required | Description | Default |
|---|---|---|---|
| playbookId | Yes | ID of your playbook (must match contract type) | |
| respondentEmail | Yes | ||
| negotiationToken | Yes | Token from the initiator | |
| respondentCompany | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and openWorldHint=false, so the agent already knows this mutates local state. The description adds genuinely new behavior: joining 'triggers automatic compromise resolution and returns the result' — an important side effect beyond a plain write. It stops short of explaining what resolution means or what permissions/state are required, so not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with the action and role, then the behavioral consequence. No filler 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?
For a mutating tool with no output schema, the description covers purpose and the resolution side effect, which is a reasonable minimum. However, it leaves the two undocumented parameters and the meaning/outcome of 'compromise resolution' unexplained, so an agent cannot fully anticipate the call's requirements or results.
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 only 50%: respondentEmail and respondentCompany have no schema descriptions, and the description supplies no parameter guidance at all. With half the parameters undocumented and a mutation tool that depends on a matching playbook, the description fails to compensate for the coverage gap.
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 and resource ('Join an existing negotiation') and disambiguates the role with 'as the respondent', which separates it from initiate_negotiation among the siblings. It doesn't explicitly name the sibling it complements, but the actor-role framing is enough for an agent to tell them apart.
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?
'Join an existing negotiation' implies the usage context (a negotiation already exists and you are the counterparty), but there is no explicit when-to-use, when-not-to-use, or pointer to an alternative tool. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every contract type Dealroom can make, with the code to use as contractType, the guide slug, the governing laws and languages it is offered in, the role the caller can take (DPA and BAA only) and the inputs it asks for. Each input says whether it is required and, when it has one, its default; mustSend marks the required inputs without a default. Send every required input in terms. A required input with a default can be left out: the default is applied. Call this first to know what to ask the user. Send contractType to get one type with its inputs, or summary true to get every type without its inputs (a short list of codes). No API key needed.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of names and labels | en |
| summary | No | Optional: leave the inputs out of each type (each then carries inputCount) | |
| contractType | No | Optional: one code (for example DPA) or guide slug; only that type is returned, with its inputs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true and openWorldHint=false already declaring the safety profile, the description adds useful non-obvious behavior: mustSend marks required inputs lacking a default, defaults are applied when a required input is omitted, and no API key is needed. It goes beyond the annotations without contradicting them.
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?
It is one dense paragraph but well front-loaded: what is listed first, then the mustSend/default rules, then the two query modes. Slightly run-on with some compression, but nearly every clause carries operational information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description has to explain return shape, and it does: the fields per type, the mustSend marker, and the inputCount variant for summary mode. Combined with the auth note, it is sufficient for correct invocation, with only minor gaps around exact response 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?
Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: the contractType parameter accepts a code or guide slug and returns that type with inputs, and summary=true yields a short code list where each type carries inputCount. That is more than the schema alone conveys.
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 (list) and resource (contract types) and enumerates exactly what each entry carries: code, guide slug, governing laws, languages, caller role, and inputs. It clearly reads as the discovery/reference tool rather than a generation or download tool, though it never names a sibling explicitly, so it stops short of a 5.
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?
Strong guidance: "Call this first to know what to ask the user" sets the situation, and it explains how to switch modes between contractType (one type with inputs) and summary true (all types without inputs). It gives clear context but no explicit exclusions against alternatives such as get_template or find_template.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What a contract commits its parties to and the dates it states: the obligations ledger (recurring and event-driven duties, for the DPA today) and, for every contract type, the date inputs, the term, notice and renewal inputs and the agreed option of each term, renewal, termination, notice or duration clause. Facts as the contract states them; the contract text governs. Free (no credit).
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | en | |
| dealId | Yes | Agent deal id (dealId from generate_contract) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real context beyond that: it states the data is 'Facts as the contract states them; the contract text governs' (a fidelity caveat) and 'Free (no credit)' (cost behavior not present in 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?
Purpose is front-loaded in the first clause, but the middle sentence is a long, comma-heavy enumeration ('the date inputs, the term, notice and renewal inputs and the agreed option of each term, renewal, termination, notice or duration clause') that is hard to parse and partly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does the work of explaining what is returned: the obligations ledger and the date/term/notice/renewal inputs per clause. It omits any note on result shape, ordering, or volume, but for a read-only per-deal listing it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%; dealId is well documented in the schema ('dealId from generate_contract') and lang is a self-explanatory en/es enum, so structured fields carry most of the weight. The description adds no parameter meaning, 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?
States a specific resource and content: 'What a contract commits its parties to and the dates it states', then enumerates the obligations ledger plus term/notice/renewal inputs. Clear verb-implied retrieve/list of a concrete resource, but it never distinguishes itself from the nearby get_deadlines sibling, so sibling differentiation is missing.
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?
There is no explicit when-to-use or when-not-to-use guidance and no alternative tool is named, even though get_deadlines and get_deal overlap. The only context clues are a scope aside ('for the DPA today') and 'Free (no credit)', which conveys cost rather than usage routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available contract templates with clauses, options, and bias values. Use this to understand which contract types are available and what options exist for each clause. Pass query to search by code, abbreviation or name in English or Spanish ("nda", "dpa", "hipaa", "confidencialidad"), best match first.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Optional search: contract code, abbreviation or name (English or Spanish) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds useful behavior beyond that: the result set includes clauses/options/bias values and is returned 'best match first' when a query is passed, and it works across English and Spanish input.
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 short sentences, front-loaded with purpose, then usage, then parameter guidance. The query sentence partly restates the schema, but the added examples and ordering note justify its presence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless-by-default read-only list tool with no output schema, the description covers what is returned, how search behaves, and language support. Only the relationship to list_contract_types is left unresolved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description earns credit above baseline by supplying concrete query examples ('nda', 'dpa', 'hipaa', 'confidencialidad') and clarifying the match-order semantics ('best match first') that the schema does not state.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb and resource ('List available contract templates') plus the payload contents (clauses, options, bias values), so an agent knows what comes back. It does not, however, differentiate itself from the sibling list_contract_types, which it partly overlaps with by claiming to reveal 'which contract types are available.'
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 positive use case ('Use this to understand which contract types are available and what options exist for each clause') but names no alternatives or exclusions. With a sibling named list_contract_types covering a similar-sounding surface, the absence of routing guidance leaves ambiguity.
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.
generate_contract18 fields changedInput schema / properties / counterparty / descriptionPrevious value: -"The other side. Left out: its block stays blank for it to complete."New value: +"The other side, with its address and jurisdiction of incorporation when you know them. Left out: its block stays blank for it to complete."Input schema / properties / counterparty / properties / address / descriptionPrevious value: -"Registered or postal address"New value: +"Registered office or principal place of business, for example \"Calle Mayor 1, 28013 Madrid, Spain\". Printed in the preamble (\"with its principal place of business at ...\") and the Parties section. Left out: [Address] stays as a blank to fill in."Input schema / properties / counterparty / properties / contactAdded value: +{
+ "description": "Contact person or details for the Contact line of the Parties section (Markdown, HTML and text versions), for example \"Ana García, legal@example.com\". Left out: no Contact line.",
+ "type": "string"
+}Input schema / properties / counterparty / properties / email / descriptionAdded value: +"A contact e-mail for this party. Used for the Contact line when contact is left out. The API key's account e-mail is never written into the contract."Input schema / properties / counterparty / properties / jurisdictionAdded value: +{
+ "description": "Where the party is incorporated or registered, for example \"Spain\" or \"Delaware, United States\". Printed in the Parties section of the Markdown, HTML and text versions.",
+ "type": "string"
+}Input schema / properties / counterparty / properties / legalName / descriptionPrevious value: -"Full legal name of the company or person"New value: +"Full legal name of the company or person. Printed as the party's name in the preamble, the Parties section and the signature block."Input schema / properties / counterparty / properties / signatoryName / descriptionPrevious value: -"Name of the person who signs"New value: +"Name of the person who signs. Printed in the signature block; left out, the Name line stays blank."Input schema / properties / counterparty / properties / signatoryTitle / descriptionPrevious value: -"Title of the person who signs, for example CEO"New value: +"Title of the person who signs, for example CEO. Printed in the signature block; left out, the Title line stays blank."Input schema / properties / counterparty / properties / taxId / descriptionPrevious value: -"Company or tax number, where the contract shows one"New value: +"Company or tax number (for example a Spanish NIF or a US EIN). Printed in the Parties section of the Markdown, HTML and text versions, and in the preamble where the template shows one."Input schema / properties / party / descriptionPrevious value: -"Your side (the side the API key acts for)"New value: +"Your side (the side the API key acts for). Send every detail you have: only what you send is written into the contract."Input schema / properties / party / properties / address / descriptionPrevious value: -"Registered or postal address"New value: +"Registered office or principal place of business, for example \"Calle Mayor 1, 28013 Madrid, Spain\". Printed in the preamble (\"with its principal place of business at ...\") and the Parties section. Left out: [Address] stays as a blank to fill in."Input schema / properties / party / properties / contactAdded value: +{
+ "description": "Contact person or details for the Contact line of the Parties section (Markdown, HTML and text versions), for example \"Ana García, legal@example.com\". Left out: no Contact line.",
+ "type": "string"
+}Input schema / properties / party / properties / email / descriptionAdded value: +"A contact e-mail for this party. Used for the Contact line when contact is left out. The API key's account e-mail is never written into the contract."Input schema / properties / party / properties / jurisdictionAdded value: +{
+ "description": "Where the party is incorporated or registered, for example \"Spain\" or \"Delaware, United States\". Printed in the Parties section of the Markdown, HTML and text versions.",
+ "type": "string"
+}Input schema / properties / party / properties / legalName / descriptionPrevious value: -"Full legal name of the company or person"New value: +"Full legal name of the company or person. Printed as the party's name in the preamble, the Parties section and the signature block."Input schema / properties / party / properties / signatoryName / descriptionPrevious value: -"Name of the person who signs"New value: +"Name of the person who signs. Printed in the signature block; left out, the Name line stays blank."Input schema / properties / party / properties / signatoryTitle / descriptionPrevious value: -"Title of the person who signs, for example CEO"New value: +"Title of the person who signs, for example CEO. Printed in the signature block; left out, the Title line stays blank."Input schema / properties / party / properties / taxId / descriptionPrevious value: -"Company or tax number, where the contract shows one"New value: +"Company or tax number (for example a Spanish NIF or a US EIN). Printed in the Parties section of the Markdown, HTML and text versions, and in the preamble where the template shows one."create_playbook1 field changedInput schema / properties / governingLaw / enumPrevious value: -[
- "CALIFORNIA",
- "ENGLAND_WALES",
- "SPAIN"
-]New value: +[
+ "CALIFORNIA",
+ "ENGLAND_WALES",
+ "SPAIN",
+ "DELAWARE"
+]generate_contract1 field changedInput schema / properties / governingLaw / enumPrevious value: -[
- "CALIFORNIA",
- "ENGLAND_WALES",
- "SPAIN"
-]New value: +[
+ "CALIFORNIA",
+ "ENGLAND_WALES",
+ "SPAIN",
+ "DELAWARE"
+]list_contract_types2 fields changedInput schema / properties / contractTypeAdded value: +{
+ "description": "Optional: one code (for example DPA) or guide slug; only that type is returned, with its inputs",
+ "type": "string"
+}Input schema / properties / summaryAdded value: +{
+ "default": false,
+ "description": "Optional: leave the inputs out of each type (each then carries inputCount)",
+ "type": "boolean"
+}explain_optionsfind_templateget_deadlineslist_obligationsshare_with_attorneycreate_playbook3 fields changedInput schema / properties / contractType / descriptionPrevious value: -"Contract type"New value: +"Contract type code: one from list_contract_types, or an A2A_ agent-to-agent protocol type from list_templates (those are negotiated only, never made with generate_contract)"Input schema / properties / contractType / enumRemoved value: -[
- "A2A_API_ACCESS",
- "ACTA_CONSEJO_ADMINISTRACION",
- "ACTA_JUNTA_GENERAL",
- "ADVERTISING_IO",
- "ADVISORY",
- "AFFILIATE_PROGRAM",
- "A2A_MONITORING",
- "PHANTOM_SHARES_GRANT",
- "RESIDENTIAL_TENANCY_GB",
- "RESIDENTIAL_TENANCY_US_CA",
- "DELAWARE_CERT_OF_INCORPORATION",
- "A2A_COMPUTE_PROCUREMENT",
- "CONSULTING",
- "A2A_CONTENT_LICENSE",
- "RESIDENTIAL_TENANCY_ES",
- "CONVERTIBLE_NOTE",
- "DATA_LICENSING",
- "DPA",
- "A2A_DATA_SHARING",
- "EMPLOYMENT",
- "CONTRATO_LABORAL",
- "EQUITY_INCENTIVE",
- "FOUNDERS",
- "BAA_NEGOTIATOR",
- "CESION_PI",
- "IP_ASSIGNMENT",
- "INFLUENCER_MARKETING",
- "JOINT_VENTURE",
- "A2A_KNOWLEDGE_ACCESS",
- "PHANTOM_SHARES_PLAN",
- "A2A_MARKETPLACE",
- "MSA",
- "NDA",
- "A2A_ORCHESTRATION",
- "A2A_PAYMENT_AUTHORIZATION",
- "PRIVACY_NOTICE",
- "SAFE",
- "SAAS",
- "SEED_INVESTMENT",
- "CONTRATO_SERVICIOS",
- "SHAREHOLDERS",
- "PACTO_SOCIOS",
- "SOFTWARE_DEVELOPMENT",
- "A2A_SUPPLY_CHAIN",
- "A2A_TASK_DELEGATION",
- "TECHNOLOGY_LICENSE",
- "TEMPLATE",
- "TERM_SHEET",
- "A2A_TOOL_LICENSE",
- "WHITE_LABEL_RESELLER"
-]Input schema / properties / governingLaw / enumPrevious value: -[
- "CALIFORNIA",
- "NEW_YORK",
- "ENGLAND_WALES",
- "SPAIN"
-]New value: +[
+ "CALIFORNIA",
+ "ENGLAND_WALES",
+ "SPAIN"
+]generate_contract2 fields changedInput schema / properties / governingLaw / enumPrevious value: -[
- "CALIFORNIA",
- "NEW_YORK",
- "ENGLAND_WALES",
- "SPAIN"
-]New value: +[
+ "CALIFORNIA",
+ "ENGLAND_WALES",
+ "SPAIN"
+]Input schema / properties / terms / descriptionPrevious value: -"Inputs by id (see inputs in list_contract_types); required ones must be given"New value: +"Inputs by id (see inputs in list_contract_types). Send every required input in terms. A required input with a default can be left out: the default is applied."get_template2 fields changedInput schema / properties / contractType / descriptionPrevious value: -"Contract type identifier"New value: +"Contract type code: one from list_contract_types, or an A2A_ agent-to-agent protocol type from list_templates (those are negotiated only, never made with generate_contract)"Input schema / properties / contractType / enumRemoved value: -[
- "A2A_API_ACCESS",
- "ACTA_CONSEJO_ADMINISTRACION",
- "ACTA_JUNTA_GENERAL",
- "ADVERTISING_IO",
- "ADVISORY",
- "AFFILIATE_PROGRAM",
- "A2A_MONITORING",
- "PHANTOM_SHARES_GRANT",
- "RESIDENTIAL_TENANCY_GB",
- "RESIDENTIAL_TENANCY_US_CA",
- "DELAWARE_CERT_OF_INCORPORATION",
- "A2A_COMPUTE_PROCUREMENT",
- "CONSULTING",
- "A2A_CONTENT_LICENSE",
- "RESIDENTIAL_TENANCY_ES",
- "CONVERTIBLE_NOTE",
- "DATA_LICENSING",
- "DPA",
- "A2A_DATA_SHARING",
- "EMPLOYMENT",
- "CONTRATO_LABORAL",
- "EQUITY_INCENTIVE",
- "FOUNDERS",
- "BAA_NEGOTIATOR",
- "CESION_PI",
- "IP_ASSIGNMENT",
- "INFLUENCER_MARKETING",
- "JOINT_VENTURE",
- "A2A_KNOWLEDGE_ACCESS",
- "PHANTOM_SHARES_PLAN",
- "A2A_MARKETPLACE",
- "MSA",
- "NDA",
- "A2A_ORCHESTRATION",
- "A2A_PAYMENT_AUTHORIZATION",
- "PRIVACY_NOTICE",
- "SAFE",
- "SAAS",
- "SEED_INVESTMENT",
- "CONTRATO_SERVICIOS",
- "SHAREHOLDERS",
- "PACTO_SOCIOS",
- "SOFTWARE_DEVELOPMENT",
- "A2A_SUPPLY_CHAIN",
- "A2A_TASK_DELEGATION",
- "TECHNOLOGY_LICENSE",
- "TEMPLATE",
- "TERM_SHEET",
- "A2A_TOOL_LICENSE",
- "WHITE_LABEL_RESELLER"
-]delete_dealbuy_creditscreate_playbookdownload_contractgenerate_contractget_credit_balanceget_dealget_subscriptionsget_templateinitiate_negotiationjoin_negotiationlist_contract_typeslist_templatesNegotiate B2B deals agent to agent: every offer recorded, owner rules checked, agreements locked.
Negotiate for your human under PXP: tagged claims, escalation, decision brief, hash-chained ledger
Agent-to-agent negotiation: schedule meetings, agree prices and terms; each human approves the deal.
Contract-change authorization for AI agents: preflight a change to an API or MCP contract, get a signed decision, and verify the receipt offline. Only a granted change can proceed.
Add one secure layer between your agents and this server.
