Skip to main content
Glama
Sign In
AgentWorld MCP Server

AgentWorld MCP Server

by shawnhvac
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

publish_spend_authority_grant

Publish a signed spend-authority grant to bind an agent wallet to a spend envelope with per-period budget, no-confirm threshold, and expiry; the facilitator relays it for activation.

Instructions

[FREE] Publish a signed spend-authority grant, relayed to the facilitator.

Goal: bind an agent wallet to a spend envelope - budget per rolling period, threshold under which no confirmation is needed, and an expiry. Success means: the facilitator reports ok=true and the grant is live for the next verify.

signed_grant = {"grant": {...}, "signature": "0x..."} where the grant carries type="spend-authority-grant", agent, budgetUsdc, noConfirmUsdc, period (hour|day|month), validBefore (unix), nonce. The signature is EIP-191 over the canonical JSON (sorted keys, compact separators) and the recovere

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": {
      "signed_grant": "<signed_grant>"
    },
    "name": "publish_spend_authority_grant"
  }
}

Input Schema

NameRequiredDescriptionDefault
signed_grantYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

A3.8/5.0
Behavior4/5

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

With zero annotations the description carries full burden and does real work: it declares the tool free, states that the grant is relayed to a facilitator, and defines the success condition (ok=true, grant live for next verify). It stops short of describing failure modes, idempotency/replay behavior of the nonce, or what the caller sees on rejection, and the text is truncated mid-sentence ('the recovere'), likely cutting off the recovered-signer-must-match check.

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?

Front-loaded with the free-tier marker and the core action, then cleanly split into Goal, Success, and payload-shape sections, so an agent can parse it quickly. The final sentence is cut off mid-word, which is the one structural defect.

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 single-argument, no-output-schema tool this covers what is needed: the signing scheme, every field the grant must carry, and the observable success criterion. Remaining gaps are error responses, nonce/expiry validation rules, and the truncated tail of the signature-verification sentence.

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?

Schema coverage is 0% for a nested object, so the description must compensate, and it does: it enumerates grant fields (type, agent, budgetUsdc, noConfirmUsdc, period, validBefore, nonce) and specifies the signature as EIP-191 over canonical JSON with sorted keys and compact separators. The truncation at the end and the schema's additionalProperties=true leave the exact durability of the signature envelope only partially pinned down.

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?

The description uses a specific verb and resource ('Publish a signed spend-authority grant, relayed to the facilitator') and states the resulting state ('the grant is live for the next verify'). It does not explicitly distinguish itself from the closely related siblings get_spend_authority and revoke_spend_authority, so the agent must infer that this is the create path from the name alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied through the 'Goal' clause (bind an agent wallet to a spend envelope with budget, no-confirm threshold, and expiry) rather than stated as a when-to-use rule. There is no guidance on when not to call it, or on pairing with get_spend_authority to check state or revoke_spend_authority to undo it.

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

Deploy Server

Other Tools