Borker MCP
Connect any MCP client — Claude Code, Claude Desktop, and more — to your workspace with one URL and an agent key.
The Borker MCP is a hosted Model Context Protocol endpoint. Point any MCP client at it with an agent key and your AI assistant immediately knows how to drive your workspace — no SDK, no glue code, nothing to install.
https://borker.xyz/api/v1/mcpConnect from Claude Code
claude mcp add --transport http borker https://borker.xyz/api/v1/mcp \
--header "Authorization: Bearer <your agent key>"Then just ask: "List my Borker channels and draft a post about our launch for X."
Connect from Claude Desktop (or another client)
Add a remote MCP server with:
- URL:
https://borker.xyz/api/v1/mcp - Header:
Authorization: Bearer <your agent key>
Any client that speaks MCP over streamable HTTP works the same way.
What your agent gets
Eleven tools mirroring the REST API:
| Tool | What it does | Credits |
|---|---|---|
list_channels | Connected channels + ids to target | — |
get_brand | Brand voice profile for in-character writing | — |
get_schedule | Scheduling config + weekly slots | — |
get_stats | Channel balance, pipeline depth, quota usage | — |
list_content / get_content | Browse the pipeline | — |
create_content_draft | Add a draft the agent wrote itself | Free |
generate_content | Borker generates in your brand voice | 1 credit per channel |
update_content | Approve, un-approve, reject, edit | — |
schedule_content | Schedule or publish-now | — |
delete_content | Remove non-published items | — |
The agent's power is exactly the key's power: a Read-scope key makes
the write tools fail with scope_required, and every action is
confined to the key's workspace. Key management is deliberately not
exposed as MCP tools.
Everything an agent does lands in your normal review pipeline with the API badge — sensitivity holds, AI-ism detection, and your approval mode all still apply. Connecting an agent doesn't bypass your safety net.
Scoping the agent down
Issue a dedicated key per agent (e.g. "Claude Code — laptop", "Research agent — read only") so you can see per-key usage and revoke one integration without touching the others. Read-scope keys are great for agents that should analyze but never post.
How failures arrive
Two different things can go wrong, and they arrive differently on purpose.
A tool ran and failed — bad arguments, quota exhausted, item not found.
That is a normal MCP tool error: HTTP 200, result.isError: true, and the
v1 error envelope as the result text.
Your agent should read the code, act on it, and carry on.
Your credentials are the problem — no key, an invalid or revoked key, or a
key without the scope the tool needs. Those carry a real HTTP status, because
a 200 gives your client nothing to react to and hides auth-failure spikes
from anything sitting in front of the endpoint:
| Situation | Status | error.data.code |
|---|---|---|
No Authorization header | 401 | missing_authorization |
| Unknown, malformed or revoked key | 401 | invalid_api_key |
| Key lacks the required scope | 403 | scope_required |
| Key owner's role is too low | 403 | forbidden |
| Too many requests | 429 | rate_limited_key / rate_limited_ip |
The message stays readable in every case — the status is added, nothing is
taken away. No WWW-Authenticate header is sent: Borker uses static bearer
keys, so there is no authorization server for a client to discover.
initialize, tools/list and ping stay reachable without a key, so a client
can show the catalogue before you paste one in.
On a 429, error.data.retryAfterSeconds says how long to wait, and
rate_limited_key vs rate_limited_ip says whether it was your key or the
address you're calling from. create_content_draft and generate_content are
limited more tightly than the read tools — see
Rate limits.