Skip to main content
Glama

Complete Agent Delegation

agent_complete_delegation

Finalize a pending agent delegation after WalletChan signature approval, verify the signer, and store the signed delegation encrypted in the agent vault.

Instructions

Complete a pending agent delegation after the WalletChan signature request is approved, verify the signer, and store the signed delegation encrypted in the agent vault.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
requestIdNoOptional signature request ID. Defaults to the request stored by agent_request_delegation_signature.
signatureNoOptional direct signature override. Normally omit and let WalletChan MCP read the tracked signature request.
delegationIdYesDelegation ID returned by agent_prepare_delegation.
pendingActionIdNoOptional pending delegated action to submit after activation. Defaults to the pending action associated with this delegation, when one exists.
submitPendingActionNoWhether to submit an MCP-created pending agent action after the delegation activates. Defaults to true when a matching pending action exists.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

A3.8/5.0
Behavior4/5

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

No annotations are supplied, so the description must carry the behavioral load, and it does disclose three concrete facts: this is a mutation ('Complete'), it verifies the signer, and it persists the signed delegation encrypted in the agent vault. It omits auth/permission requirements, idempotency, and failure behavior, which keeps it from a 5.

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?

A single front-loaded sentence with no filler; the action verb and precondition lead, followed by the side effects. Slightly dense with three clauses, but every clause carries information.

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

Completeness3/5

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

For a multi-step mutation with no annotations and no output schema, the description covers the workflow position and side effects but says nothing about what happens on a bad signature, whether repeated calls are safe, or what the caller receives. Adequate but with visible gaps.

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%, so the schema already documents all five parameters including defaults and the signature override semantics. The description adds no additional meaning about requestId, signature, pendingActionId, or submitPendingAction, so the baseline 3 applies.

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

Purpose4/5

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

States a specific verb and resource ('Complete a pending agent delegation') and adds the two internal steps (verify signer, store encrypted in agent vault). The precondition 'after the WalletChan signature request is approved' positions it in the workflow relative to agent_prepare_delegation and agent_request_delegation_signature, though it never names those siblings explicitly.

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?

Gives a clear triggering context: run this only after the WalletChan signature request has been approved. It does not state exclusions or name an alternative for the case where the request is not yet approved, so it falls short of explicit when/when-not guidance.

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