AgentLedger
REMOTE · AIAGENTSCITY.COM
Meter, cap, and block AI agent spend before the provider is charged.
Available components
Last scanned (7 hours ago)
Scores higher than 84% of remote servers
Unreachable for 1 day in a row. Last reached 4 Nov 2026.
Category Finance and Payments
How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →
Endpoint Security11
- TLS not yet verified: we couldn't open a connection to check the certificate. View diagnostics → Unverified
- Authorisation not yet verified: we couldn't confirm whether this endpoint requires it. View diagnostics → Unverified
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- HSTS not yet verified: we couldn't read the response headers to check for it. View diagnostics → Unverified
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
Transport & Reachability0
- Transport check failed: declared streamable-http, but we couldn't connect to verify it. See how to fix → View diagnostics → Fail
Schema Quality & AI Usability0
- Schema not yet verified: we couldn't read the endpoint's schema, or could read only part of its tool list.Unverified
Stability & Change Management0
- Stability not yet verified: not enough scan history yet (needs a 30-day window).Unverified
Tool Coverage0
- Tool coverage not yet verified: we couldn't read the endpoint's tools, or could read only part of the list.Unverified
Tool Safety0
- Tool safety not yet verified: we couldn't read the endpoint's tools, or could read only part of the list.Unverified
Capabilities0
- Capabilities not yet verified: we couldn't read the endpoint's capabilities.Unverified
Unverified: 5 categories
Categories scored 0 because we could not verify them: authentication we do not have, an unreachable endpoint, or not enough scan history. We only credit what we can confirm.
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 5 Nov 26 0
- Endpoint reachability: reachable → unreachable ▼ security
- HSTS header: pass → unverified ▼ security
- Authorization: fail → unverified ▼ security
- Stability: pass → unverified ▼ security
- Tool safety: pass → unverified ▼ security
- TLS certificate: pass → unverified ▼ security
- Transport: pass → fail ▼ security
- Schema quality: 100 → unverified ▼ functional
- Tool coverage: 100 → unverified ▼ functional
- Capabilities: pass → unverified ▼ functional
- 28 Oct 26 +1
- Stability: fail → pass ▲ security
- 14 Oct 26 +3
- HSTS header: fail → pass ▲ security
- 13 Oct 26 +1
- Tool “ledger_start” rewrote its description, which is the text the model reads security
- 11 Oct 26 +3
- New tool “ledger_approval_decide”, which the server declares destructive security
- Tool “ledger_set_budget” rewrote its description, which is the text the model reads security
- Schema quality: 173 → 195 ▼ functional
- Server version: 4.0.11 → 0.4.7 functional
- New tool “ledger_approvals” functional
- New tool “ledger_wait_events” functional
- New tool “ledger_request_approval” functional
- “ledger_api_docs” reworded the description of “topic” cosmetic
- 4 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 52 to 56.
- 2 Oct 26 +1
- Tool “ledger_track” rewrote its description, which is the text the model reads security
- 28 Sept 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 5 Nov 2026 · Probed https://aiagentscity.com/mcp/
TLS unreached
Background: What to check on a remote MCP endpoint →
DNSSEC insecure
Validation of aiagentscity.com. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| com. | present | 19718 | 13 | Verified |
| aiagentscity.com. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication Inconclusive
We could not reach the endpoint well enough to judge its authorisation posture.
| Result | Inconclusive |
|---|
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://aiagentscity.com/mcp/ | Unreachable | ||
| http (plaintext) | http://aiagentscity.com/mcp/ | HTTPS enforced |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
ledger_alerts Agent Budget Alerts ~104
Alert history for an agent: budget warnings (80% threshold) and spending spikes. Requires a credential: either the agent's own agent_secret or its workspace's workspace_key (same rule as GET /v1/alerts).
| Name | Type | Req | Description |
|---|---|---|---|
| agent_id | string | yes | unique agent identifier |
| agent_secret | string | – | the agent's own secret (either this or workspace_key) |
| workspace_key | string | – | the owning workspace's key (either this or agent_secret) |
Structured output declared, but exposes no named fields.
No examples provided.
ledger_api_docs AgentLedger API Docs ~106
Self-serve documentation for AgentLedger — quickstart, MCP tools, REST endpoints, budget caps, error codes, and idempotency usage, as markdown.
| Name | Type | Req | Description |
|---|---|---|---|
| topic | string | – | "quickstart" | "mcp" | "rest" | "budget" | "errors" | "idempotency" | "metering" | "events" | "all" (default "" == "all"). Unknown topics fall back to the full docs. |
Structured output declared, but exposes no named fields.
No examples provided.
ledger_approval_decide Approve or Deny a Spend Request ~166
Approve or deny a pending spend permit — workspace owner only. The agent's own agent_secret can REQUEST an approval but can never decide one: a credential that can approve its own requests is not a control. decision must be 'approve' or 'deny'; only pending permits can be decided. An approved permit is consumed by the agent's next ledger_track within its amount — it is a one-shot exception, not a raised cap.
| Name | Type | Req | Description |
|---|---|---|---|
| agent_id | string | yes | the agent that requested the permit |
| approval_id | string | yes | the apr_ id from ledger_request_approval / ledger_approvals |
| decision | string | yes | 'approve' or 'deny' |
| workspace_key | string | yes | the key of the workspace that owns the agent |
Structured output declared, but exposes no named fields.
No examples provided.
ledger_approvals List Spend Approvals ~103
List spend-approval permits — yours, or your whole workspace's.
| Name | Type | Req | Description |
|---|---|---|---|
| agent_id | string | – | list this agent's permits (needs agent_secret or workspace_key) |
| agent_secret | string | – | the agent's own secret (agent view) |
| state | string | – | optional filter: pending | approved | denied | consumed | expired |
| workspace_key | string | – | the owning workspace's key — lists ALL its agents' permits when given alone |
Structured output declared, but exposes no named fields.
No examples provided.
ledger_check_spend Check Before Spending ~285
Ask BEFORE you spend: may this agent spend this much right now? Returns allowed (true/false), a stable reason code (within_budget, over_monthly_cap, over_daily_cap, over_monthly_token_cap, over_daily_token_cap, no_budget_set, unpriced_model), a one-line message, the cost estimate, the price used (with its source and as_of date) and every budget window with cap, spent and remaining. Same decision the /proxy/{provider} gate enforces. Read-only: nothing is recorded or reserved, so record the spend with ledger_track afterwards. Give exactly one spend shape: amount_cents (any rail, e.g. an x402 purchase), OR model with tokens_in/tokens_out.
| Name | Type | Req | Description |
|---|---|---|---|
| agent_id | string | yes | the agent that would spend |
| agent_secret | string | – | the agent's own secret (either this or workspace_key) |
| amount_cents | – | – | the spend in cents, if you already know it |
| model | string | – | model id to price from tokens (instead of amount_cents) |
| tokens_in | integer | – | expected input tokens (with model) |
| tokens_out | integer | – | expected output tokens, e.g. your max_tokens (with model) |
| workspace_key | string | – | the owning workspace's key (either this or agent_secret) |
Structured output declared, but exposes no named fields.
No examples provided.
ledger_examples AgentLedger Recipes ~51
Complete, runnable Python recipe for a common AgentLedger integration pattern.
| Name | Type | Req | Description |
|---|---|---|---|
| pattern | string | yes | "python_tracking" | "budget_enforcement" | "weekly_report" | "retry_safe_writes" |
Structured output declared, but exposes no named fields.
No examples provided.
ledger_price Price a Call Before You Make It ~243
What will this call cost? Priced from the same table the caps use. Exists because ledger_track requires the CALLER to supply amount_cents, so an agent whose spend is capped could under-report its own cost and stay under the cap. This returns the number the enforcement path would use, so an agent can report honestly (and plan before it spends). Cost = (tokens_in * in_rate + tokens_out * out_rate) / 1_000_000. If the model has cache rates, the standard in-rate is used, which is the conservative direction for a spend cap. Every price carries the source it came from and the date it was read, and `verified: false` means the number was NOT read off the provider's own pricing page. Treat an unverified price as an estimate, not a measurement.
| Name | Type | Req | Description |
|---|---|---|---|
| model | string | yes | the model id you are about to call (e.g. gpt-4o, claude-sonnet-4) |
| tokens_in | integer | – | expected input tokens |
| tokens_out | integer | – | expected output tokens, e.g. your max_tokens |
Structured output declared, but exposes no named fields.
No examples provided.
ledger_proxy_attach Attach the Budget-Enforcing Proxy ~211
Point your provider traffic at the proxy so budget caps are enforced BEFORE the provider is contacted, instead of being reported afterwards. This closes the gap where the brake was unreachable from MCP: an agent connected over MCP could record spend (ledger_track) but nothing could refuse a call. With this, the cap is enforced on every LLM call. Returns the base_url to use, the two headers to send, and the exact change for the OpenAI and Anthropic SDKs. Your provider credential is NOT part of this: it stays in Authorization / x-api-key and is only forwarded, never stored.
| Name | Type | Req | Description |
|---|---|---|---|
| agent_id | string | yes | the agent whose budget the proxied calls are billed to |
| agent_secret | string | – | the agent's own secret (either this or workspace_key) |
| provider | string | – | which upstream to proxy: openai or anthropic |
| workspace_key | string | – | the owning workspace's key (either this or agent_secret) |
Structured output declared, but exposes no named fields.
No examples provided.
ledger_report Agent Spend Report ~137
Spend report for an agent over a rolling window. Returns total spend, breakdown by rail and by service, budget status (ok/warning/exceeded), detected anomalies, and entry count. Requires a credential: either the agent's own agent_secret or its workspace's workspace_key (same rule as GET /v1/report).
| Name | Type | Req | Description |
|---|---|---|---|
| agent_id | string | yes | unique agent identifier |
| agent_secret | string | – | the agent's own secret (either this or workspace_key) |
| days | integer | – | report window in days (default 30) |
| workspace_key | string | – | the owning workspace's key (either this or agent_secret) |
Structured output declared, but exposes no named fields.
No examples provided.
ledger_request_approval Request Spend Approval ~257
Ask your workspace owner for a one-shot spend exception before a ledger_track that the cap would refuse. Creates a pending permit for exactly amount_cents on the given service. The owner (a human, or a supervisor agent holding the workspace_key) approves or denies it with ledger_approval_decide. An APPROVED permit is consumed by the next ledger_track for this agent whose amount fits inside it — the budget cap itself does not change. Permits expire after 1 hour undecided. Poll with ledger_approvals to see the decision. Claiming a brand-new agent_id requires workspace_key; otherwise pass the agent's agent_secret.
| Name | Type | Req | Description |
|---|---|---|---|
| agent_id | string | yes | the agent asking for the exception |
| agent_secret | string | – | the agent's own secret (either this or workspace_key) |
| amount_cents | integer | yes | the spend to be approved, in cents |
| reason | string | – | why, one line — shown to the approver |
| service | string | yes | what the money is for (e.g. "openai:gpt-5 batch eval") |
| workspace_key | string | – | the owning workspace's key (either this or agent_secret) |
Structured output declared, but exposes no named fields.
No examples provided.
ledger_revoke_secret Revoke Agent Secret ~129
Invalidate an agent_id's agent_secret WITHOUT deleting its spend history. Use when a credential may have leaked, or to stop an agent writing. Subsequent writes to that agent fail with agent_secret_mismatch until you rotate a new secret in. The agent_id stays claimed, so no other workspace can claim it and inherit the ledger. Requires the workspace_key that owns agent_id. Returns {"agent_id", "revoked": True, "_note"}, or {"error", "error_code"}.
| Name | Type | Req | Description |
|---|---|---|---|
| agent_id | string | yes | – |
| workspace_key | string | yes | – |
Structured output declared, but exposes no named fields.
No examples provided.
ledger_rotate_secret Rotate Agent Secret ~160
Mint a NEW agent_secret for an agent_id your workspace already owns, invalidating the old one. Use this to RECOVER an agent whose secret was lost: the previous credential stops working immediately. Requires the workspace_key that owns agent_id — an agent's own agent_secret cannot rotate itself, because a leaked agent credential must not be able to lock its real owner out. Unlike ledger_track this never claims a new agent_id: an unknown id returns agent_not_claimed. The new secret is returned ONCE. Store it before you drop the response. Returns {"agent_id", "agent_secret", "_note"}, or {"error", "error_code"}.
| Name | Type | Req | Description |
|---|---|---|---|
| agent_id | string | yes | – |
| workspace_key | string | yes | – |
Structured output declared, but exposes no named fields.
No examples provided.
ledger_set_budget Set Agent Budget ~351
Set spending caps for an agent. Warns at 80%, blocks spend when exceeded — enforced: a ledger_track call that would cross the cap is rejected. Dollar caps (monthly_cents/daily_cents) and token caps (monthly_tokens/ daily_tokens) are independent dimensions: dollar caps only cover non-"tokens" rails, token caps only cover rail="tokens" bookkeeping rows (tokens_in/tokens_out). Set both if the agent uses both. Monthly cap is required; the rest are optional (0 = no limit). Overwrites any existing budget for the agent — with one rule: raising or removing an existing cap requires the workspace_key. An agent_secret can tighten its own caps but never loosen them; to grow an allowance the agent asks its owner (see ledger_request_approval). Claiming a brand-new agent_id requires your workspace_key; that first call mints an agent_secret (returned once — save it); later calls for that agent_id must pass the agent_secret back (no workspace_key needed again).
| Name | Type | Req | Description |
|---|---|---|---|
| agent_id | string | yes | unique agent identifier |
| agent_secret | string | – | required for every call after the first for this agent_id |
| daily_cents | integer | – | daily spending cap in cents (0 = no daily cap) |
| daily_tokens | integer | – | daily token-burn cap (0 = no cap) |
| monthly_cents | integer | yes | monthly spending cap in cents |
| monthly_tokens | integer | – | monthly token-burn cap (0 = no cap) |
| workspace_key | string | – | required when claiming a brand-new agent_id; not needed once the agent_id has been claimed |
Structured output declared, but exposes no named fields.
No examples provided.
ledger_start Start a Workspace ~264
Get a FREE AgentLedger workspace with no credential and no arguments — the MCP equivalent of opening POST /start in a browser. Call this FIRST if you have no credentials yet. Every other tool here (ledger_track, ledger_set_budget, ledger_report, ledger_alerts) needs a workspace_key or an agent_secret, so a caller arriving with neither must start here or it has nowhere to go. Takes NO arguments on purpose: the goal is zero friction. It returns a `workspace_key` (shown exactly once — it cannot be re-revealed, so store it before continuing) which you then send as `workspace_key` on your first ledger_track for a NEW agent_id. That first write returns the agent's own `agent_secret`, which authenticates every write after it. The free tier includes every rail, enforced budget caps, alerts, reports and the MCP server, capped at 3 agents per workspace. Minting is rate-limited per caller IP, the same limit the human door uses. Prefer to pay? POST /v1/billing/x402 with a wallet-signed payment needs no human and buys 24h of Pro (agent allowance per the live pass tier — see /pricing.md).
Input schema present but exposes no named parameters.
Structured output declared, but exposes no named fields.
No examples provided.
ledger_track Track Agent Spend ~438
Record a spend entry for an AI agent on any payment rail, with optional token counts. Claiming a brand-new agent_id requires your workspace_key (get one via x402 at POST /v1/billing/x402 — no human, no login — or at /start). That first call mints an agent_secret and returns it in the response — save it, every later call for that same agent_id must pass it back (no workspace_key needed again) or the write is rejected. Amounts are capped at $100,000/entry and must be >= 0. If a budget is set for this agent, an entry that would cross the monthly/daily cap is blocked, not just logged. Caps here bind the AMOUNT YOU REPORT — a caller that lies to amount_cents lies to the cap. The only enforcement against real spend is routing the provider call through the /proxy/{provider} rail, which prices from the provider's own usage block. Include tokens_in/tokens_out + model on every LLM call so token burn shows up in the /v1/tokens report.
| Name | Type | Req | Description |
|---|---|---|---|
| agent_id | string | yes | unique agent identifier (e.g. "research-agent-v2") |
| agent_secret | string | – | required for every call after the first for this agent_id |
| amount_cents | integer | yes | spend amount in cents (100 = $1.00), 0-10000000 |
| model | string | – | model name (e.g. "gpt-4o") — token burn is reported per model |
| rail | string | yes | payment rail used — one of "mpp", "x402", "api_key", "manual" |
| service | string | yes | what was purchased (e.g. "search_query", "data_export") |
| tokens_in | integer | – | prompt tokens consumed (0 if unknown) |
| tokens_out | integer | – | completion tokens consumed (0 if unknown) |
| workspace_key | string | – | required when claiming a brand-new agent_id; not needed once the agent_id has been claimed |
Structured output declared, but exposes no named fields.
No examples provided.
ledger_wait_events Wait for Agent Events ~537
Long-poll an agent's event feed — how an agent with no public URL receives alerts. Webhooks (POST /v1/webhooks) push events to a URL you own; an agent on stdio MCP cannot host one, so it waits here instead. Call this in a loop: the call holds open up to `timeout` seconds (max 30) and returns when events arrive or the wait lapses. `consumer_id` names this consumer durably — pick a stable one (e.g. "claude-code-main") and reuse it. Each call returns a `cursor`; pass it back on your next call once you have processed that batch — that is the ack. To get restart redelivery, also pass `client_instance` (your process id or any per-boot token) and `client_started` (when your process booted): when the pair changes, events that were served but never acked come back with `redelivered: true`, so nothing is lost to a crash between serve and process. (The stdio MCP server supplies its own pid/started automatically — hosted callers must opt in because the gateway cannot see the client's process.) Each event is an envelope: id (deterministic — dedupe on it), kind (alert.raised | budget.warning | budget.exceeded | anomaly.detected), summary, context (agent_id, alert_type, timestamp), alerts_since_last_write (how many alerts are stacked up since the agent's last spend write — use it to throttle escalation), redelivered. Requires a credential: either the agent's own agent_secret or its workspace's workspace_key (same rule as GET /v1/agents/{agent_id}/events/wait).
| Name | Type | Req | Description |
|---|---|---|---|
| agent_id | string | yes | unique agent identifier |
| agent_secret | string | – | the agent's own secret (either this or workspace_key) |
| client_instance | string | – | your process identity (e.g. pid or per-boot token) — enables restart redelivery |
| client_started | string | – | when your process booted — paired with client_instance |
| consumer_id | string | yes | durable name for this consumer (1-64 chars, [A-Za-z0-9._-]) |
| cursor | – | – | line offset you have processed through (omit to continue) |
| name | string | – | optional label for this consumer instance |
| timeout | – | – | seconds to hold the call open (default 5, max 30) |
| workspace_key | string | – | the owning workspace's key (either this or agent_secret) |
Structured output declared, but exposes no named fields.
No examples provided.
read_skill Read Skill ~50
Read a product skill file by its skill:// URI.
| Name | Type | Req | Description |
|---|---|---|---|
| uri | string | yes | e.g. skill://<product>/<skill-name>/SKILL.md Get valid URIs from `skills_list_tool`. |
Structured output declared, but exposes no named fields.
No examples provided.
skills_list_tool Skills List Tool ~51
List this product's skills. Each entry carries the SKILL.md URI, its name and description, verbatim frontmatter, and a per-file sha256 manifest. Read a body with `read_skill`.
Input schema present but exposes no named parameters.
Structured output declared, but exposes no named fields.
No examples provided.
How do I install the AgentLedger MCP server?
AgentLedger is a hosted endpoint at https://aiagentscity.com/mcp/, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
remote · aiagentscity.com
claude mcp add --transport http entradox-agent-ledger 'https://aiagentscity.com/mcp/'
What is the AgentLedger MCP server?
AgentLedger is an MCP server listed in the public MCP registry as io.github.entradox/agent-ledger. Meter, cap, and block AI agent spend before the provider is charged. This page covers its hosted endpoint (https://aiagentscity.com/mcp/).
Is the AgentLedger MCP server safe to use?
AgentLedger scores 81 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the AgentLedger MCP server expose?
AgentLedger exposes 18 tools: ledger_rotate_secret, ledger_revoke_secret, ledger_track, ledger_set_budget, ledger_report, and 13 more. Their descriptions and schemas cost roughly 3,643 tokens of context every time the server is loaded.
Does the AgentLedger MCP server require authentication?
Its publisher declares no required credentials for AgentLedger. We have not been able to confirm that against the live endpoint, and a server can require authorisation without declaring it here.
Is the AgentLedger MCP server still maintained?
AgentLedger is still listed in the MCP registry, though our most recent checks did not reach this channel. We last reached this channel on 4 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.