> ## Documentation Index
> Fetch the complete documentation index at: https://docs.qa.tech/llms.txt
> Use this file to discover all available pages before exploring further.
# Custom MCP Integrations
> Connect your own tools and services to the QA.tech AI chat through MCP servers, with per-tool permissions.
Custom MCP Integrations let the QA.tech AI chat use tools from services you already work with, such as a test management system like TestRail. You connect a remote [MCP](https://modelcontextprotocol.io) server, choose which of its tools the chat agent may use, and the agent picks them up alongside its built-in tools. Ask it to sync test cases, look up records, or file items in your other systems, and it calls your server's tools to do it.
This is the reverse direction of the [MCP Server](/integrations/mcp)
integration. That one lets your AI editor call QA.tech. This one lets the
QA.tech chat call your services.
## Set It Up
Go to **Settings → Integrations → Custom MCP Integrations** and click **Add
server**. Give it a name and enter the server URL, which must be a
Streamable HTTP MCP endpoint reachable over HTTPS.
**OAuth** is the default: after saving, you sign in to the service in your
browser and QA.tech handles the rest — no keys to paste. See [OAuth](#oauth)
below for how it works. If your server uses static credentials instead, pick
**Bearer token or API key** and paste the credential your server expects. It
is sent as an `Authorization: Bearer` header on every request and stored
encrypted. Servers without authentication are also supported, and you can
add extra headers such as `X-Api-Key` under **Additional headers** if your
server needs them.
Click **Test connection**. QA.tech connects to the server, lists its tools,
and shows each one with a permission control.
Decide per tool whether the chat agent may use it freely, must ask you
first, or may not use it at all. New tools default to **Needs approval**.
Open the project chat and ask for something the tools can do, for example
"look up the TestRail cases for the checkout suite". Enabled tools are
available to the agent automatically.
## OAuth
Many MCP servers do not issue static API keys and instead use OAuth — the
same flow as a "Sign in with ..." button. QA.tech implements the
[MCP authorization specification](https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization),
so connecting is fully automatic:
* **No configuration.** QA.tech discovers the server's OAuth settings and
registers itself as a client. You never enter endpoints or client IDs.
* **Browser sign-in.** **Add and connect** (or **Connect** on the server card)
sends you to the service's own sign-in page, and back to QA.tech when you
approve. Your password never passes through QA.tech.
* **Automatic refresh.** Tokens are stored encrypted and refreshed in the
background. You only sign in again if the service revokes access — the
server card then shows **OAuth not connected**.
**Reconnect** on the server card repeats the sign-in at any time. Changing the
server URL resets the connection, since the stored tokens only apply to the
original server. The service's authorization server must support automatic
client registration; most MCP servers do, and QA.tech shows a clear error when
one does not.
### Who connects
OAuth servers ask **who connects**:
* **Each member connects their own account** (the default). Tools run with
each person's own permissions in the connected service, so nobody acts
through a teammate's account. When a member opens a chat before connecting,
a banner above the message box asks them to sign in — one click, the
service's sign-in page, and straight back to the chat. If a connection
stops working mid-conversation (for example after a password change), the
failed tool call shows a **Reconnect** button right in the chat.
* **Everyone shares one connection.** One account — typically a service
account — is used for the whole project. Whoever clicks Connect provides
it. Pick this for servers where individual identity doesn't matter.
The server card in settings shows your own connection state for personal
servers ("connected as you") and how many members have connected. Switching
between the two modes signs everyone out of that server.
## Tool Permissions
Every tool runs with the permission you assign. The server-level default
applies to tools that appear later, so a server update never silently gains
unrestricted access.
| Permission | Behavior |
| -------------- | ------------------------------------------------------------------------------------------ |
| Allowed | The agent calls the tool without asking. |
| Needs approval | The chat shows an approval card before each call. Approve or deny it directly in the chat. |
| Denied | The tool is hidden from the agent entirely. |
An approval request expires after 4 minutes. If you deny it or let it expire,
the tool is not executed and the agent is told the call was not permitted.
## Requirements and Limits
| Requirement | Value |
| ----------- | ----------------------------------------------------------------- |
| Transport | Streamable HTTP (stdio-only servers are not supported) |
| URL | HTTPS, reachable from the internet, not a private network address |
| Auth | OAuth (recommended), bearer token, API key, or custom headers |
| Limit | Value |
| ------------------------ | ---------------- |
| Servers per project | 8 |
| Tools per server | 40 |
| Tools across all servers | 60 |
| Headers per server | 16 |
| Header value length | 4,096 characters |
If a server exposes more tools than the limit, the extra tools are skipped.
## Security
* Credentials are stored encrypted and are never shown again after saving. Editing a server keeps the stored values unless you enter new ones.
* OAuth uses the standard authorization-code flow with PKCE. Tokens and the client registration are stored encrypted, and access tokens are refreshed automatically. Signing in happens on the service's own pages, so QA.tech never sees your password.
* Server URLs must resolve to public addresses. Private and internal network ranges are blocked, and redirects are followed at most 5 times with the same checks on every hop.
* Tool output is treated as untrusted input: the agent is instructed not to follow instructions embedded in it.
* An unreachable or misconfigured server never breaks the chat. Its tools are simply unavailable for that conversation. Run **Test connection** to see the error.
## Troubleshooting
| Symptom | Likely cause |
| ------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
| Test connection fails | The URL is not a Streamable HTTP MCP endpoint, or the credential is wrong. Check both and retest. |
| "The server URL must use https" | Only HTTPS endpoints are accepted. Expose the server behind TLS. |
| A tool never shows up in chat | Its permission is **Denied**, or the server is disabled. Check the toggle and per-tool permissions. |
| Tools changed after a server update | Run **Test connection** again to refresh the tool list, then review permissions for new tools. |
| The card shows **OAuth not connected** | The sign-in was never completed, or the service revoked access. Click **Connect** to sign in again. |
| "does not support automatic client registration" | The service's authorization server lacks dynamic client registration. Use a bearer token or API key instead, or ask the vendor to enable it. |
| Chat says tools need authentication | The server uses personal connections and you haven't signed in yet. Use the banner above the message box, or Connect on the server card in settings. |
For anything else, [contact support](https://qa.tech/contact).