19 MCP Interview Questions for AI Agent Developer Interviews

MCP separates responsibilities into three roles:

• Host: the AI application the user interacts with, such as an IDE assistant or chat application.
• Client: the connector inside the host that manages one connection to an MCP server.
• Server: the external service that exposes tools, resources, and prompts.

Example flow:

User -> Host -> MCP Client -> MCP Server -> External System

The host controls the user experience and consent flow. The server provides capabilities. The client handles protocol messages between them.

Model Context Protocol (MCP) is an open standard for connecting AI applications to external systems such as databases, files, APIs, tools, and reusable prompt workflows.

Instead of building a custom connector for every model and every tool, MCP defines a common client-server protocol. An AI application can connect to an MCP server and discover what context or actions it exposes.

Common MCP capabilities include:

• Resources: readable context, such as files, records, schemas, or documents.
• Tools: callable functions, such as searching, creating tickets, or querying a database.
• Prompts: reusable prompt templates or workflows.

In interview terms, MCP is similar to a standardized integration layer between AI clients and external systems.

MCP uses JSON-RPC 2.0 as the message format between clients and servers. Requests include a method name, optional parameters, and an id. Responses return the same id with either a result or an error.

Example tools/list request:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {}
}

Example response:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "search_docs",
        "description": "Search internal documentation",
        "inputSchema": {
          "type": "object",
          "properties": {
            "query": { "type": "string" }
          },
          "required": ["query"]
        }
      }
    ]
  }
}

Notifications are also JSON-RPC messages, but they do not include an id and do not require a response.

In MCP, tools, resources, and prompts solve different integration problems.

Tools are functions the model can call to perform an action:

{
  "name": "create_ticket",
  "inputSchema": {
    "type": "object",
    "properties": {
      "title": { "type": "string" }
    },
    "required": ["title"]
  }
}

Resources are readable pieces of context, identified by URI:

{
  "uri": "db://schema/orders",
  "name": "Orders schema",
  "mimeType": "application/json"
}

Prompts are reusable message templates or workflows selected by the user:

{
  "name": "review_pr",
  "description": "Review a pull request for correctness and risk"
}

Use tools for actions, resources for context, and prompts for guided workflows.

MCP defines two common transport styles:

stdio is usually used for local tools. The client starts the MCP server as a subprocess and exchanges newline-delimited JSON-RPC messages over stdin and stdout.

Host process
  -> starts local server
  -> sends JSON-RPC over stdin
  <- receives JSON-RPC over stdout

Streamable HTTP is used when the MCP server runs as an independent HTTP service. The client sends JSON-RPC messages with HTTP POST, and the server may use Server-Sent Events for streaming responses or server-to-client messages.

Use stdio for local developer tools, filesystem integrations, and simple desktop workflows. Use Streamable HTTP for remote services, shared infrastructure, and multi-client deployments.

An API is a general contract for software-to-software communication. MCP is a protocol designed specifically for connecting AI hosts and agents to external context, tools, and workflows.

Use a traditional API when:

• You are building a product integration for deterministic application code.
• The caller is another backend, frontend, mobile app, or partner system.
• You need stable endpoints, strict request/response contracts, and predictable automation.
• You are not targeting model-driven discovery or tool selection.

Use MCP when:

• The caller is an AI host or agent.
• The system should expose discoverable tools, resources, or prompts.
• The model needs structured context before deciding which action to take.
• You want the same integration to work across multiple MCP-capable AI clients.

In short: an API is usually built for applications. MCP is built for AI agents that need to discover capabilities, read context, and call tools safely.

An MCP server should validate tool input at runtime, even when the tool already exposes an inputSchema. The schema helps clients construct valid calls, but the server still receives untrusted input.

Example validation in JavaScript:

function validateCreateTicketArgs(args) {
  if (!args || typeof args !== 'object') {
    throw new Error('Arguments must be an object');
  }

  if (typeof args.title !== 'string' || args.title.trim().length === 0) {
    throw new Error('title is required');
  }

  if (args.priority && !['low', 'medium', 'high'].includes(args.priority)) {
    throw new Error('priority must be low, medium, or high');
  }

  return {
    title: args.title.trim(),
    priority: args.priority || 'medium'
  };
}

Good validation should check type, required fields, allowed values, length limits, authorization, and whether the requested operation is safe for the current user.

Use a JSON-RPC error when the request itself is invalid, such as an unknown method or malformed parameters.

Use a normal tools/call result with isError: true when the MCP tool ran but failed at the domain level, such as a failed search, denied permission, or invalid business operation.

Example tool-level error:

{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Permission denied: you cannot create tickets in project FINANCE."
      }
    ],
    "isError": true
  }
}

This distinction matters because the client can treat protocol failures as integration problems, while tool-level errors can be shown to the model or user as task feedback.

An MCP tool should have a stable name, a clear description, and an inputSchema that defines the arguments the client may pass.

Example tool definition:

{
  "name": "search_docs",
  "title": "Search Documentation",
  "description": "Search the internal documentation index.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": {
        "type": "string",
        "description": "Search query"
      },
      "limit": {
        "type": "integer",
        "minimum": 1,
        "maximum": 10,
        "default": 5
      }
    },
    "required": ["query"]
  }
}

Example tools/call request:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "search_docs",
    "arguments": {
      "query": "MCP resources",
      "limit": 3
    }
  }
}

In production, validate arguments on the server as well. The schema helps clients, but it should not be treated as the only security boundary.

Use a resource template when the server can expose many resources following the same URI pattern.

Example template:

{
  "uriTemplate": "docs://pages/{slug}",
  "name": "Documentation Page",
  "description": "Read a documentation page by slug",
  "mimeType": "text/markdown"
}

Example read request:

{
  "jsonrpc": "2.0",
  "id": 10,
  "method": "resources/read",
  "params": {
    "uri": "docs://pages/getting-started"
  }
}

Example response:

{
  "jsonrpc": "2.0",
  "id": 10,
  "result": {
    "contents": [
      {
        "uri": "docs://pages/getting-started",
        "mimeType": "text/markdown",
        "text": "# Getting Started\n\nInstall the CLI and run the setup command."
      }
    ]
  }
}

Resource templates are useful when the client should discover a pattern without the server listing every possible resource.