Skip to main content
Glama
decision-anchor

decision-anchor-mcp

Official

create_decision

Before executing boundary-crossing actions such as payments or delegations, record a tamper-evident decision to anchor responsibility and enable counterparty verification.

Instructions

Use when your agent is about to execute an action that crosses an external boundary — payment, delegation, or agreement with another agent. This anchors the responsibility scope before execution. Record a tamper-evident decision. Each decision is added to your record trajectory, which you and a counterparty can check against DA's external entry. Omitting the EE axes applies the defaults (medium/basic/internal/standard) — equivalent to the EE_standard preset, currently 45 DAC total; the cheapest combination is EE_basic (base fee only, currently 10 DAC). Presets are operator-adjustable — fetch current totals via GET /v1/pricing/ee-presets.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
templateNov1.3.0: required when content_inclusion_flag=1. 7-dimensional decision content metadata.
ee_presetNoOptional EE preset name — expands into the four EE axes and overrides them (fetch active presets via GET /v1/pricing/ee-presets; e.g. EE_basic, EE_standard, EE_high)
auth_tokenYesYour DA agent auth token
request_idNoOptional idempotency key — must be a UUID (the server rejects non-UUID values). 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_stateNov1.3.0: 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.
dd_declaration_modeNoDeclaration modeself_declared
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
excluded_option_countNoOptional — number of options excluded when deciding (integer >= 0)
content_inclusion_flagNov1.3.0: 0=branch 0 (default, no metadata), 1=branch 1 (template required). No extra DAC — same base fee as branch 0 (the v1.3.0 surcharge was removed in v1.3.14). Branch 1 decisions are the only ones counted toward the anomaly-compare sample.
ee_direct_access_quotaNoDirect access quota (omit to use the server config default)
premium_payment_sourceNoPremium payment source (trial is applied automatically by the server when eligible)
ee_direct_access_periodNoDirect access period (e.g., 30d)30d
ee_responsibility_scopeNoResponsibility scopestandard
content_disclosure_scopeNov1.3.0: external exposure scope (DAC add 0/15/40)
ee_disclosure_format_policyNoDisclosure formatinternal
ee_integrity_verification_levelNoVerification rigorbasic
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so thoroughly: it discloses tamper-evidence, the record trajectory, external checking against DA, the EE-axis defaults with current DAC totals, preset adjustability, and automatic trial application. These are meaningful behavioral facts that go beyond the schema.

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 four sentences, front-loaded with the primary use case, then efficiently delivers pricing and default behavior details. Every sentence earns its place; there is no filler or redundancy.

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?

For a complex 25-parameter mutation tool with no output schema, the description provides solid invocation context, defaults, and cost information. However, it does not explain the response/confirmation flow or how this tool fits into later sibling operations like confirm_decision, leaving some contextual gaps.

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?

The schema already provides 100% parameter coverage with detailed descriptions, so the baseline is 3. The description adds genuine value by explaining the EE axes/presets, cost implications of omitting axes, and branch behavior, enriching the semantics without re-listing all 25 parameters.

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 'Use when your agent is about to execute an action that crosses an external boundary — payment, delegation, or agreement with another agent' and then says 'Record a tamper-evident decision.' This clearly states the verb, resource, and invocation context, distinguishing it from siblings like confirm_decision and propose_bilateral by emphasizing the pre-execution recording function.

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 an explicit 'Use when' condition for boundary-crossing actions and notes 'before execution.' However, it does not name alternatives or state when not to use the tool, leaving the distinction from related sibling tools implicit rather than explicit.

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