MCP Foundations: interview questions

Production questions of the kind asked in applied AI engineering interviews.

1. Larkspur's support bot connects to a filesystem server rooted at the project folder. Someone adds a second filesystem server rooted at ./handbook. Now the bot says files it read yesterday “do not exist”. How do you find the cause?

What a strong answer covers:

• Reads the startup log: both servers list the same 14 tool names, so the model gets 32 definitions for 18 names
• Finds the router, tool_to_session[tool.name] = session, which keeps the last server for each name; every filesystem call now goes to ./handbook, which resolves research_server.py inside its own root and answers ENOENT
• Fixes it by namespacing tool names per server (for example handbook__read_text_file) or by refusing to start on a duplicate name, rather than relying on config order
• Adds a startup check that fails when two servers expose the same name, and logs which server each call went to

2. You are exposing the handbook to agents over MCP. A teammate wants every chunk as a tool, another wants them as resources, a third wants a prompt. How do you decide?

What a strong answer covers:

• Asks who decides when the data is used: the model picks tools, the application or user picks resources, the user picks prompts
• Makes search a tool (search_handbook), since the model needs to call it in the middle of an answer with a query it writes
• Makes sections resources (handbook://section/{chunk_id}), read without side effects, for a UI that lets an engineer attach a section to the chat
• Makes “answer with citations” a prompt, a reusable instruction the user starts with /prompt, and keeps tool count low because every tool definition is sent on every call

3. After connecting four MCP servers, Larkspur's bot got slower and its bill went up, though most questions never call a tool. How do you measure where the cost went?

What a strong answer covers:

• Measures the tool definitions sent per request: in the lab, the notebook's three servers send about 2,527 tokens of tool JSON before the question starts, and the filesystem server is 80% of it
• Logs per request the number of tool definitions, their size, and which tools were called, to find servers whose tools are never used
• Drops or filters servers per route (a billing question does not need write_file), and checks the tool-choice rate on a fixed question set after each change
• Watches for the hidden cost of duplicates: two filesystem servers raise the total to about 4,649 tokens and add nothing the model can use

4. You ship larkspur-handbook in a Docker container with transport="streamable-http" and port 8001 mapped. The container is healthy, but no client can connect. What do you check?

What a strong answer covers:

• Checks the bind address: in SDK 1.30.0 FastMCP listens on 127.0.0.1 by default, which no one outside the container can reach; pass host="0.0.0.0" (the project's own lock, mcp 1.8.0, defaulted to 0.0.0.0, so the same code behaves differently)
• Checks the URL: Streamable HTTP lives at /mcp; /sse is the other transport, and /mcp/ answers with a 307 redirect to /mcp
• Checks the session: a stateful server returns an mcp-session-id header that every later request must carry, so behind several replicas it needs sticky routing or stateless_http=True
• Tests from outside with the MCP Inspector before blaming the client, and keeps an authenticated endpoint in mind before exposing it publicly

5. A security review flags the bot's server_config.json: @modelcontextprotocol/server-filesystem with the argument ., run from the project folder. What is the risk, and what do you change?

What a strong answer covers:

• The . makes the whole project folder readable and writable through read_text_file and write_file, and that folder holds the .env with the API keys the chatbot loads
• Any text the model reads, including a fetched web page, can ask it to read that file; the fetch server's own description already tells the model it now has internet access, so tool descriptions shape behaviour too
• Narrows the root to a data folder, drops write tools the bot does not need, and keeps secrets out of any served folder
• Reviews every third-party server's tool descriptions before connecting it, and pins server versions in the config so an update cannot change them unseen