MCP TypeScript调用器

Linear: search documentation (requires `LINEAR_API_KEY`)

LINEAR_API_KEY=sk_linear_example npx mcporter call linear.search_documentation query="automations"

Installation

Install globally with npm

npm install -g mcporter

Quick Start

MCPorter auto-discovers the MCP servers you already configured in Cursor, Claude Code/Desktop, Codex, or local overrides. You can try it immediately with npx--no installation required. Need a full command reference (flags, modes, return types)? Check out docs/cli-reference.md.

Call syntax options

```bash

Try an MCP without editing config

```bash

Configuration Reference

Manage this file with mcporter config list|get|add|remove|import when you’d rather avoid hand-editing JSON; see docs/config.md for the full walkthrough. Config files are parsed as JSONC, so inline // and /* ... */ comments plus trailing commas are supported in both mcporter.json and mcporter.jsonc.

Manage configs with `mcporter config`

Run mcporter config … via your package manager (pnpm, npm, npx, etc.) when you want an interactive view of project MCPs:

• config list shows only local entries by default and, on TTYs, prints a summary of every other config file (Cursor, Claude, Windsurf, VS Code, etc.) with counts and sample names. Add --source import to inspect those imported entries directly or --json for scripting.
• config get/remove/logout reuse the fuzzy matching logic from mcporter list/call, so typos like sshadcn auto-correct to shadcn (with a dimmed notice) and ambiguous names surface “Did you mean …?” hints.
• config import <kind> --copy pulls editor-managed entries into config/mcporter.json, letting you customize or remove them locally without touching upstream files.
• Every subcommand honors --config <path> / --root <dir>, making it easy to juggle multiple project configs or workspace-specific overrides.

config/mcporter.json mirrors Cursor/Claude's shape:

{
  "mcpServers": {
    "context7": {
      "description": "Context7 docs MCP",
      "baseUrl": "https://mcp.context7.com/mcp",
      "headers": {
        "Authorization": "$env:CONTEXT7_API_KEY",
      },
    },
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest", "--autoConnect"],
      "env": { "npm_config_loglevel": "error" },
    },
  },
  "imports": ["cursor", "claude-code", "claude-desktop", "codex", "windsurf", "opencode", "vscode"],
}

What MCPorter handles for you:

• ${VAR}, ${VAR:-fallback}, and $env:VAR interpolation for config strings. Secret-bearing headers, env, and bearer-token placeholders stay lazy and resolve at runtime.
• Automatic OAuth token caching in the shared vault (~/.mcporter/credentials.json, or $XDG_DATA_HOME/mcporter/credentials.json when set) unless you override tokenCacheDir.
• Stdio commands inherit the directory of the file that defined them (imports or local config).
• Import precedence matches the array order; omit imports to use the default ["cursor", "claude-code", "claude-desktop", "codex", "windsurf", "opencode", "vscode"].
• chrome-devtools-mcp --autoConnect receives a small compatibility patch while upstream auto-connect can hang on busy Chrome profiles; set MCPORTER_DISABLE_CHROME_DEVTOOLS_COMPAT=1 to opt out.

OAuth-protected servers

If an HTTP MCP requires browser login (OAuth), persist it with --auth oauth (or set "auth": "oauth" in JSON), then run mcporter auth once:

npx mcporter config add notion https://mcp.notion.com/mcp --auth oauth
npx mcporter auth notion

On headless hosts, use npx mcporter auth notion --no-browser to print the authorization URL instead of launching the platform browser. Treat the printed URL as sensitive operational output. Keep the mcporter auth process alive until the browser redirects back to the printed redirectUrl; process managers that exit or clean up the command after capturing stdout can kill the loopback callback listener before OAuth completes. Run the command from a persistent terminal session, tmux, or a supervised background process such as nohup, and if you open the URL on another machine, make sure the callback port is reachable through a loopback-only tunnel or a configured oauthRedirectUrl.

Providers that do not support dynamic client registration can use a pre-registered app:

{
  "mcpServers": {
    "hubspot": {
      "baseUrl": "https://mcp.hubspot.com/mcp",
      "auth": "oauth",
      "oauthClientId": "your-client-id",
      "oauthClientSecretEnv": "HUBSPOT_CLIENT_SECRET",
      "oauthTokenEndpointAuthMethod": "client_secret_post",
      "oauthRedirectUrl": "http://127.0.0.1:3434/callback",
    },
  },
}

Keep client secrets in environment variables or private machine-local configs, and register the exact oauthRedirectUrl with the provider.

Refreshable bearer tokens (non-interactive OAuth)

For servers with pre-seeded OAuth tokens that need automatic refresh without browser prompts, use auth: "refreshable_bearer". HTTP servers receive Authorization: Bearer <token> headers; STDIO servers require refresh.accessTokenEnv to inject the token as an environment variable:

{
  "mcpServers": {
    "example": {
      "command": "uvx",
      "args": ["example-mcp-server"],
      "auth": "refreshable_bearer",
      "refresh": {
        "tokenEndpoint": "https://api.example.com/oauth/token",
        "clientIdEnv": "EXAMPLE_CLIENT_ID",
        "clientSecretEnv": "EXAMPLE_CLIENT_SECRET",
        "clientAuthMethod": "client_secret_basic",
        "refreshSkewSeconds": 300,
        "accessTokenEnv": "EXAMPLE_ACCESS_TOKEN",
      },
    },
  },
}

mcporter refreshes tokens before they expire (default 5 minutes early) using the refresh token from the vault. For keep-alive stdio servers that can't reload credentials after startup, use "lifecycle": "ephemeral" or restart the daemon before tokens expire.

Headless deployments that already have OAuth tokens can seed the vault without reproducing mcporter's internal vault key:

npx mcporter vault set hubspot --tokens-file ./tokens.json
npx mcporter vault set hubspot --stdin < tokens.json
npx mcporter vault clear hubspot

The JSON payload is { "tokens": { ... }, "clientInfo": { ... } }; tokens is required and clientInfo is optional.

Provide configPath or rootDir to CLI/runtime calls when you juggle multiple config files side by side.

Config resolution order & system-level configs

mcporter reads exactly one primary config per run. The lookup order is:

1. The path you pass via --config (or programmatic configPath).
2. The MCPORTER_CONFIG environment variable (set it in your shell to apply everywhere).
3. <root>/config/mcporter.json inside the current project.
4. $XDG_CONFIG_HOME/mcporter/mcporter.json[c] when XDG_CONFIG_HOME is set, falling back to ~/.mcporter/mcporter.json[c] when no XDG mcporter config exists and the project file is missing.

All mcporter config … mutations write back to whichever file was selected by that order. To manage a system-wide config explicitly, point the CLI at it:

mcporter config --config ~/.mcporter/mcporter.json add global-server https://api.example.com/mcp

Set MCPORTER_CONFIG=~/.mcporter/mcporter.json in your shell profile when you want that file to be the default everywhere (handy for npx mcporter … runs).

mcporter honors XDG Base Directory env vars for its own files when those vars are explicitly set: XDG_CONFIG_HOME for home configs, XDG_DATA_HOME for the OAuth vault, XDG_CACHE_HOME for schema caches, and XDG_STATE_HOME for daemon/runtime state. If the matching XDG var is unset or relative, mcporter keeps the legacy ~/.mcporter path. Config discovery is XDG-first but still probes ~/.mcporter/mcporter.json[c] when no XDG mcporter config exists, which keeps embedders from hiding the user registry when they set XDG_CONFIG_HOME for another tool. Existing explicit overrides still win.

context7.js (bundled CLI via Rolldown or Bun, depending on runtime)

> Convert the chrome-devtools MCP to a CLI via this one weird trick:
>
> `npx mcporter generate-cli --command "npx -y chrome-devtools-mcp@latest"`

Tip: you can drop `--command` when the inline command is the first positional argument (e.g., `npx mcporter generate-cli "npx -y chrome-devtools-mcp@latest"`).

- `--name` overrides the inferred CLI name.
- Add `--description "..."` if you want a custom summary in the generated help output (otherwise mcporter asks the MCP server for its own description/title during generation).
- Generated CLIs inherit the same color-aware help layout as `mcporter` itself: invoking the binary with no arguments shows the embedded tool list + quick start, and each `--help` page uses bold titles + dimmed descriptions when stdout is a TTY.
- Add `--bundle [path]` to emit a bundle alongside the template (Rolldown when targeting Node, Bun automatically when the runtime resolves to Bun; override with `--bundler rolldown|bun`).
- `--output <path>` writes the template somewhere specific.
- `--runtime bun|node` picks the runtime for generated code (Bun required for `--compile`).
- Add `--compile` to emit a Bun-compiled binary; MCPorter cleans up intermediate bundles when you omit `--bundle`.
- Use `--include-tools a,b,c` or `--exclude-tools a,b,c` to generate a CLI for a subset of tools (mutually exclusive).
- Use `--from <artifact>` (optionally `--dry-run`) to regenerate an existing CLI using its embedded metadata.
- Prefer a positional shorthand if the server already lives in your config/imports:
  `npx mcporter generate-cli linear --bundle dist/linear.js`.
- `--server`/`--command` accept HTTP URLs, optional `.tool` suffixes, and even scheme-less hosts (`shadcn.io/api/mcp.getComponents`).

Every artifact embeds regeneration metadata (generator version, resolved server definition, invocation flags). Use:

Agents should usually get one small skill per MCP server or workflow instead of a generic "all of mcporter" skill. See docs/agent-skills.md for the pattern and a copyable template.

Types-only interface (Promise signatures)

npx mcporter emit-ts linear --out types/linear-tools.d.ts