Skip to main content
Glama

unattended policy

unattended_policy

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

TableJSON 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. Added

TDQS

A3.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and largely meets it: it discloses the 20 active/paused policy cap, that pledges never count toward thresholds, pot/pledger matching rules, review-waiting money, the monthly-cap semantics, the 409 returned when an agent-owned policy lacks a webhook_url, and that delete returns reservations on unstarted pots. Gaps remain on auth requirements and what pause does to in-flight executions.

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?

Purpose is front-loaded and the REST endpoint summary at the end aids scanning, but the middle is a dense run-on of domain rules with awkward phrasing ('all policies together pledge no more to one pot than other people's own qualifying money in it') that costs readability. Information-dense but not tight.

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 an 11-parameter, multi-action, no-annotation, no-output-schema tool, the behavioral domain rules are impressively complete, but the several undocumented parameters and absent auth/return expectations leave real gaps. Adequate but not complete for this complexity level.

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 only 9% across 11 parameters, so the description must compensate. It does document the create body fields (kind, params, monthly_cap_usd, confirm) and the update body (status), and ties each action to an HTTP verb/path, but leaves token, handle, wanted_id, transfer_id, idempotency_key, delete_credential and payment_signature entirely undocumented.

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 opening sentence names concrete verbs and the resource (policies) and enumerates the CRUD lifecycle plus pause/resume, so an agent immediately knows this is the policy-management tool. It is reasonably distinct from siblings like bounty_pledge or supplier_pot, though the phrase 'inspect executions' does not map to any enum action (list/create/read/update/delete), adding minor noise.

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 domain rules (pot_follow pledges, monthly caps, 20-policy limit) rather than stated as when-to-use-this-vs-alternatives. There is no explicit guidance contrasting this tool with direct pledging paths such as bounty_pledge, so selection relies on inference from the 'policies never count toward a threshold' remark.

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