MCP and Extensions

MCP and Extensions

MCP status

AnyLM does not implement the Model Context Protocol today. There is no MCP client, server, transport, or registry in this repository.

If you are looking for “plug in external capabilities,” use the native extension points below. Adding MCP would be a greenfield subsystem (schema translation, process lifecycle, IPC, UI, security confirmations).

Supported extension options

1. Custom tools (no code)

Shell or HTTP tools from the Tools UI. Best for personal automations and local scripts. See Tools.

2. Builtin tools (code)

Add to tools/registry.ts + tools/exec.ts. Best for first-class, shipped capabilities with consistent confirm/sandbox behavior.

3. Custom skills (no code)

Instructions + selected tools as a toggleable bundle. See Skills.

4. Builtin skills (code)

Non-connector (toolNames) or connector (tools[].run + OAuth). Best for productized workflows (Web research, Outlook).

5. OAuth connectors

Provider definitions + Firestore connectors docs + Skills Connect UI. Required for third-party APIs that need user delegated access. Outlook is the reference public-client implementation.

6. Local OpenAI-compatible proxy

Enable in settings (proxyEnabled, proxyPort, default **3227). Other apps can send /v1/chat/completionswith ananylm_` API key.

What you get: model access under AnyLM governance / identity.
What you don’t get: AnyLM tools, skills, RAG assembly, or multi-agent — those stay inside the desktop chat path.

7. Workspace + project coding path

Point file tools at a real folder (workspacePick) and lean on project-first coding so the model operates inside a scaffolded project. This is an “agentic coding” extension of the tool system, not a separate plugin API.

8. Documents / artifacts

generate_document and the artifacts explorer let skills/tools leave durable files the user can open outside the chat.

9. In-process governance API shape

auth.request(method, path, body) dispatches to api/index.ts with REST-shaped routes. You can add endpoints there (and matching Firestore rules) for new org-level features. The shape is deliberately server-portable (Auth & Firebase).

10. Marketing catalog (web/)

When you ship a user-visible skill/tool, consider updating the site catalog so download visitors see it. Not a runtime extension — documentation/marketing surface.

If you want to add MCP later (sketch)

Not implemented — planning notes only:

1. Decide role: MCP client (AnyLM calls external servers) vs host (expose AnyLM tools as MCP). Client is the usual ask.
2. Map MCP tools → OllamaToolDef and route execution beside tools/exec / skills/exec.
3. Lifecycle: spawn/connect servers from settings; store configs in llmeter-settings.json or a new anylm-mcp.json.
4. Security: treat all MCP tools as potentially risky; reuse confirm UI; sandbox cwd/env; never pass OS keystore tokens to MCP processes blindly.
5. IPC + UI: list/connect/test servers; per-chat enable; update api.d.ts / preload / ipc together.
6. Tests: mock transport; ensure tool-round limits and load-guard still apply.

Until that exists, do not document MCP as supported in user-facing copy.

Choosing an approach

Goal	Prefer
Personal script / webhook	Custom shell or HTTP tool
Reusable prompt + tools pack	Custom skill
Shipped product capability	Builtin tool and/or skill
User’s SaaS account (mail/calendar)	Connector skill
External IDE/agent hitting models	Local proxy + API key
Standard MCP ecosystem servers	Not yet — contribute a design/spec under docs/superpowers/ first