Skip to main content
Glama

Create template party

create-template-party

Add a party to a template.

Use this tool when:

  • The user wants to add a party (e.g. a counterparty, customer, or employer) to a template

  • You are building up a template and need parties before adding signatories or signature blocks

There are two ways to add a party:

  • Internal (saved) party: send account_party_uuid (from list-account-parties) together with reference. No other fields may be sent in this case.

  • External party: send reference and scope, and optionally entity_name and address.

The two names on a party say different things:

  • reference is the generic label for the party's role on the template (e.g. "Employer", "Customer"), and stays the same for every document made from it.

  • entity_name is the name of the legal entity itself: a company's name ("Acme GmbH") or, when the party is an individual rather than an organisation, that person's name. On a template it is usually only known for the account's own side; a counterparty's is filled in per document, so leave it out rather than inventing one.

To render the party's details inline in the template text, reference the returned ref_uuid in the body (via replace-template-content) as:

<span data-party data-ref-uuid="<party ref_uuid>" data-format="name"></span>

where data-format selects what is rendered: "name" (the party's entity/company name), "reference" (its reference label), "address", or "address:inline". A data-format is required.

Note: adding a party does not, by itself, give that party anywhere to sign. If the party is meant to sign documents created from the template, follow up with create-template-signature-block for the party — and remember that the signature block must in turn be placed in the template content (via replace-template-content) inside a signature container, <div data-signatures><span data-signature-block data-ref-uuid="..."></span></div>, before it will appear on any document.

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": {
      "template_uuid": "<template_uuid>",
      "reference": "<reference>"
    },
    "name": "create-template-party"
  }
}

Input Schema

NameRequiredDescriptionDefault
scopeNoWhen internal_and_external, collaborators from this party may change the party's information. Required when account_party_uuid is not sent.
addressNoParty's address. Cannot be sent alongside account_party_uuid
referenceYesGeneric reference for the party's role on the template. e.g. "Counterparty", "Customer", "Employer"
entity_nameNoName of the legal entity that is party to the contract - a company's name, or a person's name when the party is an individual. Cannot be sent alongside account_party_uuid
template_uuidYesUUID of the template to add the party to
account_party_uuidNoTo add a saved account party, the uuid of a party from the list-account-parties tool. When provided, only reference may accompany it.

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?

The annotations already establish that this is a non-readonly, non-idempotent, non-destructive, closed-world mutation. The description adds important behavior beyond that: the two mutually exclusive field sets, the fact that adding a party does not create signing capability, and the requirement to create and place a signature block before signatures appear.

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?

The description is front-loaded and well structured with bullets for use cases, party modes, naming semantics, and follow-up steps. It is somewhat long because it includes HTML rendering and signature-container examples, but those details are relevant rather than repetitive.

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 template-party creation tool with an output schema and fully described inputs, the description covers workflow position, parameter modes, downstream dependencies, and rendering guidance. Nothing essential for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description adds substantial meaning beyond the schema by explaining the internal saved-party path versus the external-party path, the conditional role of scope, and the semantic distinction between reference and entity_name. It also documents the valid data-format values for rendering the returned ref_uuid.

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 first sentence is a specific verb and resource: 'Add a party to a template.' The use-when bullets distinguish this from document-party creation by tying it explicitly to template building before signatories or signature blocks.

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?

The description gives explicit when-to-use conditions, names list-account-parties as the source for saved parties, and points to create-template-signature-block and replace-template-content as follow-ups. The internal versus external party branches provide clear selection rules.

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