Your knowledge base, callable by anything that speaks MCP.
One endpoint on the Model Context Protocol. Five tools, one header, no site identifier to pass. The key decides which site the caller sees, so there is nothing to get wrong.
The knowledge base answers your website and nothing else.
A support console, an onboarding script, a scheduled job that files new documentation. Each of them could use the same answers the widget gives visitors, and each of them has to be wired up separately, or not at all.
The protocol itself, not another API to wrap.
A client connects to one endpoint with your site key and calls tools/list. The server answers with every tool, its description and a JSON-Schema for its arguments, so the client configures itself. Discovery is part of the protocol, which means there is no separate document that can quietly go out of date.
- query_knowledge_base - an answer grounded in the site's indexed content, counted on query quota exactly like a question asked on the website.
- list_documents - what is indexed, with the status and chunk count of each document. Read-only and not metered.
- add_knowledge - a question and answer pair added directly, for when the answer lives with a colleague rather than on a page.
- ingest_url and ingest_sitemap - index one page, or every page an XML sitemap lists. Private and loopback addresses are refused, so neither can be aimed at something internal.
- No tool takes a site identifier. The client and site come from the key alone, so a caller cannot reach another tenant by changing an argument: there is no argument to change.
Four steps, nothing to install.
- In the SLAtech admin, create a key for the site you want to expose.
- Leave the scope at query for a client that only reads, or add ingest if it should also write.
- Point the client at the endpoint and send the key in the X-Api-Key header.
- Call tools/list. The client discovers everything else on its own.
Do not reuse the widget key. That one sits in the public markup of your site where anyone can read it, so it carries the read-only scope by design and every write tool refuses it. A server-side integration gets its own key.
Any client that speaks the protocol.
The endpoint speaks the Model Context Protocol over Streamable HTTP, so it is not tied to one vendor's client. If you would rather call it directly, it is JSON-RPC over HTTP and one header, and you need no library at all.
- Any MCP client: Connect with the endpoint URL and your site key
- Direct JSON-RPC: No library needed, one POST per call
- Agencies: The key selects which client knowledge base answers
- Legacy manifest API: GET /v1/mcp/manifest still works for integrations built on it
Counted on its own meters.
MCP calls are recorded separately from chat traffic, so what the integration costs is visible on its own rather than hidden inside your website numbers. Calls are rate-limited per key, at a ceiling set well above a polling dashboard because an agent works in bursts. There are MCP-only plans for buyers who want the tools without running the chat widget.
Other ways to extend SLAtech.
Ready to let your tools ask the knowledge base?
One endpoint, one key, and a client that configures itself.