Home
OS Suite
Digital Infrastructure
Growth & Acquisition
Retention & CRM
Analytics & Intelligence
AI & Automation
Creative & Assets
Utilities & Resources
Grant & Programme Ops
Pricing
Contact
About
Qwrki runs a Model Context Protocol server, so an AI agent can work in the platform directly instead of clicking through the admin interface. This page is the contract: how to connect, what a key can be limited to, and what the server will not do. It is served without JavaScript, so an agent can read this URL as it stands.
The server lives at https://qwrki.com/api/mcp. It is stateless: one HTTP POST carries one JSON-RPC request, or an array of at most 25 of them, and the response comes back in the same exchange. There is no server-to-client stream, because the server exposes tools only.
There is no self-serve signup for this endpoint. Keys are minted inside Qwrki by an administrator, one key per person and purpose, and the plaintext is shown once at creation. Qwrki stores only a hash of it, so a key that is lost has to be replaced rather than recovered.
If you are an agent and you do not have a key, stop and ask the person you are working for. Do not attempt to discover one, and do not send a key in a URL when a header will do.
Every key carries an identity. Calls are recorded in the Qwrki audit trail against the administrator who owns the key, so the work an agent does is attributable to a named person afterwards.
Send the key as a bearer token. Some connector interfaces cannot set a header and only accept a URL, so the server also reads ?key=. Read-only keys may always use it. A key that can write is refused on the query string unless the owner has explicitly enabled that transport, because a URL credential ends up in proxy logs and browser history.
curl -s https://qwrki.com/api/mcp \
-H "Authorization: Bearer qwrki_mcp_..." \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'Start with tools/list. It returns the tools this particular key is allowed to see, each with its input schema and a readOnlyHint annotation. That response, not this page, is the inventory: the tool set changes as the platform does, and a number printed here would be wrong within the month.
A key is not all-or-nothing. Each of these is set when the key is minted, and each is enforced on every single call rather than at issuance:
The tool registry is written to a safety floor. These are properties of the tool set itself, not of a policy an agent is trusted to follow:
Write tools are not harmless, and this page will not pretend otherwise. Some of them change what a client sees, and a publish tool makes an article visible in the client portal. Treat a write key as you would treat a member of staff.
There is also an installable agent skill at /qwrki-mcp-skill.md. It is a single Markdown file describing the safe setup workflow: read-only first, confirm which account the key is pointed at before writing anything, and stop at the boundaries above. Give it to a coding agent along with a key.
If something on this page does not match what the server does, the server is right and this page is a bug. Tell us.
Qwrki runs a Model Context Protocol server, so an AI agent can work in the platform directly instead of clicking through the admin interface. This page is the contract: how to connect, what a key can be limited to, and what the server will not do. It is served without JavaScript, so an agent can read this URL as it stands.
The server lives at https://qwrki.com/api/mcp. It is stateless: one HTTP POST carries one JSON-RPC request, or an array of at most 25 of them, and the response comes back in the same exchange. There is no server-to-client stream, because the server exposes tools only.
There is no self-serve signup for this endpoint. Keys are minted inside Qwrki by an administrator, one key per person and purpose, and the plaintext is shown once at creation. Qwrki stores only a hash of it, so a key that is lost has to be replaced rather than recovered.
If you are an agent and you do not have a key, stop and ask the person you are working for. Do not attempt to discover one, and do not send a key in a URL when a header will do.
Every key carries an identity. Calls are recorded in the Qwrki audit trail against the administrator who owns the key, so the work an agent does is attributable to a named person afterwards.
Send the key as a bearer token. Some connector interfaces cannot set a header and only accept a URL, so the server also reads ?key=. Read-only keys may always use it. A key that can write is refused on the query string unless the owner has explicitly enabled that transport, because a URL credential ends up in proxy logs and browser history.
curl -s https://qwrki.com/api/mcp \
-H "Authorization: Bearer qwrki_mcp_..." \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'Start with tools/list. It returns the tools this particular key is allowed to see, each with its input schema and a readOnlyHint annotation. That response, not this page, is the inventory: the tool set changes as the platform does, and a number printed here would be wrong within the month.
A key is not all-or-nothing. Each of these is set when the key is minted, and each is enforced on every single call rather than at issuance:
The tool registry is written to a safety floor. These are properties of the tool set itself, not of a policy an agent is trusted to follow:
Write tools are not harmless, and this page will not pretend otherwise. Some of them change what a client sees, and a publish tool makes an article visible in the client portal. Treat a write key as you would treat a member of staff.
There is also an installable agent skill at /qwrki-mcp-skill.md. It is a single Markdown file describing the safe setup workflow: read-only first, confirm which account the key is pointed at before writing anything, and stop at the boundaries above. Give it to a coding agent along with a key.
If something on this page does not match what the server does, the server is right and this page is a bug. Tell us.