Skip to main content
Glama

Dealroom

by io.github.sergiomaldo
OverviewDiscussionsAdmin

Make a contract in one call

generate_contract

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).

Input Schema

NameRequiredDescriptionDefault
roleNoDPA and BAA only: the role you take (see roles in list_contract_types)
partyYesYour side (the side the API key acts for). Send every detail you have: only what you send is written into the contract.
termsNoInputs 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.
titleNoName of the deal; made from the parties when left out
inlineNoThe contract itself in the answer: md (Markdown, the default here), html or txtmd
clausesNoOptional clause choices: clause id to option code (see get_template)
languageNoen
contractTypeYesCode (for example NDA) or guide slug (for example nda), from list_contract_types
counterpartyNoThe other side, with its address and jurisdiction of incorporation when you know them. Left out: its block stays blank for it to complete.
governingLawNoRequired when the contract type offers more than one
idempotencyKeyNoSend the same value when retrying, so a retry never makes or charges a second contract

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed18 schema fields changed
    • changedInput schema / properties / counterparty / description
      Previous 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."
    • changedInput schema / properties / counterparty / properties / address / description
      Previous 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."
    • addedInput schema / properties / counterparty / properties / contact
      Added 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"
+}
    • addedInput schema / properties / counterparty / properties / email / description
      Added 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."
    • addedInput schema / properties / counterparty / properties / jurisdiction
      Added 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"
+}
    • changedInput schema / properties / counterparty / properties / legalName / description
      Previous 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."
    • changedInput schema / properties / counterparty / properties / signatoryName / description
      Previous 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."
    • changedInput schema / properties / counterparty / properties / signatoryTitle / description
      Previous 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."
    • changedInput schema / properties / counterparty / properties / taxId / description
      Previous 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."
    • changedInput schema / properties / party / description
      Previous 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."
    • changedInput schema / properties / party / properties / address / description
      Previous 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."
    • addedInput schema / properties / party / properties / contact
      Added 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"
+}
    • addedInput schema / properties / party / properties / email / description
      Added 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."
    • addedInput schema / properties / party / properties / jurisdiction
      Added 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"
+}
    • changedInput schema / properties / party / properties / legalName / description
      Previous 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."
    • changedInput schema / properties / party / properties / signatoryName / description
      Previous 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."
    • changedInput schema / properties / party / properties / signatoryTitle / description
      Previous 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."
    • changedInput schema / properties / party / properties / taxId / description
      Previous 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."
  2. Changed1 schema field changed
    • changedInput schema / properties / governingLaw / enum
      Previous value: -[
-  "CALIFORNIA",
-  "ENGLAND_WALES",
-  "SPAIN"
-]New value: +[
+  "CALIFORNIA",
+  "ENGLAND_WALES",
+  "SPAIN",
+  "DELAWARE"
+]
  3. Changed2 schema fields changed
    • changedInput schema / properties / governingLaw / enum
      Previous value: -[
-  "CALIFORNIA",
-  "NEW_YORK",
-  "ENGLAND_WALES",
-  "SPAIN"
-]New value: +[
+  "CALIFORNIA",
+  "ENGLAND_WALES",
+  "SPAIN"
+]
    • changedInput schema / properties / terms / description
      Previous 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."
  4. First observed

TDQS

A4.3/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

All Dealroom toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources