# Connect Model Monster MCP

> Connect your coding agent to Model Monster MCP and verify access to your organization and team.

Canonical URL: http://modelmonster.ai/docs/tutorials/connect-model-monster-mcp/

## Article Metadata

- Reading time: 6 min

In 10–15 minutes, you will create or securely reuse a Model Monster API key, connect your coding agent through the Model Context Protocol (MCP), and verify access to the intended organization and team with two read-only discovery calls. You will finish with the exact destination values needed to begin system work. The verification stops at discovery, so it does not list, create, scan, import, or change a system.

## Before you begin

You will need:

- A Model Monster account
- An MCP-capable coding agent
- Access to at least one existing Model Monster organization and team

An **organization** and **team** identify where you are working in Model Monster. Each has a **slug**: the exact machine-readable value that you supply to MCP tools. Later calls receive the organization and team slugs explicitly, so keep both values available after you find them.

If an organization and team have already been chosen for this work, use that pair. Otherwise, choose an existing pair you are authorized to access. The steps are the same either way.

The client configuration establishes the connection, but it does not choose a destination. You will prove the connection first, then use the values returned by Model Monster to identify where the next workflow should operate.

If your client already has a working `model-monster` server, continue to [Verify the connection and choose an organization](#verify-the-connection-and-choose-an-organization).

> **Note:** This tutorial uses read-only discovery and stops before `list_systems`, modeling guidance, system creation, source scanning, import, or synchronization.

## Create or reuse an API key

Your API key gives the MCP client your authorized Model Monster access. It does not extend that access beyond the key owner's effective permissions. Reuse a current key only if you already have its full raw value stored securely; the prefix shown in **API Keys** is not enough to configure a client. If you have the full value, continue to [Load the API key into your environment](#load-the-api-key-into-your-environment). Otherwise, create a new key. Using a separate key for each client or environment makes the credential easier to manage and revoke later.

To create a key:

1. Sign in to Model Monster and open the organization's **Settings**.
2. Select **API Keys**, then select **Create API Key**.
3. In **Create New API Key**, enter a descriptive **API Key Name***.
4. If you already know the tutorial destination, select **Restricted**, open **Restricted Team**, and use **Select a team** to choose the intended team. This is the least-privilege option for access to that team.

![Create New API Key dialog with Restricted scope selected and blank name and team fields](/media/original_images/01-create-api-key-restricted.png)

5. Create the key. When its full value appears, copy it immediately and store it in your normal secret-management workflow. You will not be able to view the full key again.

> **Warning:** A raw API key is a secret. Do not paste it into a committed configuration file, an agent prompt, terminal output, or a screenshot. The examples below use only `<YOUR_MODEL_MONSTER_API_KEY>` and the `MM_API_KEY` environment variable.

## Load the API key into your environment

In the terminal environment that you will use to launch your MCP client, set the key:

```bash
export MM_API_KEY="<YOUR_MODEL_MONSTER_API_KEY>"
```

Every client configuration in this tutorial reads the value from `MM_API_KEY`, keeping the raw secret out of the configuration itself. Launch the client from the same environment. The variable belongs to that environment and is not automatically added to a client that is already open. If the client is running, restart it after setting the variable so the new process receives it.

If you use a local `.env` workflow, keep that file uncommitted and load it before launching the client.

## Add Model Monster to your MCP client

Choose your client below and add a server named `model-monster`. Every option uses the hosted URL `https://api.modelmonster.ai/api/v1/mcp/` and reads the Bearer token from `MM_API_KEY`.

Keep the trailing slash in the URL.

Apply only the configuration for the client you use. After saving it, restart or reload the client as needed, then confirm that `model-monster` is registered before moving to the shared discovery steps.

### Claude Code

Add this configuration to the project's `.mcp.json` or a supported user configuration location:

```json
{
  "mcpServers": {
    "model-monster": {
      "type": "http",
      "url": "https://api.modelmonster.ai/api/v1/mcp/",
      "headers": {
        "Authorization": "Bearer ${MM_API_KEY}"
      }
    }
  }
}
```

Launch Claude Code from the environment where `MM_API_KEY` is loaded. Claude Code may ask you to approve a project-scoped server.

![Claude Code MCP status showing model-monster connected with sixteen available tools](/media/original_images/02-claude-code-server-status.png)

### Codex

Register the server from the command line:

```bash
codex mcp add model-monster --url https://api.modelmonster.ai/api/v1/mcp/ --bearer-token-env-var MM_API_KEY
```

Alternatively, add the equivalent entry to `~/.codex/config.toml`:

```toml
[mcp_servers.model-monster]
url = "https://api.modelmonster.ai/api/v1/mcp/"
bearer_token_env_var = "MM_API_KEY"
```

Run `codex mcp list` to confirm that the server is registered without exposing the key.

### VS Code with GitHub Copilot Agent Mode

Add this configuration to the project's `.vscode/mcp.json`:

```json
{
  "servers": {
    "model-monster": {
      "type": "http",
      "url": "https://api.modelmonster.ai/api/v1/mcp/",
      "headers": {
        "Authorization": "Bearer ${env:MM_API_KEY}"
      }
    }
  }
}
```

### Cursor

Add this configuration to `~/.cursor/mcp.json`:

```json
{
  "mcpServers": {
    "model-monster": {
      "type": "http",
      "url": "https://api.modelmonster.ai/api/v1/mcp/",
      "headers": {
        "Authorization": "Bearer ${env:MM_API_KEY}"
      }
    }
  }
}
```

## Verify the connection and choose an organization

Ask your coding agent:

```text
Use the model-monster MCP server and call list_orgs.
Show me the organization names and slugs you can access.
```

![Claude Code list_orgs result showing Monsters, Inc. and its organization slug monsters.inc](/media/original_images/03-list-orgs-success.png)

A successful result returns the names and slugs of organizations available to your key. If `list_orgs` returns organizations, the Model Monster MCP connection is working.

Review the returned names to find your destination. If an organization has already been chosen for this work, find it in the returned list. Otherwise, choose an accessible existing organization where you intend to work.

Copy that organization's returned `slug` and retain it as `<ORG_SLUG>`. The name helps you recognize the organization; the slug is the value later tools accept.

A successful result with an empty organization list still proves that the configured server and authenticated call worked, but it does not provide a usable destination. Obtain access to an organization, then repeat the same read-only call before continuing.

> **Note:** Choosing an organization means retaining its returned slug. Model Monster does not save it as an MCP session selection.

## Find a team and record the destination

Replace `<ORG_SLUG>` with the exact organization slug you retained, then ask your coding agent:

```text
Call list_teams for organization <ORG_SLUG>.
Show me the team names and slugs you can access.
```

A successful result returns the names and slugs of teams available within that organization.

Review the team names and returned slugs. If a team has already been chosen for this work, confirm that it appears under the expected organization. Otherwise, choose an existing team you are authorized to access and intend to use in the next workflow.

If the successful result contains no teams, the read still confirms that the organization-scoped call worked. It cannot complete the destination, however, because the next workflow needs both values. Obtain access to a team in that organization, then repeat `list_teams` for the same organization.

Ask the agent to repeat the exact organization and team pair. Record the returned values in your tutorial notes rather than relying on conversation history:

```text
Organization slug: <ORG_SLUG>
Team slug: <TEAM_SLUG>
```

![Claude Code list_teams result showing three team names and slugs under organization monsters.inc](/media/original_images/04-list-teams-destination.png)

You now have the organization and team you will use for later work. Keep both slugs together as a pair for the next workflow.

> **Note:** Connection and destination discovery do not create or change a system. Stop here: do not call `list_systems`, `prepare_modeling_context`, `create_system`, `sync_graph`, or begin a scan or import flow.

## Continue to system scanning

The `model-monster` server has responded to both read-only calls, and you have retained an accessible organization and team slug pair.

Continue with [AI-Assisted Blueprint Modeling](/docs/modeling-your-systems/system-scanning-and-import/), bringing `<ORG_SLUG>` and `<TEAM_SLUG>` with you. It explains how to prepare evidence, work with your agent, and validate the resulting System Blueprint.
