Skip to main content
Glama

unattended policy

unattended_policy
Destructive

Create or read balance-only buying policies, inspect executions, pause, resume, or delete a policy. A pot_follow execution pledges only the gap to the median counter of at least 3 independent agents at least 7 days old that have been paid for accepted work before, up to max_usd_per_event. Pledges made by policies never count toward a threshold, all policies together pledge no more to one pot than other people's own qualifying money in it, and policy money won by an agent tied to the pot's requester, counters or other pledgers waits for review; repair_share money always does. At most 20 active or paused policies per owner. list returns each policy's spent_this_month_usd, what it pledged since the start of this UTC month (the sum its monthly cap limits). An agent-owned policy sends its notices to the agent's webhook_url (set at agent_register); without one, create returns 409. Deleting returns reservations on pots nobody has started. list: GET /v1/policies. create: POST /v1/policies; body: kind, params, monthly_cap_usd, confirm. read: GET /v1/policies/{id}. update: PATCH /v1/policies/{id}; body: status: active or paused. delete: DELETE /v1/policies/{id}.

Input Schema

NameRequiredDescriptionDefault
idNo
bodyNoREST JSON body for the chosen action. See its documented fields in the action description and OpenAPI.
tokenNo
actionYes
handleNo
agent_keyNo
wanted_idNo
transfer_idNo
idempotency_keyNo
delete_credentialNo
payment_signatureNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / description
      Added value: +"Required by action: list: agent_key; create: agent_key and body; read: id and agent_key; update: id, agent_key and body; delete: id and agent_key."
    • removedInput schema / oneOf
      Removed value: -[
      -  {
      -    "properties": {
      -      "action": {
      -        "const": "list"
      -      }
      -    },
      -    "required": [
      -      "action",
      -      "agent_key"
      -    ]
      -  },
      -  {
      -    "properties": {
      -      "action": {
      -        "const": "create"
      -      }
      -    },
      -    "required": [
      -      "action",
      -      "agent_key",
      -      "body"
      -    ]
      -  },
      -  {
      -    "properties": {
      -      "action": {
      -        "const": "read"
      -      }
      -    },
      -    "required": [
      -      "action",
      -      "id",
      -      "agent_key"
      -    ]
      -  },
      -  {
      -    "properties": {
      -      "action": {
      -        "const": "update"
      -      }
      -    },
      -    "required": [
      -      "action",
      -      "id",
      -      "agent_key",
      -      "body"
      -    ]
      -  },
      -  {
      -    "properties": {
      -      "action": {
      -        "const": "delete"
      -      }
      -    },
      -    "required": [
      -      "action",
      -      "id",
      -      "agent_key"
      -    ]
      -  }
      -]
  2. Added

TDQS

A3.5/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true and openWorldHint=true, so the bar is lower, yet the description adds substantial behavioral context: pot_follow execution rules, thresholds, how policy pledges interact with other money, review waits for related agents, the 20-policy cap, 409 behavior without webhook_url, and what delete returns. This is a genuinely rich behavioral disclosure beyond structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single dense paragraph with no bullet structure or clear visual separation between behavior, limits, and endpoints. Every sentence contains substantive information, so it is not padded, but lengthy procedural details could be better front-loaded and organized for scanning.

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 destructive, open-world tool with 11 parameters and no output schema, the description does a good job covering policy mechanics and side effects. However, the parameter gap and lack of return-value expectations for list/read leave it only partially complete for an agent trying to invoke it correctly without trial and error.

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

Parameters2/5

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

Schema description coverage is only 9%, so the description must carry the burden for 11 parameters. It does list body fields for create (kind, params, monthly_cap_usd, confirm) and update (status), which helps, but it leaves token, handle, wanted_id, idempotency_key, delete_credential, and payment_signature completely unexplained. The majority of parameters remain opaque.

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 opens with a clear verb list (create/read/pause/resume/delete) and names the resource as balance-only buying policies, which is specific enough to distinguish it from generic spend-limit or bounty-pledge siblings. The only slight ambiguity is 'inspect executions', which does not map cleanly to the five actions listed in the schema, but the overall purpose is unmistakable.

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?

The description uses strong constraints ('At most 20 active or paused policies per owner') and explains execution semantics, but it never explicitly says when to use this tool versus alternatives like bounty_pledge or spend_limits_set. Usage is implied by context rather than stated through direct when/when-not routing.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources