Skip to main content
Glama
kensaurus

Mushi-Mushi

by kensaurus
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Spend-down status of Cursor keys

get_spend_down_status
Read-onlyIdempotent

Shows a project's Cursor key spend-down status: mode, credit expiry, window state, daily fix usage, stop-loss, scoreboard, and review follow-ups. Use it to check if expiring credits are being used.

Instructions

For each Cursor key this project can use, show spend-down mode (ADR 0028): whether it is on, when the credits expire, the window state (off | not_started | active | expired | key_unusable), fixes started today out of the daily limit, the apps the key pays for that this project can see (each with its stop-loss state: paused when, over its spend-down runs of the last 14 days with 20+ samples, the 95% Wilson bound puts its Opus merge rate under 20%, hold rate over 35% or no-PR share over 50%; a paused app still gets 1 probe fix a day), a count of its other apps, the last 7 days' scoreboard (key-wide totals; per app × model × day rows for visible apps: runs, PRs, no-PR verdicts, other failures, Opus merge / fix_first / hold, merged, latest review cost per PR, merge and mergeable yield), and what the last worker tick did. Returns { keys: [{ id, label, keyHint, scope, enabled, creditsExpireAt, model, dailyLimit, windowDays, state, startsAt, dispatchedToday, remainingToday, projects: [{ id, name, canResume, stopLoss }], otherApps, projectsNote, stopLossNote, scoreboard: { days, since, totals, rows } | null, scoreboardNote, lastRunAt, lastSummary }], reviewFollowups: { days, dispatched, finished, pushed, noChange, verdictsAfter: { merge, fix_first, hold }, awaitingReview, conversionRate, skipped, apps } | null } — reviewFollowups (ADR 0032) is what sending fix_first PRs back to an agent with the Opus findings produced in the last 7 days, over the apps you can access. Read-only. Use to see whether expiring Cursor credits are being used and what they produce; use set_byok_spend_down to change it.

Input Schema

NameRequiredDescriptionDefault
projectIdYesProject id (`project_id` is accepted too.)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.17

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint/idempotentHint/openWorldHint=false, and the description's 'Read-only' merely repeats that. It adds some domain context (ADR 0028, stop-loss probe behavior, credit expiry) that isn't in annotations, but most of the text is return-field exposition rather than operational behavior. Credit for the ADR/stop-loss nuance, but limited additional behavioral disclosure.

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

Conciseness2/5

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

The description is a massive run-on that describes the return shape twice — first in dense prose and then again as an inline JSON shape — which is redundant. It is not front-loaded for quick scanning; the key action ('read-only status of Cursor keys') is buried in field enumeration.

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?

With no output schema, the description carries the full burden of return-shape disclosure and it does so exhaustively, including the reviewFollowups structure and nullability notes. An agent knows exactly what it will get back.

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?

Only one parameter (projectId) and schema coverage is 100%, so the schema already documents it fully, including the project_id alias. The description adds no syntax or format guidance for projectId, so baseline 3 is appropriate.

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?

States a specific verb+resource (get spend-down status per Cursor key) and enumerates exactly what is shown: spend-down mode, expiry, window state, dispatched-today counts, per-app stop-loss, scoreboard, and last tick. It is clearly distinct from set_byok_spend_down, which it names.

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 'Use to see whether expiring Cursor credits are being used and what they produce; use set_byok_spend_down to change it,' giving both the read use case and the alternative for mutation. No explicit 'when not to use' beyond that, so a 4.

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

Deploy Server

Other Tools