Skip to main content
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 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 integration. That one lets your AI editor call QA.tech. This one lets the QA.tech chat call your services.

​
Set It Up

1

Add a server

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.
2

Choose authentication

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 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.
3

Test the connection

Click Test connection. QA.tech connects to the server, lists its tools, and shows each one with a permission control.
4

Set tool permissions

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.
5

Use it in chat

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, 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. 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

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

For anything else, contact support.