MCP servers interfaced through skills – thoughts?

Keen integrates MCP servers through the existing Skills system. Connected MCP servers generate ordinary skill directories under ~/.keen/skills, and the LLM uses those skill files to discover MCP tools before calling the shared call_mcp_tool tool.

This makes MCP discovery prompt-efficient: the system prompt only lists a concise skill entry, while detailed tool lists and schemas are loaded on demand.

For a configured server named github, Keen generates:

~/.keen/skills/mcp:github/ ├── SKILL.md ├── .keen-generated-mcp.json └── schemas/ ├── create_issue.json └── list_issues.json

The skill name is always:

Keen generates MCP skills from connected server tool metadata:

---

name: mcp:github description: Use this skill to interact with the github MCP server.

Available tools

The generated metadata file looks like:

{ "managed_by": "keen-mcp", "server": "github", "status": "connected", "tool_count": 2, "last_successful_refresh": "2026-05-21T12:00:00Z", "last_error": "" }

Schema generation¶

Each MCP tool's InputSchema becomes a JSON file in the generated skill directory.

For a tool named create_issue, the schema path is:

~/.keen/skills/mcp:github/schemas/create_issue.json

For nested tool names, directories may be created under schemas/ as long as the name does not escape the schemas directory.

The LLM is instructed by call_mcp_tool to read:

Then it must pass arguments matching the schema exactly.

Keen includes enabled skills in the system prompt as a catalog entry like:

• mcp:github: Use this skill to interact with the github MCP server. → read ~/.keen/skills/mcp:github/SKILL.md

When the user asks for something that needs the MCP server, the LLM follows the same skill activation process as regular skills:

⚠️ There is a persistence difference between explicit slash activation and LLM-driven skill reading:

{ "server": "github", "tool": "create_issue", "arguments": { "title": "Fix flaky test", "body": "The race test fails intermittently." } }

The call_mcp_tool tool is generic. It does not expose one separate LLM tool per MCP server tool. The generated skill and schema files provide the discovery and argument contract.

After MCP startup completes, the REPL syncs MCP statuses with skills:

Generated files for failed or removed servers are not necessarily deleted. Instead, Keen disables the skill so it is hidden from the enabled skills catalog.

/mcp connect <server>

This calls MCP Refresh for the server.

MCP skills use the normal skills config file:

{ "is_enabled": { "mcp:github": true, "mcp:posthog": false } }

You can manage them with normal skill commands:

/skills list /skills disable mcp:github /skills enable mcp:github /skills reload

Important behavior:

To fully remove a server from Keen's MCP runtime, remove it from the selected MCP configuration file (~/.keen/mcp/configs.json by default, or the file passed to --mcp-config) and restart Keen.

MCP tools can perform arbitrary actions depending on the remote server. Keen adds these guardrails: