Connect Tools & Data with MCP

MCP (Model Context Protocol) extends 100xprompt beyond your codebase. Register a server and 100xprompt can read from and act on your other systems - issue trackers, docs, databases, browsers, design tools - in the same session where it writes and runs your code. A connected server’s capabilities show up as regular tools. 100xprompt picks them up and uses them when they help complete your request. No glue code, no copy-paste between apps.

Reach your other systems from one session

Suppose you’re fixing a bug tracked in Jira that depends on last week’s design spec and a production schema. Instead of describing each one, you let 100xprompt fetch them directly. A single instruction can span several systems:

Issue trackers - read a ticket, comment, transition status, open follow-ups.
Documentation & knowledge bases - pull the current spec or runbook before writing code.
Databases - inspect schemas, run read queries, verify a migration’s effect.
Browsers - navigate, click, and read live pages to test or scrape.
Design & product tools - fetch a design, export an asset, read comments.
Anything with an MCP server - the ecosystem grows constantly, and any compliant server works.

100xprompt speaks MCP two ways: it connects to MCP servers you register (this page), and its own tools follow the same conventions so they behave consistently. Here you’re the one registering servers.

How it fits together

You register servers in a config file - the mcp key of your 100xprompt.json, or a dedicated .mcp.json. 100xprompt starts or connects to each one, discovers the tools it offers, and makes them available for the rest of your session.

There are two kinds of server. The only difference is how 100xprompt reaches them:

Type	You provide	100xprompt does	Best for
Local	A `command` to run	Launches the process and talks to it directly	Tools that run on your machine (filesystem, a local database, a browser driver)
Remote	A `url`	Connects over HTTP, authenticating if needed	Hosted services (SaaS issue trackers, docs platforms, team APIs)

Register a server

You register MCP servers in one of two files. Either way, you choose each entry’s name, and that name becomes the prefix on every tool the server exposes:

100xprompt.json - add servers under the top-level mcp key, alongside the rest of your configuration.
.mcp.json - a dedicated, portable file for MCP servers only. Drop it at your project root to share integrations through the repo, keep one in your global config for servers you want everywhere, or use .mcp.local.json for personal entries you don’t commit. This is the file the interactive 100xprompt mcp add writes.

Both files describe the same two kinds of server - local and remote. The field names differ slightly between them, as shown below.

In `100xprompt.json`

MCP servers live under the mcp key of your 100xprompt.json (or 100xprompt.jsonc).

Local (command)
Remote (URL)

A local server is a program 100xprompt runs for you. Point command at the executable and its arguments, as an array.

{
  "mcp": {
    "database": {
      "type": "local",
      "command": ["100xprompt", "x", "@modelcontextprotocol/server-postgres"],
      "environment": {
        "DATABASE_URL": "postgres://localhost:5432/app"
      },
      "enabled": true,
      "timeout": 8000
    }
  }
}

Field	Type	Description
`type`	`"local"`	Marks this as a command-based server.
`command`	`string[]`	The executable and its arguments, as an array.
`environment`	object	Environment variables set for the server process.
`enabled`	boolean	Set to `false` to keep the entry but skip it at startup.
`timeout`	number	Milliseconds to wait when fetching the server’s tools.

Use environment for connection strings, tokens, and API keys so they stay out of the command line and out of your shell history.

A remote server is a hosted endpoint. Give it a url; add headers for static credentials, or let OAuth handle sign-in for you.

{
  "mcp": {
    "tracker": {
      "type": "remote",
      "url": "https://mcp.example.com/mcp",
      "headers": {
        "Authorization": "Bearer {env:TRACKER_TOKEN}"
      },
      "enabled": true,
      "timeout": 8000
    }
  }
}

Field	Type	Description
`type`	`"remote"`	Marks this as a URL-based server.
`url`	string	The MCP endpoint to connect to.
`headers`	object	Headers sent with every request (for static tokens or API keys).
`oauth`	object \| `false`	OAuth settings, or `false` to turn off automatic OAuth.
`enabled`	boolean	Set to `false` to keep the entry but skip it at startup.
`timeout`	number	Milliseconds to wait when fetching the server’s tools.

Remote servers support OAuth automatically. If a server asks for authentication, 100xprompt detects it - you don’t need an oauth block unless you’re supplying your own client credentials or want to disable the behavior with oauth: false.

In `.mcp.json`

.mcp.json holds a single mcpServers object, keyed by server name. Its entries use the widely adopted MCP field names - a local server is identified by its command, a remote one by its url - so files you already have from other MCP-aware tools work as-is.

Local (command)
Remote (URL)

Give the executable as command and its arguments as an args array. Use env for variables passed to the process.

{
  "mcpServers": {
    "database": {
      "command": "100xprompt",
      "args": ["x", "@modelcontextprotocol/server-postgres"],
      "env": {
        "DATABASE_URL": "postgres://localhost:5432/app"
      }
    }
  }
}

Field	Type	Description
`command`	string	The executable to launch.
`args`	`string[]`	Arguments passed to the command.
`env`	object	Environment variables set for the server process.

Give the endpoint as url, and optional headers for static credentials.

{
  "mcpServers": {
    "tracker": {
      "url": "https://mcp.example.com/mcp",
      "headers": {
        "Authorization": "Bearer {env:TRACKER_TOKEN}"
      }
    }
  }
}

Field	Type	Description
`url`	string	The MCP endpoint to connect to.
`headers`	object	Headers sent with every request.

Entries from every .mcp.json and your 100xprompt.json mcp block are merged into one set of servers. When the same name appears in both, the 100xprompt.json entry wins - so you can keep a portable .mcp.json in the repo and still override a single server, or flip it off with { "enabled": false }, from your own config.

Add a server interactively

To be walked through it instead of editing config by hand, run:

100xprompt mcp add

You’ll be prompted for a name, whether the server is local or remote, the command or URL, and - for remote servers - whether it needs OAuth. The entry is written to a .mcp.json file, so it’s the fastest way to get a valid, portable configuration. By default it writes to your project’s .mcp.json. Use --scope (or -s) to choose where it lands:

100xprompt mcp add --scope user    # your global config, available everywhere
100xprompt mcp add --scope local   # .mcp.local.json - kept out of version control

Turn a server off without deleting it

Every server is on by default. Set enabled to false to park a server without removing its configuration - useful for silencing a flaky integration or a tool you only need occasionally.

{
  "mcp": {
    "browser": {
      "type": "local",
      "command": ["100xprompt", "x", "@playwright/mcp"],
      "enabled": false
    }
  }
}

When a remote server uses OAuth, you sign in once and 100xprompt keeps the session. Provide your own clientId / clientSecret only if the service requires pre-registered credentials. Otherwise 100xprompt registers itself with the server dynamically.

{
  "mcp": {
    "tracker": {
      "type": "remote",
      "url": "https://mcp.example.com/mcp",
      "oauth": {
        "clientId": "your-client-id",
        "clientSecret": "your-client-secret",
        "scope": "read:issues write:issues"
      }
    }
  }
}

Field	Description
`clientId`	Your registered OAuth client ID. Omit to let 100xprompt register dynamically.
`clientSecret`	The client secret, if the server requires one.
`scope`	The scopes to request during sign-in.

Add the server with type: "remote" and its url. No oauth block is needed for a standard sign-in - automatic OAuth handles it.

Start the sign-in

Run the auth command for that server:

100xprompt mcp auth tracker

Omit the name to pick from a list of your OAuth-capable servers and see which are already signed in.

Approve in your browser

100xprompt opens your provider’s authorization page. Sign in and grant access - the response returns to 100xprompt automatically to complete the handshake.

Confirmed and remembered

On success you’ll see the server connect. 100xprompt stores the credentials and refreshes them as needed, so you won’t be asked again until they’re revoked or expire.

To sign out of a server and clear its stored credentials, run:

100xprompt mcp logout

Keep secrets out of committed config. Reference tokens and client secrets through environment variables with the {env:NAME} syntax (for example "Authorization": "Bearer {env:TRACKER_TOKEN}") rather than pasting raw values into a file you check in.

Check what’s connected

List every configured server, its type, and its live status - connected, disabled, or waiting on authentication:

100xprompt mcp list

✓ database    connected
    100xprompt x @modelcontextprotocol/server-postgres
⚠ tracker     needs authentication
    https://mcp.example.com/mcp
○ browser     disabled
    100xprompt x @playwright/mcp

A needs authentication status is your cue to run 100xprompt mcp auth <name>. To inspect one server - its resolved settings, live status, and which file it came from - name it:

100xprompt mcp get tracker

And to delete an entry from whichever file defines it:

100xprompt mcp remove tracker

How the tools appear

When a server connects, 100xprompt discovers everything it offers and namespaces each tool by the server’s name. A server named tracker that exposes a search_issues capability becomes the tool tracker_search_issues. The prefix keeps tools from different servers separated and tells you at a glance where a capability comes from.

From there, 100xprompt selects the right tool on its own as it works through your request. You can ask:

“Find the open tickets tagged checkout, read the top one, and start a branch for it.”

100xprompt reaches for the tracker server’s tools, then continues the code work in the same flow.

If a server offers a large number of tools, 100xprompt keeps your context lean by loading each tool’s full definition only when it’s about to use it - so a big integration won’t crowd out the rest of your session.

Tips & limits

A server won't connect

Run 100xprompt mcp list to see its status. For local servers, confirm the command runs on its own in a terminal and that any required environment variables are set. For remote servers, check the url and, if it needs sign-in, run 100xprompt mcp auth <name>.

Tools are slow to appear on startup

Increase timeout for that server. It controls how long 100xprompt waits while fetching the server’s tool list (the default is 5000 ms) - larger integrations sometimes need a moment.

I don't want a server running right now

Set enabled: false instead of deleting the entry. Your configuration stays intact and you can flip it back on later. (The enabled toggle lives in the 100xprompt.json mcp block; use it there to switch off a server defined in either file.)

Where should I put the config?

Use .mcp.json at your project root when you want the whole team to pick up an integration from the repo, and .mcp.local.json for personal servers you’d rather not commit. Reach for the mcp block in 100xprompt.json (or 100xprompt.jsonc) when you’d rather keep MCP alongside the rest of your settings, or to override or disable a shared server. A server in your global config is available everywhere you work.

Tools

How 100xprompt uses tools, and how MCP tools sit alongside the built-in set.

Plugins

Bundle MCP servers, commands, and skills into shareable extensions.

Settings

The full configuration reference, including where mcp fits.

​Reach your other systems from one session

​How it fits together

​Register a server

​In 100xprompt.json

​In .mcp.json

​Add a server interactively

​Turn a server off without deleting it

​Sign in with OAuth

​Check what’s connected

​How the tools appear

​Tips & limits

​Related

Tools

Plugins

Settings

Reach your other systems from one session

How it fits together

Register a server

In `100xprompt.json`

In `.mcp.json`

Add a server interactively

Turn a server off without deleting it

Sign in with OAuth

Check what’s connected

How the tools appear

Tips & limits

Related