A
licenseA
qualityD
maintenanceSpending limits for AI agents. Create budgets, enforce limits, track spend across x402, cards, MPP, or any payment rail.
7
18
Apache 2.0
cycles-mcp-server
by runcycles
This server provides AI agents with runtime budget control, cost enforcement, and usage auditing via the Model Context Protocol (MCP) — without modifying agent code.
Core tools:
cycles_reserve— Lock budget before costly operations (LLM calls, tool invocations, API calls); returns an ALLOW/DENY decision and reservation IDcycles_commit— Record actual cost after an operation, releasing unused reserved budgetcycles_release— Cancel a reservation when an operation is skipped or fails, returning funds to the poolcycles_extend— Heartbeat a long-running reservation to prevent it from expiringcycles_decide— Lightweight preflight check: ask if an action would be allowed without locking budgetcycles_check_balance— Inspect remaining, reserved, spent, allocated, and debt amounts for any scope (tenant, workspace, agent, workflow, etc.)cycles_list_reservations— Audit/debug reservations filtered by status (ACTIVE, COMMITTED, RELEASED, EXPIRED) or subjectcycles_get_reservation— Retrieve full details of a specific reservation by IDcycles_create_event— Fire-and-forget usage metering without the reserve/commit lifecycle
Key use cases:
Enforce per-task, per-tenant, or per-workspace LLM cost caps
Prevent runaway agent loops from exceeding budget limits
Enable agents to self-regulate (e.g., switch to cheaper models when budget is low)
Track and audit spend across multi-tenant or multi-agent pipelines
Meter usage in existing systems without changing agent code
Also supports mock mode for local development, built-in prompts for budget strategy design and overrun diagnosis, and integration with any MCP-compatible host (Claude Code, Cursor, Windsurf, custom agents).
Cycles MCP Server — AI agent runtime control over Model Context Protocol
MCP server that gives any MCP-compatible AI agent (Claude Code, Cursor, Windsurf, custom agents) runtime budget, action, and audit authority — enforce LLM cost limits, tool call caps, action permissions, and audit trails before execution, with zero agent code changes. Connect via MCP and use the budget tools (cycles_reserve, cycles_commit, cycles_release, cycles_decide) directly from the agent's tool-calling loop. Powered by Cycles. See Security Model & Enforcement Boundary for what is enforced server-side versus cooperatively in the agent loop.
Why use this?
Autonomous AI agents (Claude, GPT, custom agents) call LLMs, invoke tools, and hit external APIs — but have no built-in way to cap how much they spend. A single agent loop can burn through hundreds of dollars before anyone notices. Multiply that across tenants and teams, and cost control becomes a real problem.
This MCP server gives any MCP-compatible agent a runtime budget authority: a set of tools to check, reserve, spend, and release budget before and after every costly operation. The agent asks "can I afford this?" before acting, and reports what it actually used afterward.
Who needs this:
Platform teams building multi-tenant agent systems that need per-customer or per-workspace spend limits
Agent developers who want agents to self-regulate — degrade to cheaper models when budget is low, skip optional tool calls, reduce retries
Enterprises deploying AI agents that need guardrails so a runaway agent can't blow through a budget
Why MCP specifically:
MCP is the standard protocol that AI hosts (Claude Desktop, Claude Code, Cursor, Windsurf, custom agents) use to discover and call tools. By exposing Cycles as an MCP server, any MCP-compatible agent gets budget awareness as a plug-in — just add the server to your config. No SDK integration in the agent's own code required.
The server also ships built-in prompts so an AI assistant can help you design your budget strategy, generate integration code, and diagnose budget overruns — not just enforce budgets at runtime.
Related MCP server: l6e-mcp
Use Cases
Coding agent with a per-task dollar cap
You run a Claude Code agent that writes and iterates on code. Each task should cost no more than $5. The agent calls cycles_reserve before every LLM call with a cost estimate in USD_MICROCENTS. If the reservation comes back DENY, the agent stops and reports "budget exhausted" instead of silently racking up charges. When the call completes, cycles_commit records the actual token cost so the running total stays accurate.
Multi-tenant SaaS with per-customer budgets
Your platform lets customers deploy AI assistants. Each customer has a monthly budget. The agent calls cycles_check_balance at the start of a conversation to see what's left, then cycles_reserve before each tool invocation (web search, code execution, API calls). If customer Acme is near their limit, the decision comes back ALLOW_WITH_CAPS — the agent automatically drops to a cheaper model and skips optional tools. Customer budgets are isolated; one customer's heavy usage never affects another.
Multi-agent pipeline with shared budget
You have an orchestrator that fans out to specialist agents — a researcher, a coder, and a reviewer. All three draw from the same workflow budget. Each agent calls cycles_reserve before its work; the Cycles server tracks concurrent reservations so the total never exceeds the workflow limit. If the researcher burns through 80% of the budget, the coder's next reservation gets DENY and the orchestrator can decide to skip the review step instead of going over budget.
Long-running data pipeline with heartbeats
An agent processes a large dataset in chunks, each chunk taking several minutes. It calls cycles_reserve with a 5-minute TTL before each chunk, then cycles_extend every 60 seconds to keep the reservation alive while processing. If the agent crashes, the reservation expires automatically and the locked budget returns to the pool — no manual cleanup needed.
Fire-and-forget usage metering
You have an existing system that already makes LLM calls and you just want to track spend, not gate it. After each call completes, the agent fires cycles_create_event with the actual cost. No reservation needed — the event is applied atomically to all budget scopes (tenant, workspace, app). You get a real-time spend dashboard without changing your existing call flow.
Grok Bot with a non-bypassable paid-media action
Grok Bot can call custom MCP tools, but installing the standalone Cycles tools beside a paid-media connector remains cooperative: the Bot could call the other connector directly. The Grok Bot paid-media gateway shows the hard-enforcement shape instead. Its mutation handler derives scope from trusted server configuration, requires a live RISK_POINTS reservation, propagates the reservation ID to the downstream API, and conservatively settles ambiguous outcomes.
Installation
npm install @runcycles/mcp-serverSetup
Claude Desktop
One-click (recommended): download cycles-mcp-server-<version>.mcpb from the latest release and open it with Claude Desktop (double-click, or Settings → Extensions → drag it in). Claude Desktop shows a config screen for your Cycles server URL and API key — or enable mock mode to explore the tools without a server (no enforcement).
Manual (JSON config): add to your claude_desktop_config.json:
macOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:
%APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"cycles": {
"command": "npx",
"args": ["-y", "@runcycles/mcp-server"],
"env": {
"CYCLES_BASE_URL": "http://localhost:7878",
"CYCLES_API_KEY": "your-api-key-here"
}
}
}
}For local development without an API key, use mock mode:
{
"mcpServers": {
"cycles": {
"command": "npx",
"args": ["-y", "@runcycles/mcp-server"],
"env": {
"CYCLES_MOCK": "true"
}
}
}
}Claude Code
claude mcp add cycles -- npx -y @runcycles/mcp-serverSet your environment variables:
export CYCLES_BASE_URL=http://localhost:7878
export CYCLES_API_KEY=your-api-key-hereCursor / Windsurf / Other MCP Hosts
Use stdio transport with:
command: npx
args: ["-y", "@runcycles/mcp-server"]
env: { CYCLES_API_KEY: "your-key", CYCLES_BASE_URL: "http://localhost:7878" }Configuration
export CYCLES_API_KEY=your-api-key-here # required (unless CYCLES_MOCK=true)
export CYCLES_BASE_URL=http://localhost:7878 # required — your Cycles server URL
export CYCLES_MOCK=false # true disables live enforcement and returns synthetic responses
export CYCLES_ALLOW_MOCK_IN_PRODUCTION=false # must be true to use mock mode with NODE_ENV=production
export PORT=3000 # optional, for HTTP transport
export HOST=127.0.0.1 # optional HTTP bind address; unset binds all interfaces
export MCP_HTTP_AUTH_TOKEN=replace-me # optional bearer token required on /mcp when set
# Optional subject defaults — merged into any tool call that omits the field,
# so agents can call cycles_reserve with just an action and amount:
export CYCLES_DEFAULT_TENANT=acme
export CYCLES_DEFAULT_WORKSPACE=prod
export CYCLES_DEFAULT_APP=support-bot
export CYCLES_DEFAULT_WORKFLOW=
export CYCLES_DEFAULT_AGENT=
export CYCLES_DEFAULT_TOOLSET=Agent-ergonomics behavior: explicit subject fields always win over CYCLES_DEFAULT_* values, and cycles_check_balance accepts an empty call when defaults supply a filter. idempotencyKey remains required on every mutating tool — same-key replay is the protocol's retry deduplication and evidence-suppression mechanism, and only the caller can hold a key stable across retries. Responses carry plain-text hints after the JSON payload when the budget is under pressure (DENY, ALLOW_WITH_CAPS, or under ~15% remaining), so agents self-regulate without host support.
Mock mode prints a prominent warning on every startup, and generated mock reservation/event IDs begin with mock_. The server refuses to start with CYCLES_MOCK=true and NODE_ENV=production unless CYCLES_ALLOW_MOCK_IN_PRODUCTION=true is also set.
For HTTP transport, set MCP_HTTP_AUTH_TOKEN to require Authorization: Bearer <token> on every /mcp request. Blank or whitespace-only configured tokens are rejected at startup. /health remains public. If no token is configured while HTTP binds to a non-loopback address, the server prints a prominent warning.
Need an API key? API keys are created via the Cycles Admin Server (port 7979). See the deployment guide to create one, or run:
curl -s -X POST http://localhost:7979/v1/admin/api-keys \
-H "Content-Type: application/json" \
-H "X-Admin-API-Key: admin-bootstrap-key" \
-d '{"tenant_id":"acme-corp","name":"dev-key","permissions":["reservations:create","reservations:commit","reservations:release","reservations:extend","reservations:list","balances:read","decide","events:create"]}' | jq -r '.key_secret'The key (e.g. cyc_live_abc123...) is shown only once — save it immediately. For key rotation and lifecycle details, see API Key Management.
Individual vs. team use: For individual use or evaluation, set
CYCLES_MOCK=true— no server or API key required. If you're deploying agents for multiple users or workspaces, see the multi-tenant setup guide.
Running
# stdio transport (default — for Claude Desktop / Claude Code)
npx @runcycles/mcp-server
# HTTP transport (Streamable HTTP on port 3000)
npx @runcycles/mcp-server --transport httpTools
Tool | Protocol Endpoint | Description |
|
| Reserve budget before a costly operation |
|
| Commit actual usage after operation completes |
|
| Release reservation without committing |
|
| Extend reservation TTL (heartbeat) |
|
| Lightweight preflight budget check |
|
| Check current budget balance for a scope |
|
| List reservations with filters |
|
| Get reservation details by ID |
|
| Record usage without reserve/commit lifecycle |
Agent Decision Loop
Every costly operation follows a reserve → execute → finalize lifecycle:
1. cycles_reserve → Lock budget before each costly step
2. Execute → Perform the operation (respecting any caps)
3. cycles_commit → Record actual usage — releases unused portion back to the pool
OR cycles_release → Cancel the reservation if the step was skippedOptionally, before reserving:
cycles_check_balance— inspect remaining budget to plan your approachcycles_decide— lightweight preflight check without locking funds
Every reservation must be finalized with either cycles_commit or cycles_release — never leave reservations dangling. For long-running operations, use cycles_extend to heartbeat the reservation TTL so it doesn't expire mid-operation. See integration patterns for detailed examples.
Security Model & Enforcement Boundary
Cycles authority is enforced at two different boundaries, and it matters which one you are relying on.
Enforced unconditionally (server-side)
Every cycles_reserve, cycles_commit, and cycles_decide call is a request for authority, evaluated by the Cycles runtime against the authenticated tenant's policies and current balances. This holds regardless of what the model generates:
Malformed amounts never leave the MCP server. Input schemas reject negative, fractional, or non-numeric amounts, and any value above JavaScript's safe-integer range (2⁵³ − 1), before a request is made.
A well-formed but excessive reservation is refused by the Cycles server with a
BUDGET_EXCEEDEDerror — no reservation ID is issued and nothing is spent. A hallucinated or prompt-injected oversized reserve cannot make Cycles grant more authority than policy allows.A reservation by itself spends nothing. Budget only moves on
cycles_commit(orcycles_create_event), and commits are bounded by the reservation plus the configured overage policy.
Cooperative (inside the agent's tool loop)
This MCP server exposes budget tools alongside the host's other tools — it does not sit between the model and those tools. When a reservation is denied, the agent is instructed not to proceed, but nothing in the MCP protocol forces it to. A prompt-injected or misbehaving agent could skip cycles_reserve entirely and invoke a consequential tool directly.
Making enforcement non-bypassable
For the budget check to be a hard gate rather than a convention, put Cycles in the actual dispatch path so the downstream operation cannot execute without a valid reservation:
Gate in the host application — before executing a consequential operation, require a reservation ID and verify it with
cycles_get_reservation.Use a dispatch-path integration — framework middleware that wraps tool execution (e.g. the Cycles Spring Boot starter or LangChain integration) enforces reserve-before-execute in code the model cannot skip.
Meter server-side as a backstop — where gating isn't possible, record actual usage with
cycles_create_eventso overruns are at least detected and budgets stay accurate.
Mock mode enforces nothing
With CYCLES_MOCK=true, every call returns a synthetic ALLOW — it exists for development and demos only. The server refuses to start in mock mode when NODE_ENV=production (unless explicitly overridden) precisely so a synthetic ALLOW is never mistaken for a real one.
Resources
URI | Description |
| Current budget balance for a tenant |
| Reservation details |
| Getting started guide |
| Integration patterns |
Prompts
Prompt | Description |
| Generate Cycles integration code |
| Analyze budget exhaustion |
| Recommend scope hierarchy and limits |
Development
npm install
npm run dev # stdio transport with tsx
npm run dev:http # HTTP transport with tsx
npm run build # TypeScript build
npm run lint # ESLint
npm test # Run tests
npm run test:coverage # Run with coverage (95%+ lines, 85%+ branches)
npm run typecheck # Type check without emittingPublishing
The server is published to two registries:
Registry | Identifier | How |
npm |
| CI publishes on |
MCP Registry |
| CI publishes the |
Releases are automated with release-please. PRs are squash-merged (repo enforces squash-only) with conventional PR titles (feat:, fix:, …) — the PR title becomes the single commit on main that release-please reads. It maintains a release PR that accumulates the changelog and bumps the version in package.json, server.json (both fields), and the AUDIT.md header. Merging the release PR creates the tag and GitHub release, then dispatches the publish pipeline.
CI runs on the tag: test (Node 20+22) → npm publish (Trusted Publishing/OIDC, with provenance) → smoke test against the published tarball → MCP Registry publish → MCPB desktop-extension bundle attached to the GitHub release.
Manual fallback (works unchanged): bump versions yourself, then tag and push:
git tag v0.5.0
git push origin v0.5.0Documentation
Cycles Documentation — full docs site
MCP Server Quickstart — getting started guide
Integrating Cycles with MCP — detailed MCP integration guide
Protocol Conformance
This MCP server is audited against the Cycles Protocol v0.1.24 OpenAPI spec. See AUDIT.md for the full conformance report.
Privacy Policy
Full policy: runcycles.io/privacy
The short version: this server connects only to the Cycles server URL you configure and sends it budget requests (subject identifiers, amounts, usage metrics) — Cycles is self-hosted, so that data stays in your infrastructure and never reaches runcycles. No LLM prompts or responses are stored. The server contains no telemetry, phone-home, or update checks. In mock mode, no network requests are made at all. Your API key lives in your local configuration and is sent only to your configured Cycles server.
License
Apache-2.0
Available Tools
9 toolscycles_check_balanceCheck Budget BalanceARead-only
Check current budget balance for a scope. Returns remaining, reserved, spent, allocated, and debt amounts. At least one subject filter (tenant, workspace, app, workflow, agent, or toolset) is required. Do not use as a substitute for cycles_reserve — balances can change between check and action.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| app | No | ||
| agent | No | ||
| limit | No | ||
| cursor | No | ||
| tenant | No | ||
| toolset | No | ||
| workflow | No | ||
| workspace | No | ||
| includeChildren | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| hasMore | No | |
| balances | Yes | |
| nextCursor | No |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=false. The description adds value by explaining that balances can change between check and action, which is important behavioral context beyond what annotations provide.
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 concise with two sentences. The first sentence states the main purpose, and the second adds a constraint and warning. No superfluous information.
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?
Given the presence of an output schema (not shown but indicated), the description sufficiently covers the tool's purpose and key constraints. It lacks details on all parameters, but the essential requirement (at least one filter) is clearly stated. The warning about balance changes adds important context.
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 0%, so the description must compensate. It clarifies that at least one of the listed filters (tenant, workspace, app, workflow, agent, or toolset) is required, but does not explain other parameters like limit, cursor, or includeChildren. Partial compensation.
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 clearly states the tool checks the current budget balance for a scope and lists the specific amounts returned (remaining, reserved, spent, allocated, debt). It also distinguishes itself from the sibling tool cycles_reserve by warning not to use it as a substitute.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states that at least one subject filter is required (tenant, workspace, app, workflow, agent, or toolset) and warns not to use this tool as a substitute for cycles_reserve. This provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cycles_commitCommit UsageAIdempotent
Commit actual usage after an operation completes. Always call this after cycles_reserve whether the operation succeeded or failed. Finalizes the budget charge and releases any unused reserved amount back to the pool.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| actual | Yes | ||
| metrics | No | ||
| metadata | No | ||
| reservationId | Yes | ||
| idempotencyKey | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| charged | Yes | |
| balances | No | |
| released | No |
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotency and non-destructiveness. Description adds that it must follow a reservation, commits actual usage, and releases unused amount, providing lifecycle context beyond structured annotations.
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?
Three concise sentences: purpose, usage order, and effect. Every sentence adds value with no 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?
Covers core behavior and workflow dependency. Lacks details on error conditions or idempotency handling, but has output schema to document return values.
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 0%, and the description does not explain any parameters (e.g., reservationId, idempotencyKey, actual, metrics, metadata). Agent must infer from names alone, which is insufficient for correct invocation.
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?
Clearly states it commits actual usage after an operation completes, linking to cycles_reserve. Distinguishes from siblings by specifying it finalizes the charge and releases unused reserved amount.
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?
Explicitly says to call after cycles_reserve regardless of success/failure. Lacks mention of when not to use (e.g., alternatives like cycles_release), but the context is clear for the intended workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cycles_create_eventRecord Usage EventAIdempotent
Record a usage event directly without the reserve/commit lifecycle. Use for fire-and-forget metering of completed operations where pre-estimation is not available. The event is applied atomically to all derived scopes.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| actual | Yes | ||
| metrics | No | ||
| subject | No | ||
| metadata | No | ||
| clientTimeMs | No | ||
| overagePolicy | No | ||
| idempotencyKey | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| charged | No | |
| eventId | Yes | |
| balances | No |
TDQS
A3.9/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds value beyond annotations: 'applied atomically to all derived scopes' and 'fire-and-forget'. Annotations already indicate idempotent and non-destructive. No contradictions.
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?
Three concise sentences, no redundancy. Every sentence adds meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, 3 required, nested objects, and no schema descriptions, the description lacks sufficient detail for correct invocation. Missing parameter guidance.
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?
Description does not explain any parameters despite 0% schema description coverage and complex nested objects. Agent relies solely on schema structure without contextual intent.
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 uses specific verb 'Record' and resource 'usage event'. It distinguishes from siblings by explicitly contrasting with the reserve/commit lifecycle.
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?
Describes when to use: 'fire-and-forget metering of completed operations where pre-estimation is not available'. Implicitly excludes the reserve/commit lifecycle. Lacks explicit exclusion of alternatives but clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cycles_decidePreflight Budget CheckAIdempotent
Lightweight preflight check — ask whether an action would be allowed without reserving budget. Does not create a reservation. Use at workflow start to decide strategy. For concurrency-safe budget locking, use cycles_reserve instead.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| subject | No | ||
| estimate | Yes | ||
| metadata | No | ||
| idempotencyKey | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| caps | No | |
| decision | Yes | |
| reasonCode | No | |
| retryAfterMs | No | |
| affectedScopes | No |
TDQS
A4.1/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description transparently states it does not create a reservation, aligning with annotations (destructiveHint=false, idempotentHint=true). It clarifies the read behavior beyond the annotations, ensuring the agent understands it is a non-destructive check.
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 very concise with two short sentences, front-loading the core purpose and usage guidelines. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a clear purpose, the description completely omits parameter semantics for a tool with 5 parameters (3 required) and nested objects. The agent lacks crucial information to correctly construct inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the JSON schema has no parameter descriptions. The description provides no explanation of any parameters (action, subject, estimate, metadata, idempotencyKey), leaving the agent to infer from schema alone.
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 clearly states it is a 'preflight check' to ask if an action is allowed without reserving budget, and explicitly says it does not create a reservation. This distinguishes it from sibling tools like cycles_reserve.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Use at workflow start to decide strategy' and directs to cycles_reserve for concurrency-safe budget locking, giving a clear when-to-use and when-not-to-use with an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cycles_extendExtend Reservation TTLAIdempotent
Extend the TTL of an active reservation. Use as a heartbeat for long-running operations to prevent the reservation from expiring. Does not change the reserved amount.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| metadata | No | ||
| extendByMs | Yes | ||
| reservationId | Yes | ||
| idempotencyKey | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| balances | No | |
| expiresAtMs | Yes |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations by stating that the reserved amount is unchanged and that it acts as a heartbeat, which aligns with the idempotent and non-destructive hints. It does not contradict annotations.
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 concise, with two sentences that front-load the core action and then provide additional context. No unnecessary words.
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?
The description provides the essential purpose and a key usage scenario, but lacks details on parameter semantics (e.g., extendByMs limits, idempotencyKey purpose) and does not mention whether the operation can fail or any side effects. The presence of an output schema partially mitigates return value documentation, but parameter documentation is entirely absent.
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?
With 0% schema description coverage, the description does not explain individual parameters (e.g., what extendByMs represents, what idempotencyKey is for) beyond the implied context from the main description. The agent must infer parameter meanings from the tool title and description.
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 clearly states the action ('Extend the TTL') and the resource ('active reservation'), and explicitly notes what it does not change, distinguishing it from sibling tools like cycles_reserve.
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?
Provides a specific use case ('heartbeat for long-running operations') and a clear behavior note ('does not change the reserved amount'), but does not explicitly contrast with alternatives like cycles_reserve or cycles_commit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cycles_get_reservationGet Reservation DetailsARead-only
Get details of a specific reservation by ID. Returns status, subject, action, reserved amount, timestamps, and affected scopes. Useful for debugging and monitoring long-running operations.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| reservationId | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| action | Yes | |
| status | Yes | |
| subject | Yes | |
| metadata | No | |
| reserved | Yes | |
| committed | No | |
| scopePath | Yes | |
| createdAtMs | Yes | |
| expiresAtMs | Yes | |
| finalizedAtMs | No | |
| reservationId | Yes | |
| affectedScopes | Yes | |
| idempotencyKey | No |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint: true, indicating safe read. The description adds value by detailing the returned fields (status, subject, action, etc.) and the debugging/monitoring use case, going beyond what annotations provide.
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 two sentences, front-loaded with purpose, and every word adds value. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter, existing annotations, and an output schema, the description covers purpose, returned data, and use case adequately.
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 coverage is 0% (no parameter descriptions), and the description only says 'by ID' without explaining how to obtain or format the reservationId. This is insufficient compensation for the lack of schema documentation.
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 clearly states the action 'Get details of a specific reservation by ID' and lists the specific attributes returned. The tool is distinct from siblings like cycles_list_reservations (listing all) and cycles_reserve (creating).
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?
The description notes that it is 'useful for debugging and monitoring long-running operations,' providing context. However, it does not explicitly exclude alternatives or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cycles_list_reservationsList ReservationsARead-only
List reservations, optionally filtered by status (ACTIVE, COMMITTED, RELEASED, EXPIRED) or subject fields. Useful for debugging stuck reservations or auditing budget usage.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| app | No | ||
| agent | No | ||
| limit | No | ||
| cursor | No | ||
| status | No | ||
| tenant | No | ||
| toolset | No | ||
| workflow | No | ||
| workspace | No | ||
| idempotencyKey | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| hasMore | No | |
| nextCursor | No | |
| reservations | Yes |
TDQS
A3.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, so the description adds minimal behavioral context. Does not disclose pagination (cursor/limit) or any other traits beyond the annotations.
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?
Two concise sentences with no wasted words. Front-loaded with action and resource, then filters, then use cases. Excellent structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description does not cover the majority of input parameters or their semantics. With 10 parameters, this is insufficient for an agent to select and invoke correctly without external knowledge.
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 0%. Description only mentions 'status' and 'subject fields' vaguely, but fails to explain 8 other parameters (app, agent, limit, cursor, etc.). Heavily under-documented for a 10-param tool.
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?
Description clearly states verb (List), resource (reservations), and optional filter (status). Immediately distinguishes from sibling tools by its read-only nature and specific use cases.
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?
Explicitly states use cases: 'debugging stuck reservations or auditing budget usage.' No explicit when-not-to-use, but context implies read-only. Sibling differentiation is indirect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cycles_releaseRelease ReservationAIdempotent
Release a reservation without committing. Use when an operation is cancelled, skipped, or fails before execution. Returns the released budget amount back to the pool.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | ||
| reservationId | Yes | ||
| idempotencyKey | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| balances | No | |
| released | Yes |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true and destructiveHint=false. The description adds value by explaining the effect (returns released budget amount back to pool) and the non-committing nature. It does not contradict annotations and provides context beyond them.
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 concise: two sentences, front-loaded with the primary action. Every sentence adds value, with no redundant or filler content.
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?
Given that an output schema exists (not shown), the description is largely complete: it states purpose, usage, and effect. It lacks error conditions or prerequisites (e.g., reservation must exist), but these are minor gaps. The sibling tools provide context.
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 0%, so the description must compensate. However, the description does not explain any parameters. While parameter names are somewhat self-explanatory, the lack of any parameter details leaves room for ambiguity, especially for the 'reason' parameter.
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 directly states that the tool releases a reservation without committing, clearly distinguishing it from cycles_commit and cycles_reserve. The verb 'Release' combined with 'without committing' precisely conveys the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The explicit instruction 'Use when an operation is cancelled, skipped, or fails before execution' provides clear when-to-use guidance. It also implies when not to use (e.g., when committing, use cycles_commit instead).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cycles_reserveReserve BudgetAIdempotent
Reserve budget before a costly operation (LLM call, tool invocation, external action). Returns a reservation_id to commit or release later. If decision is not ALLOW, do not proceed with the operation. For lightweight preflight checks without reserving, use cycles_decide instead.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ttlMs | No | ||
| action | Yes | ||
| dryRun | No | ||
| subject | No | ||
| estimate | Yes | ||
| metadata | No | ||
| gracePeriodMs | No | ||
| overagePolicy | No | ||
| idempotencyKey | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| caps | No | |
| balances | No | |
| decision | Yes | |
| reserved | No | |
| scopePath | No | |
| reasonCode | No | |
| expiresAtMs | No | |
| retryAfterMs | No | |
| reservationId | No | |
| affectedScopes | Yes |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and destructiveHint=false, so the description adds context about returning a reservation_id for later commit/release and the ALLOW/not ALLOW decision. However, it does not describe any potential side effects like holding budget or timeout behavior, which would be valuable for transparency.
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 two sentences, highly concise, with key information front-loaded. Every sentence earns its place: first defines the purpose, second provides usage scope and alternative.
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?
Given the tool's complexity (9 parameters, nested objects, enums, and a sibling set of 8 other tools), the description is too brief. It covers the core purpose and usage guidelines but lacks details on parameter semantics and expected behavior. The output schema exists, but the description should at least hint at what parameters are essential.
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?
The schema coverage is 0%, meaning the description does not explain any of the 9 parameters. While the schema itself defines constraints and enums, the description adds no guidance on how to set parameters like estimate, overagePolicy, or idempotencyKey. This is a significant gap.
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 clearly states the tool's action ('Reserve budget'), the resource ('before a costly operation'), and the outcome ('returns a reservation_id'). It also distinguishes from the sibling cycles_decide by explicitly naming it and explaining the difference (reserving vs. lightweight preflight check).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('before a costly operation') and when not to use it ('For lightweight preflight checks without reserving, use cycles_decide instead'). It also provides a clear instruction: 'If decision is not ALLOW, do not proceed.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
9 tool updates
v0.6.0- Changed
cycles_check_balance1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "balances": { + "items": { + "additionalProperties": false, + "properties": { + "allocated": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "debt": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "isOverLimit": { + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ] + }, + "overdraftLimit": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "remaining": { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + "reserved": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "scope": { + "type": "string" + }, + "scopePath": { + "type": "string" + }, + "spent": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "scope", + "scopePath", + "remaining" + ], + "type": "object" + }, + "type": "array" + }, + "hasMore": { + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ] + }, + "nextCursor": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "balances" + ], + "type": "object" +}
- Changed
cycles_commit1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "balances": { + "anyOf": [ + { + "items": { + "additionalProperties": false, + "properties": { + "allocated": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "debt": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "isOverLimit": { + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ] + }, + "overdraftLimit": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "remaining": { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + "reserved": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "scope": { + "type": "string" + }, + "scopePath": { + "type": "string" + }, + "spent": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "scope", + "scopePath", + "remaining" + ], + "type": "object" + }, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "charged": { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + "released": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "status": { + "type": "string" + } + }, + "required": [ + "status", + "charged" + ], + "type": "object" +}
- Changed
cycles_create_event2 fields changed- changed
Input schema / requiredPrevious value: -[ - "idempotencyKey", - "subject", - "action", - "actual" -]New value: +[ + "idempotencyKey", + "action", + "actual" +] - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "balances": { + "anyOf": [ + { + "items": { + "additionalProperties": false, + "properties": { + "allocated": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "debt": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "isOverLimit": { + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ] + }, + "overdraftLimit": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "remaining": { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + "reserved": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "scope": { + "type": "string" + }, + "scopePath": { + "type": "string" + }, + "spent": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "scope", + "scopePath", + "remaining" + ], + "type": "object" + }, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "charged": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "eventId": { + "type": "string" + }, + "status": { + "type": "string" + } + }, + "required": [ + "status", + "eventId" + ], + "type": "object" +}
- Changed
cycles_decide2 fields changed- changed
Input schema / requiredPrevious value: -[ - "idempotencyKey", - "subject", - "action", - "estimate" -]New value: +[ + "idempotencyKey", + "action", + "estimate" +] - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "affectedScopes": { + "anyOf": [ + { + "items": { + "type": "string" + }, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "caps": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "cooldownMs": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "maxStepsRemaining": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "maxTokens": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "toolAllowlist": { + "anyOf": [ + { + "items": { + "type": "string" + }, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "toolDenylist": { + "anyOf": [ + { + "items": { + "type": "string" + }, + "type": "array" + }, + { + "type": "null" + } + ] + } + }, + "type": "object" + }, + { + "type": "null" + } + ] + }, + "decision": { + "enum": [ + "ALLOW", + "ALLOW_WITH_CAPS", + "DENY" + ], + "type": "string" + }, + "reasonCode": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "retryAfterMs": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "decision" + ], + "type": "object" +}
- Changed
cycles_extend1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "balances": { + "anyOf": [ + { + "items": { + "additionalProperties": false, + "properties": { + "allocated": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "debt": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "isOverLimit": { + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ] + }, + "overdraftLimit": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "remaining": { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + "reserved": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "scope": { + "type": "string" + }, + "scopePath": { + "type": "string" + }, + "spent": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "scope", + "scopePath", + "remaining" + ], + "type": "object" + }, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "expiresAtMs": { + "type": "number" + }, + "status": { + "type": "string" + } + }, + "required": [ + "status", + "expiresAtMs" + ], + "type": "object" +}
- Changed
cycles_get_reservation1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "action": { + "additionalProperties": false, + "properties": { + "kind": { + "type": "string" + }, + "name": { + "type": "string" + }, + "tags": { + "anyOf": [ + { + "items": { + "type": "string" + }, + "type": "array" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "kind", + "name" + ], + "type": "object" + }, + "affectedScopes": { + "items": { + "type": "string" + }, + "type": "array" + }, + "committed": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "createdAtMs": { + "type": "number" + }, + "expiresAtMs": { + "type": "number" + }, + "finalizedAtMs": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "idempotencyKey": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "metadata": { + "anyOf": [ + { + "additionalProperties": {}, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + { + "type": "null" + } + ] + }, + "reservationId": { + "type": "string" + }, + "reserved": { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + "scopePath": { + "type": "string" + }, + "status": { + "type": "string" + }, + "subject": { + "additionalProperties": false, + "properties": { + "agent": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "app": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "dimensions": { + "anyOf": [ + { + "additionalProperties": { + "type": "string" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + { + "type": "null" + } + ] + }, + "tenant": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "toolset": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "workflow": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "workspace": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "type": "object" + } + }, + "required": [ + "reservationId", + "status", + "subject", + "action", + "reserved", + "createdAtMs", + "expiresAtMs", + "scopePath", + "affectedScopes" + ], + "type": "object" +}
- Changed
cycles_list_reservations1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "hasMore": { + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ] + }, + "nextCursor": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "reservations": { + "items": { + "additionalProperties": false, + "properties": { + "action": { + "additionalProperties": false, + "properties": { + "kind": { + "type": "string" + }, + "name": { + "type": "string" + }, + "tags": { + "anyOf": [ + { + "items": { + "type": "string" + }, + "type": "array" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "kind", + "name" + ], + "type": "object" + }, + "affectedScopes": { + "items": { + "type": "string" + }, + "type": "array" + }, + "createdAtMs": { + "type": "number" + }, + "expiresAtMs": { + "type": "number" + }, + "idempotencyKey": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "reservationId": { + "type": "string" + }, + "reserved": { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + "scopePath": { + "type": "string" + }, + "status": { + "type": "string" + }, + "subject": { + "additionalProperties": false, + "properties": { + "agent": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "app": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "dimensions": { + "anyOf": [ + { + "additionalProperties": { + "type": "string" + }, + "propertyNames": { + "type": "string" + }, + "type": "object" + }, + { + "type": "null" + } + ] + }, + "tenant": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "toolset": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "workflow": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "workspace": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "type": "object" + } + }, + "required": [ + "reservationId", + "status", + "subject", + "action", + "reserved", + "createdAtMs", + "expiresAtMs", + "scopePath", + "affectedScopes" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "reservations" + ], + "type": "object" +}
- Changed
cycles_release1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "balances": { + "anyOf": [ + { + "items": { + "additionalProperties": false, + "properties": { + "allocated": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "debt": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "isOverLimit": { + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ] + }, + "overdraftLimit": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "remaining": { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + "reserved": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "scope": { + "type": "string" + }, + "scopePath": { + "type": "string" + }, + "spent": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "scope", + "scopePath", + "remaining" + ], + "type": "object" + }, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "released": { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + "status": { + "type": "string" + } + }, + "required": [ + "status", + "released" + ], + "type": "object" +}
- Changed
cycles_reserve2 fields changed- changed
Input schema / requiredPrevious value: -[ - "idempotencyKey", - "subject", - "action", - "estimate" -]New value: +[ + "idempotencyKey", + "action", + "estimate" +] - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "affectedScopes": { + "items": { + "type": "string" + }, + "type": "array" + }, + "balances": { + "anyOf": [ + { + "items": { + "additionalProperties": false, + "properties": { + "allocated": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "debt": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "isOverLimit": { + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ] + }, + "overdraftLimit": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "remaining": { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + "reserved": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "scope": { + "type": "string" + }, + "scopePath": { + "type": "string" + }, + "spent": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "scope", + "scopePath", + "remaining" + ], + "type": "object" + }, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "caps": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "cooldownMs": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "maxStepsRemaining": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "maxTokens": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "toolAllowlist": { + "anyOf": [ + { + "items": { + "type": "string" + }, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "toolDenylist": { + "anyOf": [ + { + "items": { + "type": "string" + }, + "type": "array" + }, + { + "type": "null" + } + ] + } + }, + "type": "object" + }, + { + "type": "null" + } + ] + }, + "decision": { + "enum": [ + "ALLOW", + "ALLOW_WITH_CAPS", + "DENY" + ], + "type": "string" + }, + "expiresAtMs": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "reasonCode": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "reservationId": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "reserved": { + "anyOf": [ + { + "additionalProperties": false, + "properties": { + "amount": { + "type": "number" + }, + "unit": { + "type": "string" + } + }, + "required": [ + "unit", + "amount" + ], + "type": "object" + }, + { + "type": "null" + } + ] + }, + "retryAfterMs": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "scopePath": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "decision", + "affectedScopes" + ], + "type": "object" +}
9 tool updates
v0.2.4- First observed
cycles_check_balance - First observed
cycles_commit - First observed
cycles_create_event - First observed
cycles_decide - First observed
cycles_extend - First observed
cycles_get_reservation - First observed
cycles_list_reservations - First observed
cycles_release - First observed
cycles_reserve
TDQS
A4.2/5.0
Disambiguation5/5
Each tool has a clearly distinct purpose: reserve, commit, release, extend, decide (preflight), check balance, list, get details, and create event. No overlap or ambiguity.
Naming Consistency5/5
All tools follow a consistent 'cycles_verb_noun' pattern with snake_case, using clear verbs like reserve, commit, release, extend, decide, check_balance, list_reservations, get_reservation, create_event.
Tool Count5/5
9 tools is well-scoped for a budget/reservation lifecycle server, covering all necessary operations without being too few or too many.
Completeness5/5
The tool set covers the full lifecycle: reserve, commit, release, extend, preflight check, balance check, listing, detail lookup, and direct event creation. No obvious gaps.
Maintenance
ActivityActive
ResponsivenessNo issues
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Budget & cost control for AI agents — per-agent spend caps + rate limits before each call.
Agentic workflow budget approvals with usage receipts.
An effect gate for AI agents: at-most-once side effects, spend limits, and signed receipts.
See, price, and control every tool call your AI agents make: policy checks, cost, and audit tools.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceEnables AI coding agents to set budgets per task, check costs before expensive operations, and halt when budget is exhausted, with support for calibration and cloud sync.4MIT
- AlicenseNot gradedqualityCmaintenanceBudget & cost control for AI agents: hard per-agent spend caps, rate limits, idempotency, and human-in-the-loop approval — enforced before each LLM call, not after the invoice. One hosted MCP endpoint (no proxy or self-hosting), settled via x402 (USDC on Base).MIT
- FlicenseNot gradedqualityDmaintenanceEnables AI agents to track LLM costs, enforce budgets, compare models, and estimate expenses through simple tool calls.-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/runcycles/cycles-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server