Connect an agent
The server is a StreamableHTTP MCP endpoint with full OAuth 2.1 / dynamic client registration discovery — a client points at the URL and the handshake is automatic. In an MCP client config it looks like:
mcp config{
"mcpServers": {
"byteshift": {
"url": "https://mcp.byteshift.com/mcp"
}
}
}On first use the client walks the OAuth flow, you approve it, and it receives an org-scoped token. Every tool call passes that token through to the API, so tenancy is enforced exactly once, in one place — no tool takes an organization parameter.
The tools
Tools are intent-shaped, not a 1:1 mirror of endpoints. The entry point is list_services — a cross-signal inventory sorted unhealthiest first. From there an agent goes wide, then narrows, then drills in:
- Explore —
log_stats,search_logs,get_log;trace_stats,find_traces,get_trace;list_metrics,get_metric. - Cost —
cost_statsfor billed spend from the ledger, with coverage so empty never masquerades as zero. - AI —
ai_usage,ai_traces,ai_sessions,ai_cost. - Data —
list_data_assets,data_lineage. - Monitors (write) —
list_monitors,ensure_monitor,set_monitor_state,delete_monitor.
Every stats and catalog tool scopes to one service and takes the same filter vocabulary as the API — so an agent gets per-service trends, not just the global picture.
Reading and acting
Read tools carry a read-only hint. The monitor verbs are the first write surface, marked readOnlyHint: false— and consent is the host's job, keyed off that annotation. byteshift's own Ask agent, for instance, holds a write tool as a proposal and renders a confirmation card with a current→proposed diff before anything runs.delete_monitor is the one destructive verb and is flagged as such.
The same loop, everywhere
This is not a side channel. The console's Ask feature drives this exact MCP server as a client, so a tool shipped for agents is a capability the product gains the same day. What your agent can do through MCP is what byteshift can do for you in the console.