antigravity-desktop-live-quota-mcp
Related Servers
Alternatives to antigravity-desktop-live-quota-mcp
No user-submitted related servers found.
Related Servers
- AlicenseBqualityCmaintenanceThis MCP server gives AI coding agents continuous self-awareness of their remaining Google Antigravity quota across both 5-hour rolling and weekly entitlement windows, plus live session token consumption and context pressure for the active conversation. It enables agents to probe headroom between tool steps, checkpoint work gracefully before hitting rate limits, and govern subagent model choice — all at zero LLM token cost.3MIT
- AlicenseNot gradedqualityCmaintenanceEnables AI agents to query live 5-hour and 7-day quota limits, per-model allowances, and user plan tiers from the local Google Antigravity 2.0 Language Server. It also forecasts planned task consumption and self-learns from real pre/post measurements, isolating parallel-chat noise.7 npmMIT
- AlicenseNot gradedqualityBmaintenanceEnables users to connect Google Gemini 4 High (Argon Extended Thinking) from Gemini Web into Google Antigravity via MCP tools, a /kg4 slash command, and an OpenAI-compatible proxy for chat completions.6MIT
- AlicenseAqualityCmaintenanceLets an AI agent check its own Claude and Codex usage limits — used percentages and exact reset times for session and weekly windows — so it can plan long-running work around resets instead of dying mid-task. It reads local, credential-free sources by default, always reports which source answered, and ships a hook that pushes quota state into context automatically.1MIT
- FlicenseNot gradedqualityDmaintenanceEnables local AI agents to generate code and interact with Google Antigravity (Gemini Pro) via MCP, consuming zero API tokens.-
- AlicenseAqualityCmaintenanceEnables AI agents to monitor and debug browser runtime errors, console logs, and page diagnostics in real time via a Chrome extension and local MCP server.4MIT
TDQS
Scored across 3 tools
Each tool targets a clearly distinct object: quota data (get_quota_status), the UI badge element (reinject_badge), and the server process itself (get_instance_status). There is no plausible way to confuse one for another.
All three names are snake_case verb_noun constructions (get_*, reinject_*), and the nouns map directly to the resource being acted on. Minor variation in verb choice (reinject vs get) is semantically meaningful, not inconsistent.
Three tools is on the thin side, but this is a narrow single-purpose server (live quota monitoring for a desktop app) and each tool covers a genuinely separate concern. Nothing is redundant or filler.
The surface covers querying quota, refreshing the badge, and inspecting instance leadership, but the badge lifecycle is one-directional — there is no way to hide/disable the badge or configure its refresh behavior, and no tool to reset or re-acquire leadership. These are notable gaps an agent would hit when trying to fully manage the display state.