Skip to main content
Glama
DykstraSound

McProxy

by DykstraSound

McProxy

A local, multi-tenant Model Context Protocol server framework for macOS, paired with a browser-based connection manager at 127.0.0.1:7337. It puts several third-party services behind one MCP server, so a client like Claude Desktop or Claude Code sees one process instead of one per integration.

What it deliberately does not include

McProxy ships zero connectors. src/connectors/descriptors/ is empty and the descriptor registry is an empty array — there is nothing to configure, nothing to authorize, and no tool beyond ping until you add one. This is the framework's central decision, not an oversight: shipping someone else's integration would ship the shape of their credentials too. Every connector — its fields, its auth flow, its probe — is added per install, either by a human following a guide or by an AI agent running a setup interview.

Related MCP server: local-apple-data

Quick start

git clone https://github.com/DykstraSound/McProxy.git
cd McProxy
npm install
cp .env.example .env
npm run gui

npm run gui opens the connection manager in your browser. With no connectors configured yet, the page has nothing to show — that's expected. The MCP server itself (npm run dev, or dist/server.js after npm run build) also runs fine at this point; it answers ping and nothing else until a connector exists.

Adding your first connection

See docs/ADDING-A-CONNECTOR.md to write a connector descriptor yourself, or docs/AGENT-SETUP.md to have an AI agent walk you through it.

The descriptor model

Every connector is one file exporting one object: fields, auth kind, a live probe, an optional identity check, and an optional reconnect flow. The GUI, the .env resolver, and the tool-layer account scoping are all generic over this one shape — adding a connector never touches any of them.

export default defineConnector({
  id: "example",
  displayName: "Example",
  kind: "native",
  envPrefix: "EXAMPLE",             // {PREFIX}_ACCOUNTS / {PREFIX}_{SLUG}_{FIELD}
  multiInstance: true,
  manageable: true,
  auth: "oauth",
  fields: [{ key: "API_KEY", label: "API key", secret: true, required: true }],
  async probe(inst) { /* live reachability check — never rejects */ },
  async identity(inst) { /* real remote account, for the identity-mismatch check */ },
  authorize(inst) { return { script: "scripts/authorize-example.ts", args: [inst.slug] }; },
});

What it guarantees

  • Third-party content is fenced before it reaches a model. Every tool result that carries data fetched from a connected service is wrapped in a nonce-tagged envelope, minted after the payload exists so nothing in it can forge a matching close marker (src/shared/tools/untrusted.ts).

  • Secrets never leave the server through the API. The connection list masks every field marked secret to a four-character prefix/suffix and the write-side form never echoes a stored value back (src/gui/api.ts, maskSecret / fieldViews).

  • .env is written by exactly one module, which preserves comments and untouched lines byte for byte and takes a timestamped backup before every write (src/connectors/env-file.ts).

  • Every file under ~/.mcproxy is 0600 and every directory is 0700, enforced on every server and GUI start, not just at creation (src/shared/secure-fs.ts).

  • A probe never answers from a cache. Instance resolution is never memoized — a .env edit is live on the next call, not the next restart (src/connectors/instances.ts) — and the cached status a connection displays is written only by an explicit Test or reconnect, never inferred (src/connectors/status.ts).

  • Absence is reported as absence, never as health. A connector nobody has tested renders never-checked, not a default "ok" (src/connectors/status.ts); a config change is detected by re-resolving live state, never assumed from what was last observed.

Requirements

macOS, Node ≥ 22. Platform-agnostic support is an explicit non-goal.

License

MIT

Available Tools

1 tool
pingA

Returns a simple pong response. Used to verify the MCP server is running. Read-only.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full disclosure burden. It explicitly discloses the read-only nature ('Read-only') and the expected output ('Returns a simple pong response'). For a simple ping tool there is little else to disclose, so this is adequate, though not exhaustive (e.g., no mention of latency or failure behavior, which is minor here).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short, front-loaded sentences with zero waste. The core function ('Returns a simple pong response') leads, followed by the use case and the read-only qualifier. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, no-output-schema, no-sibling tool, the description is complete. An agent knows exactly what to expect on invocation (a pong response), why to call it (server verification), and its safety profile (read-only). Nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and 100% schema description coverage (empty schema), so the baseline is 4. The description adds nothing about parameters, but none exist to explain — the schema already exhaustively documents the empty parameter set. No compensation needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb ('Returns') and resource ('a simple pong response') and explicitly names the tool's purpose: verifying the MCP server is running. With no sibling tools to differentiate from, the purpose is unambiguous and immediately actionable for an agent.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use the tool ('Used to verify the MCP server is running'). With no sibling tools and no alternative paths, no exclusions are needed. It could have added a note on when NOT to use it, but the context is clear and sufficient for a health-check utility.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev1.0.0
    • First observedping

TDQS

A4.1/5.0

Scored across 1 tool

Disambiguation5/5

With only a single tool, there is no possibility of confusion between tools. The ping tool's purpose is clearly stated as a health check.

Naming Consistency5/5

The single tool name 'ping' is a clear, conventional verb that matches its read-only health-check function. With one tool there is no pattern inconsistency to penalize.

Tool Count2/5

A server named McProxy with only one health-check tool feels far too thin for its apparent scope. A proxy server would typically expose multiple operational tools, making one tool insufficient.

Completeness1/5

The tool surface provides only liveness verification and no actual proxy functionality, which is severely incomplete given the server name. Agents expecting proxy capabilities would hit a dead end immediately.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    D
    maintenance
    MCP server for privacy-gated local Apple data access including Mail, Messages, Notes, Calendar, Contacts, Photos, Reminders, Voice Memos, and iCloud Drive.
    30
    1
    MIT
  • A
    license
    Not graded
    quality
    A
    maintenance
    A local macOS MCP server for AI Agents that exposes safe endpoints for shell commands, files, processes, macOS automation, browser control, and more.
    69
    MIT
  • A
    license
    Not graded
    quality
    C
    maintenance
    A universal MCP server for registering internal, external, and OpenAPI-based APIs as MCP tools. It exposes them to MCP clients via Streamable HTTP and provides admin portal, RBAC/session auth, credential injection, and audit logging.
    Academic Free v1.1