MCP Servers

MCP (Model Context Protocol) is an open standard that lets AI models call external tools and data sources during a chat. SKH integrates MCP servers as an optional extension layer: register a server, authorise selected members or groups, and tools become available in chat.

Use cases

• Jira / Linear – Read, comment, create issues.
• GitHub – Pull requests, code search, issues.
• Confluence / Notion – Wiki queries.
• Your own APIs – ERP queries, internal microservices.
• Open-source MCPs – e.g. for docs lookups or database queries.

Server types

SKH supports two server types:

STDIO

The MCP server runs as a local command-line process. SKH runs it as a background process and communicates with it directly. Typical for servers started via npx.

You provide:

• Command – e.g. npx -y @upstash/context7-mcp@latest.
• Arguments – Optional extra parameters.
• Environment variables – e.g. for API keys.

HTTP

The MCP server is reachable over a URL.

You provide:

• URL – The HTTP(S) address of the server.
• Headers – e.g. an Authorization header.

Registering a server

1. Settings → MCP Servers → Add server.
2. Provide:
   • Name – Display name, e.g. "Jira (Acme)".
   • Description (optional).
   • Server type – STDIO or HTTP.
   • Command/arguments/environment or URL/headers.
   • Timeout – in milliseconds (default 30,000).
   • Auto-restart – Restart automatically on failure.
   • Public – If on, the server is available to all members of your organisation (provided they have tool permissions).
3. Save. The server starts at Inactive.

Test

After creating, click Test. SKH tries to open a connection and fetch the list of available tools. On success the status flips to Active. On failure you'll see the error in the server detail view.

Status values

Listing tools

The server detail view (click the server) opens a tools dialog showing:

• Every tool the server exposes (name, description, expected inputs).
• Which permissions are granted per tool to which members or groups.
• A way to set permissions directly.

Granting permissions

Tools are not granted by default. You must specify per tool who can use it:

1. Server detail view → Manage tools.
2. On a tool, Add permission.
3. Pick:
   • Member – A specific person.
   • Group – All members of the group.
4. Optionally: a description of why access was granted.

Grant tools only to those who need them – especially writing tools (e.g. create issue).

Calling from chat

Members with a tool permission and MCP mode active in chat can ask the model to invoke a tool. Example:

"Create a Jira issue in project PLAT titled 'OAuth bug' with a summary of the discussion above."

The model picks the right tool, the result appears as a collapsible card in the chat:

🔧 jira_create_issue
   {project: "PLAT", title: "OAuth bug", description: "..."}

   → {issueKey: "PLAT-1234", url: "https://..."}

That way you can see exactly what the model called before it continues.

Well-known MCP servers

A short, non-exhaustive list of popular open-source MCPs:

More at github.com/modelcontextprotocol (opens in a new tab).

Security notes

• Tools are active – Unlike pure reading, tools can have side effects (create issue, modify file, send e-mail). Permission grants are therefore critical.
• Secrets in environment variables – For an STDIO server with an API key, keep it in the environment variables, never in the command field. Values are stored encrypted.
• HTTP servers – Use HTTPS. Authorization headers are also stored encrypted.
• With BYOK models – The external provider sees the tool calls. The data flow consequences from AI Models & Data Protection still apply.

Common issues

• Server stays in Error status after test – For STDIO servers: check that the command tool is available on the SKH platform. For HTTP servers: check URL and authentication.
• Tools don't appear in chat – MCP mode active? Permission set on the tool? Server Active?
• Timeout errors – Increase the timeout value (default 30 s) for slower servers.

Traceability

Every tool call stays visible as a collapsible card in the chat message – with tool name, arguments and response. That way it's possible to inspect after the fact what the model did and when.