Skip to main content
Glama

Form an agreement with a known counterparty

create_agreement

Form an agreement between two known parties in a single transaction, capturing signed offer, acceptance, and commitment from their verified mandate decisions.

Instructions

Form an agreement between two parties who already know each other, with no marketplace and no negotiation room. Call this once per transaction.

Both parties present the allow decision their own mandate produced. The offeror verifies {"action_type": "offer.submit", "transaction_id": ..., "counterparty_organization_id": <the offeree's org>, "proposed_terms": } and the offeree verifies the same document with action_type offer.accept and the offeror's organisation. Pass each result as buyer_decision and supplier_decision. A decision over a different act, a different mandate, or an amount the mandate did not allow refuses the whole call and records nothing.

It writes the whole formation in one call: the offeror's signed offer carrying a session identifier it mints, the offeree's acceptance over the exact offer hash, the agreement carrying both parties' signatures over the same bytes, the supplier's commitment, and two events, agreement.direct (draft to agreement_pending) and agreement.committed (agreement_pending to committed), each countersigned by the other party.

The transaction ends this call in state committed. Follow with record_obligation act=issue.

Refusals: a transaction that already left draft (A202-STATE-TRANSITION-DENIED), an unregistered profile (A202-PROFILE-UNKNOWN), terms the profile does not allow (A202-PROFILE-TERMS-INVALID), an offer expiring before it was made (A202-OFFER-EXPIRED).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
buyerYesThe buying party: organisation, agent, mandate, and signing key.
termsYesThe commercial terms. core is identical for every transaction profile; profile_terms is validated against the schema the profile names.
supplierYesThe supplying party: organisation, agent, mandate, and signing key.
session_idNoOptional session identifier, prefixed ses_. The offeror mints one when absent. Bilaterally this names the relationship; nothing orders it.
offeror_roleNoWhich party makes the offer. Defaults to supplier.
rules_versionNoThe rule set version the record is written under. Defaults to 1.3, the version that registers direct formation. Earlier versions never registered it and refuse the path.
buyer_decisionYesThe result verify_mandate returned for this exact act, passed through unchanged. It must be an allow, made under this party's own mandate, over the act document this tool builds, and made within the last 60 seconds. Where it does not match, the refusal detail states the exact proposed_action to verify. For the buyer this is the decision over its own act: offer.accept when the supplier is the offeror, offer.submit when the buyer is.
transaction_idYesThe transaction, prefixed txn_. Choose one per deal; it is the key everything else is recorded under.
offer_valid_untilYesRFC 3339 instant the offer expires. Must be later than now.
supplier_decisionYesThe result verify_mandate returned for this exact act, passed through unchanged. It must be an allow, made under this party's own mandate, over the act document this tool builds, and made within the last 60 seconds. Where it does not match, the refusal detail states the exact proposed_action to verify. For the supplier this is the decision over its own act: offer.submit when the supplier is the offeror, offer.accept when the buyer is.
offer_evidence_refsNoOptional evidence the offer relies on, such as an accreditation.
Behavior5/5

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

The description discloses the full write path: 'It writes the whole formation in one call... two events, agreement.direct and agreement.committed, each countersigned by the other party.' It also details refusal conditions (A202-* codes) and notes that a non-matching decision 'refuses the whole call and records nothing.' These are meaningful behavioral details that go beyond the provided annotations (readOnlyHint=false, etc.), which are minimal.

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 appropriately dense for the tool's complexity. It is organized logically: purpose, scenario, verification steps, write behavior, follow-up, and refusals. Every sentence contributes necessary information without filler. It is longer than average, but the complexity of the tool justifies the length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description comprehensively covers the workflow, verification requirements, state transitions, refusal reasons, and next-step guidance. The only notable gap is that it does not explicitly describe the return value of the tool; since there is no output schema, a brief note on what the call returns (e.g., the transaction record or confirmation) would complete the picture.

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 the schema covers all parameters, the description adds essential semantic context for buyer_decision and supplier_decision by specifying the exact act documents to verify, the role-dependent action_type values (offer.submit vs. offer.accept), and the 60-second validity window. It also explains that session_id is minted by the offeror if absent. This substantially enriches the meaning of the parameters beyond the schema descriptions.

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 opens with 'Form an agreement between two parties who already know each other, with no marketplace and no negotiation room.' This specifies the exact action and resource, and distinguishes it from marketplace-based flows or other transaction tools. It is not a tautology and clearly states the scope.

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 explicitly states 'Call this once per transaction' and clarifies the appropriate scenario (known counterparties, no marketplace, no negotiation). It also provides a clear follow-up action: 'Follow with record_obligation act=issue,' which orients the agent on the next step. This is strong when-to-use guidance with an explicit alternative.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/a202-protocol/a202'

If you have feedback or need assistance with the MCP directory API, please join our Discord server