Build & submit taskBetaintermediate

Wire Two MCP Servers Into a Project: a stdio Vault and a Remote Endpoint

Model Context Protocol (MCP) servers are how Claude Code reaches systems beyond the repo. In this task you author a project-scope .mcp.json with two real servers: the reference filesystem server speaking stdio, rooted at a vault of internal handbook files, and a remote keyless endpoint speaking HTTP. Then you use the vault server from inside a live session to retrieve three planted facts, and you submit the config, the session transcript, your answers, and your notes on config scopes and the trust boundary for instant, rubric-based feedback.

1 hr

Est. time

3

Outcomes

5

Rubric criteria

65%

Pass score

What you'll learn

Skills you'll have real reps in after shipping this.

Project scope (.mcp.json at the repo root) is the shareable scope: it rides version control, every teammate inherits it, and Claude Code asks for approval before first use. Local and user scopes live in ~/.claude.json for wiring that stays personal.
Two transports cover the MCP world: stdio spawns a local process from command, args, and env, while a remote server is a url with type http or sse, and an entry that has a url with no type is a config error Claude Code will skip.
A server sees exactly what you hand it: the filesystem server reads only under the root path passed as its argument, and a committed config stays keyless, with ${VAR} expansion carrying anything sensitive at load time.

The scenario

Every team that adopts Claude Code hits the same moment: the answer Claude needs lives in another system (a wiki, a tracker, a database), and pasting it into chat gets old fast. The Model Context Protocol (MCP) is the open standard that closes that gap, and the first server you wire yourself teaches the whole pattern: the two transports, the three config scopes, the approval step, and exactly what a server is allowed to see.

This kit stages that moment with the internal handbook of Otterworks, a fictional warehouse-robotics company. Six files sit in vault/; three of them hold ledger tokens that answer the kit's questions and three carry decoys. You wire the reference filesystem server over the vault as a stand-in for any external data source, add a remote keyless server alongside it so both transports are real, and prove the retrieval with a session transcript. A local self-check reads your actual .mcp.json and writes your proof-of-work evidence only when both transports are wired correctly, the config is keyless, and the retrieval artifacts hold up.

Your role

You are the engineer who owns how your team's project connects Claude Code to outside systems. Your deliverable is a shareable project-scope MCP config with both transports wired, a transcript proving the retrieval went through your server, and notes a teammate could learn the scope model from, packaged as a single submission.

Start the task to unlock the full brief

You'll get the step-by-step requirements, setup commands, the 5-criterion grading rubric, tips, and the ability to submit your solution for instant AI grading.

Free to start · submit when you're ready

Wire real MCP servers into Claude Code, hands-on

The Model Context Protocol (MCP) is how Claude Code reaches wikis, trackers, databases, and every other system your answers live in, and this task has you wire it for real. You author a project-scope .mcp.json with both transports (a stdio filesystem server rooted at a vault of company documents, plus a remote HTTP endpoint), approve the servers in a live session, and drive the retrieval of three planted facts through namespaced mcp__ tool calls you capture in a transcript. Along the way you learn the three config scopes and why the project-scope file is the one a team shares, what a server can see given its root argument, and why a committed config stays keyless. A local self-check verifies the wiring against your actual config and generates your evidence, so a green run means a submittable bundle.

Frequently asked questions

Do I need accounts or API keys for the servers?

No. The stdio server is the reference filesystem server run with npx, and the remote entry can be any public keyless endpoint. The self-check explicitly fails a config that carries credential-shaped values, so everything runs with Node, Python, and your normal Claude Code login.

What exactly gets graded?

Your .mcp.json wiring (a stdio server rooted at the vault plus a remote url entry with a correct type), a transcript of a real session showing mcp__ tool calls, the three retrieved FACT tokens, your notes on config scopes and the trust boundary, and the evidence the self-check generates. A rubric scores each part, and the config and evidence checks gate mechanically before any judgment call.

Can I skip the live session and copy the tokens straight out of the vault files?

The tokens are findable by hand, and the grade hinges on the transcript: it must show genuine MCP tool-use texture, meaning the approval step, namespaced mcp__ calls that match your configured server names, and result fragments from the right vault files. The grader cross-checks the transcript against the machine-made snapshot of your config, so running the wired session is the practical path to passing.