read_workspace_api

MCP server · The governed passthrough

Reads one workspace route under your own grant: GET only, and it takes no method argument at all. Run describe_workspace_api first for the exact path and shape. A path outside the parity manifest is refused outright, and anything that governs agents themselves (spend, keys, grants, members, payment) is refused with the reason. JSON in, JSON out: no downloads, no streaming.

What it needs

Argument	Type	Required	Description
path	string	Yes
query	any	No

What it returns

The route's own JSON response with the status it answered, and which route the call resolved to.

Credential

An app session token, from an authenticated app.ax1om.ai session. Call it with only an API key and you get a plain refusal saying so, rather than a confusing 401.

Network call: yes. The full credential split is on authentication.

Example call

Most readers never write the protocol themselves: the agent does, once the server is connected. Both forms are the same call.

Ask your agent

prompt

Use the ax1om MCP server.
Call read_workspace_api: reads one workspace route under your own grant: GET only, and it takes no method argument at all.

JSON-RPC

POST https://api.ax1om.ai/mcp

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "read_workspace_api",
    "arguments": {}
  }
}

The arguments object is whatever this tool's own input schema declares. An MCP client reads that schema from the server, so it is the server that answers for the exact shape rather than this page.

Notes

• It is permission parity rather than gate removal: the call runs as you, so your role, your plan entitlements and the agent-compute consent gate all still apply, and an agent can do nothing here that you could not do in the app.