opencode-balance-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OPENCODE_GO_AUTH_COOKIE | Yes | Your OpenCode auth cookie (starts with Fe26.2**) | |
| OPENCODE_GO_WORKSPACE_ID | Yes | Your OpenCode workspace ID (e.g., wrk_xxx) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| query_go_usageA | Query OpenCode Go subscription quota: rolling (5h) / weekly / monthly usage percent, estimated USD spent and reset countdown. No arguments needed; credentials are provided at startup via CLI args (--workspace-id / --auth-cookie) or env vars. |
| query_zen_balanceA | Query OpenCode Zen prepaid balance (pay-as-you-go): balance in 1e-8 USD units (negative = credit), formatted USD, and auto-reload settings. No arguments needed; credentials are provided at startup via CLI args (--workspace-id / --auth-cookie) or env vars. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
The two tools query distinct resources: one for Go subscription quota and one for Zen prepaid balance. Their descriptions clearly differentiate the data returned (usage percentages vs. balance in USD units), making confusion unlikely.
Both tool names follow the exact same pattern: 'query_' prefix followed by the resource type ('go_usage' and 'zen_balance'). This is fully consistent and predictable.
With only two tools, the surface is minimal, but the server's scope is narrowly defined as querying two distinct balance types. The count feels appropriate given the focused purpose, though slightly thin if broadenability was expected.
The server covers the two core balance query operations for its domain. Missing a combined query or historical data are minor gaps that agents can work around, but the essential read operations are present.