Skip to main content
Glama
decision-anchor

decision-anchor-mcp

Official

propose_bilateral

Propose a bilateral agreement to a counterparty agent, creating a decision record that activates only upon mutual acceptance. Handles payment splits, task delegation, and joint commitments.

Instructions

Use when two agents need to fix a shared boundary — both sides must agree before the boundary is anchored. Essential for payment splits, task delegation, or any joint commitment between agents. Propose a bilateral agreement to another agent — creates a DD with declaration_mode 'bilateral' and waits for counterparty acceptance.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
auth_tokenYesYour DA agent auth token
request_idNoUnique idempotency key for this request. Auto-generated if omitted.
access_classNoOptional — read-access class for the record
dd_unit_typeNoDecision unit typesingle
parent_dd_idNoParent DD ID for lineage tracking
decision_typeYesDecision type
selection_scopeNoOptional — declared scope of the selection
selection_stateNoSelection stateSELECTED
delegation_stateNoOptional — delegation responsibility state (DAC add 0/10/30)
payment_signatureNoOptional x402 payment payload (base64), required only for paid calls. Omit it on the first call: the tool returns the payment challenge. Sign that challenge with your own wallet, then call this tool again with identical arguments plus this field. Decision Anchor never holds your key and never signs on your behalf.
ee_retention_periodNoHow long the record is retained (indefinite requires an active indefinite-retention subscription — otherwise 403)medium
origin_context_typeYesOrigin context
decision_action_typeYesAction type
counterparty_agent_idYesThe agent_id of the counterparty you are proposing to
excluded_option_countNoOptional — number of options excluded when deciding (integer >= 0)
ee_direct_access_quotaNoDirect access quota (omit to use the server config default)
ee_direct_access_periodNoDirect access period (e.g., 30d)30d
ee_responsibility_scopeNoResponsibility scopestandard
content_disclosure_scopeNoOptional — external exposure scope (DAC add 0/15/40)
ee_disclosure_format_policyNoDisclosure formatinternal
ee_integrity_verification_levelNoVerification rigorbasic
Behavior4/5

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

No annotations are provided, so the description carries full responsibility. It discloses key behavioral traits: the created DD has declaration_mode 'bilateral', the tool 'waits for counterparty acceptance', and anchoring only happens after mutual agreement. This is meaningful, though it omits rejection handling or timeout behavior.

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?

Three sentences, front-loaded with the 'Use when' directive, and each clause adds value. No filler, repetition, or irrelevant detail.

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 tool is complex with 21 parameters, but the schema is exhaustive. The description explains the core proposal-and-acceptance flow and use cases. It does not describe the return value (though no output schema exists), which is a minor gap for such a feature-rich tool.

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

Parameters3/5

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

Schema description coverage is 100%, with all 21 parameters documented via types, enums, and defaults. The description's mention of declaration_mode 'bilateral' provides conceptual context but does not enhance parameter-level understanding beyond the schema. Baseline 3 is appropriate.

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 uses the specific verb 'propose' with a clear resource ('a bilateral agreement to another agent'). It explicitly distinguishes from sibling tools by stating it creates a DD with declaration_mode 'bilateral' and waits for counterparty acceptance, unlike unilateral creation tools. Use cases like payment splits and task delegation clarify scope.

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?

The opening phrase 'Use when two agents need to fix a shared boundary' provides explicit when-to-use context, reinforced by concrete examples. However, it does not explicitly state when NOT to use this tool or name alternative tools, so it stops short of a full 5.

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/decision-anchor/mcp-server'

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