Skip to content

Lab 8.1: Wire Two Existing MCP Servers

Goal

Add two existing MCP servers to OpenCode and test them with bounded prompts.

This lab is about safe integration, not maximum power. You should be able to explain why each server is useful, what it can access, and how you verified it worked.

What You Will Practice

  • Choosing MCP servers for real workflows
  • Adding MCP entries to OpenCode config
  • Scoping server access
  • Testing servers with safe prompts
  • Distinguishing useful access from risky access

Prerequisites

You need:

  • OpenCode installed
  • A project where you can edit OpenCode config
  • Two MCP servers you want to try
  • Any required credentials for those servers, if applicable

Recommended beginner choices:

  • A filesystem MCP server scoped to a safe local directory
  • A GitHub MCP server scoped to a test repo or read-only access
  • A fetch/web MCP server for public URLs
  • A browser MCP server for local UI inspection

Do not connect a production database or production admin account for this lab.

Step 1: Choose Two Use Cases

For each server, write one sentence.

Server 1:
I want my agent to access <system> so it can <task>.

Server 2:
I want my agent to access <system> so it can <task>.

Good examples:

I want my agent to access GitHub so it can read pull request details during review.

I want my agent to access a safe local docs folder so it can answer project documentation questions.

Weak examples:

I want to try this because it seems cool.

I want the agent to access everything so it has more context.

Step 2: Identify The Safety Boundary

For each server, answer:

  1. What can it read?
  2. What can it write or mutate?
  3. Does it need credentials?
  4. Can you make it read-only?
  5. Can you scope it to one repo, folder, account, or local test system?
  6. What is the worst plausible mistake if the agent uses it incorrectly?

Write this down before changing config.

Step 3: Add The MCP Config

Open your OpenCode config and add an mcp object if one does not exist.

The general shape is:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "server-name": {
      "type": "local-or-remote",
      "enabled": true
    }
  }
}

Example: Local Filesystem Server

Use a safe path. Do not point this at your home directory.

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "safe-docs": {
      "type": "local",
      "command": ["npx", "-y", "@modelcontextprotocol/server-filesystem", "./docs"],
      "enabled": true,
      "timeout": 30000
    }
  }
}

Example: Remote Server

Use the server provider's docs for the exact URL and auth method.

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "remote-example": {
      "type": "remote",
      "url": "https://mcp.example.com/mcp",
      "enabled": true
    }
  }
}

If the server needs tokens, prefer environment variables or the server's OAuth flow. Do not paste API keys into a lab submission.

Step 4: Restart OpenCode

Restart OpenCode after editing config so the servers load cleanly.

If a server fails to start, check:

  • The command or URL is correct
  • Required packages are available
  • Required credentials are present
  • The scoped path exists
  • The server is enabled

Step 5: Test Server 1 With A Bounded Prompt

Use a prompt that names the server, limits scope, and forbids risky actions.

Example for a filesystem server:

Use the safe-docs MCP server to read only the project README or docs index. Do not edit files. Return five bullets describing what the project does.

Example for GitHub:

Use the GitHub MCP server to read issue #1 in the test repository only. Do not comment, close, label, assign, or edit anything. Return the issue title, summary, and one suggested next step.

Record what happened.

Step 6: Test Server 2 With A Bounded Prompt

Repeat the same pattern for the second server.

Your prompt should include:

  • Which server or capability to use
  • What exact thing to inspect
  • What not to do
  • Output shape

Step 7: Compare The Two Servers

Answer:

  1. Which server felt safer? Why?
  2. Which server was more useful? Why?
  3. Which server would you allow in a shared team config?
  4. Which server would you keep personal or disabled by default?

Deliverable

Submit a lab note:

# Lab 8.1 Notes

## Server 1

Use case:
Config snippet:
Safety boundary:
Test prompt:
Result:

## Server 2

Use case:
Config snippet:
Safety boundary:
Test prompt:
Result:

## Comparison

Which server was safer?
Which server was more useful?
What would you change before sharing this config with a team?

Do not include secrets, tokens, private URLs, or credentials in the submitted note.

Pass Criteria

You pass this lab if:

  • You wire two MCP servers or clearly explain why one could not be started.
  • Each server has a real use case.
  • Each server has a documented safety boundary.
  • Each test prompt is bounded and non-destructive.
  • You do not expose secrets in your notes.

Common Mistakes

  • Adding a powerful server without knowing what it can write.
  • Pointing filesystem access at your entire home directory.
  • Testing with a vague prompt like "use GitHub and tell me what's up."
  • Treating MCP as a replacement for permissions and judgment.
  • Submitting tokens or private configuration details.