Skip to main content
Glama

Create document party

create-document-party

Adds a party to a document, alongside any parties it already has.

Use this tool when:

  • A contracting party is missing from a document, e.g. the counterparty of a contract created from scratch

  • A signatory has to be added for a party the document does not have yet: create the party first, then add the signatory with create-document-signatory

Pass party_account_party_uuid to add one of the account's saved parties (list-account-parties), usually the user's own company. A saved party can be on a document only once, and is always internal. For any other party, give party_entity_name, party_address and party_scope instead.

Parties cannot be added while the document is archived, in the signing stage or an approved stage, going through an approval checkpoint, or bound by a preemptive signature.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "document_uuid": "<document_uuid>",
      "party_reference": "<party_reference>"
    },
    "name": "create-document-party"
  }
}

Input Schema

NameRequiredDescriptionDefault
party_scopeNoWhen this is internal_and_external, collaborators from this party may change the party's information. Required when party_account_party_uuid is not sent
document_uuidYesUUID of the document to add the party to. If you don't already have the document's UUID, use the list-documents tool to find it.
party_addressNoParty's address. Cannot be sent alongside party_account_party_uuid
party_referenceYesGeneric reference for the party. e.g. "Counterparty", "Customer", "Employee", etc
party_entity_nameNoActual name of the party. Cannot be sent alongside party_account_party_uuid
party_account_party_uuidNoTo add a saved account party, the uuid of a party from the list-account-parties tool

Output Schema

NameRequiredDescriptionDefault
uuidNoIdentifier for the party - unique to the specific instance of the party. Do not show to the user unless they ask for it
addressNoThe party's address. Absent when not yet known
ref_uuidNoA static reference identifier, allowing parties in documents to be matched their corresponding party in the document's source template. Do not show to the user unless they ask for it
referenceNoA generic reference for the party. e.g. "Customer", "Employee", etc
entity_nameNoThe actual name of the party. Absent when not yet known
is_internalNoTrue if the party belongs to this account
_entity_typeNoOnly relevant for tooling. Do not show to the user

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare this as a non-read-only, non-destructive, non-idempotent operation. The description adds important behavioral constraints beyond annotations: saved parties can appear only once, saved parties are always internal, and parties cannot be added in several document lifecycle states.

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

Conciseness5/5

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

The description is front-loaded with the core action, follows with structured usage bullets, then parameter routing and restrictions. The bullets and short paragraphs make it easy to scan without wasting sentences.

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 a create/mutation tool with annotations, full schema description coverage, and an output schema, this is complete. It covers purpose, alternatives, parameter routing, and lifecycle restrictions an agent needs before invoking it.

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 100%, so the baseline is 3, but the description adds meaningful routing guidance: use party_account_party_uuid for saved account parties and otherwise provide party_entity_name, party_address, and party_scope. It does not document every parameter, but it clarifies the key mutually exclusive paths.

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

Purpose5/5

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

The description gives a specific verb and resource: adding a party to a document alongside existing parties. It also distinguishes the relevant neighboring workflows by pointing to create-document-signatory for signatories and list-account-parties for saved account parties.

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

Usage Guidelines5/5

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

It gives explicit when-to-use conditions, including missing contracting parties and signatory prerequisites, and names the alternative tool for signatories. It also states when the tool cannot be used, covering archived, signing, approved, approval checkpoint, and preemptive signature states.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources