Agent access (MCP)

Mint an agent credential

1. Go to Agent access → Create agent (owner / admin only).
2. Give it a name, then choose its capabilities — from target discovery (database.read, server.read, kube.read, app.read) and read-only queries (database.query_read) to live-resource observability (resource.read), read-only API access (kube.proxy, app.connect), server commands (agent.host_exec), security review (security.read) and JIT access (access.request). Pick only what the agent needs.
3. Database access is read-only unless you say otherwise. Ticking database.query_maintenance additionally allows ANALYZE / VACUUM, and database.query_write allows write and DDL statements. Both are still subject to guardrails and recorded, and neither can exceed what the creating user is allowed to do.
4. Pick the allowed targets — databases, servers, apps and clusters. The agent can only ever reach the targets you select here, nothing else in the workspace.
5. Set an expiry (7 / 30 / 90 / 180 / 360 days). Agents are always time-boxed.
6. On save you get a one-time token, the MCP endpoint URL, and a ready-to-paste client config. The token is shown once — store it safely.

Connect a client

Clients that support remote (Streamable HTTP) MCP — Cursor, Claude Code — take the URL + bearer token directly:

{
  "mcpServers": {
    "subnomic": {
      "url": "https://app.subnomic.com/mcp",
      "headers": { "Authorization": "Bearer subnomic_live_agt_…" }
    }
  }
}

For a stdio-only client, bridge it with mcp-remote:

{ "mcpServers": { "subnomic": {
  "command": "npx",
  "args": ["mcp-remote", "https://app.subnomic.com/mcp",
           "--header", "Authorization: Bearer subnomic_live_agt_…"]
}}}

Verify the endpoint quickly before wiring a client in:

curl -s https://app.subnomic.com/mcp \
  -H "Authorization: Bearer subnomic_live_agt_…" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

What the agent can do

The exact tools an agent sees depend on the capabilities you granted. Unless you tick a maintenance or write capability above, they are all read-only or observational — the lifecycle tools appear only with resource.write. Across the families:

• Discover — list the databases, servers, clusters and apps the credential is scoped to (list_targets, list_servers, list_kube_targets, list_app_targets).
• Query data — explore schemas and run SQL (list_schemas, list_tables, describe_table, table_ddl, query_database). Reads always work; maintenance (ANALYZE / VACUUM) and write/DDL statements are refused unless you granted database.query_maintenance or database.query_write.
• Observe infrastructure — list and describe live Kubernetes & Docker resources, tail logs, read events and host metrics (kube_list_resources, kube_describe, kube_events, kube_logs, docker_list, docker_inspect, docker_logs, host_metrics, host_overview).
• Read-only API & host — issue read-only Kubernetes API GETs, internal-app HTTP GETs and guardrailed shell commands (kube_get, app_http_get, run_command).
• Investigate — one-shot structured reports: investigate a resource, diagnose a cluster, find crash-looping pods, summarise recent changes (investigate_resource, diagnose, crashloop_report, recent_changes).
• Security review — scored audits of RBAC, secrets, internet exposure and workload hardening (rbac_audit, secret_audit, exposure_audit, workload_security_audit, security_review).
• Audit & access — search the activity log and file a just-in-time access request (search_activity, request_access).
• Change things — with resource.write, the full object lifecycle on Kubernetes and Docker: apply a manifest or create a swarm service, scale, restart, swap an image, edit labels, drain a node, delete (kube_apply, kube_delete, kube_patch_meta, kube_drain, rollout_restart, rollout_scale, rollout_set_image, docker_apply, docker_delete, docker_start, docker_stop, docker_set_image, container_restart, container_scale).
• Operate the workspace — the records rather than the infrastructure: follow or cancel tasks, run and follow workflows, manage recurring scheduled tasks, read and resolve alerts, declare / update / annotate incidents, and post to a chat channel (list_tasks, task_status, run_workflow, create_scheduled_task, list_alerts, declare_incident, post_to_channel, …). Each needs its own capability; the scheduled-task writes additionally require the agent to be granted, because a schedule is standing permission to run commands on a host.

Every call is guardrail-evaluated and recorded — query tools as a replayable database session, the rest in the activity log, all attributed to the agent. A call a guardrail would deny — or one needing human approval — is refused: an agent has no interactive-approval path.

Permissions

mcp.read views credentials; mcp.manage mints and revokes them. Both are owner/admin-level by default. A credential's own scopes can never exceed the permissions of the admin who minted it.