Question 1

Why is MCP's split into data and transport layers useful?

Accepted Answer

List the practical consequences: 1. Server code is transport-independent. The same tool logic runs locally (stdio) and remotely (HTTP) — only how the server is started changes. 2. Adding a transport doesn't change the protocol. The data layer stays fixed. 3. Debugging gets easier. You can separate a message-format problem (data layer) from a connection problem (transport layer). Close with a concrete case: a server for an internal system is first tested locally over stdio, then deployed as an HTTP server for the team. The tool logic doesn't change — only transport and authentication are added.

Question 2

What would you pay attention to when writing an MCP tool description?

Accepted Answer

Start from the mechanism: the model doesn't see the tool's code — only name, description and input schema. So the description is the tool's interface. Rules: 1. Say what it does and what it returns. "Returns crash details" is weak; "returns the stack trace, the number of affected users and the version it first appeared in" is strong — the model knows what to expect. 2. Say when to use it, especially if similar tools exist. Two tools with similar descriptions make the model pick wrong. 3. Don't leave parameter descriptions empty. What is issue_id — the identifier from the URL, or an internal number? 4. State side effects explicitly. If the tool changes something, that must be visible in the description — for the model and for the human reviewing it. Add a diagnostic: if a tool is connected but the agent never calls it, the problem is almost always the description, not the tool.

Question 3

How do you choose between Tools, Resources and Prompts?

Accepted Answer

Give a simple criterion: Tool when an action is needed: send a query, compute something, change a system. The model calls it with parameters. Resource when static or semi-static information is needed: documentation, configuration, a schema. It is read, not called. Prompt when a recurring interaction template is needed: a "triage this crash" sequence. In practice Tools dominate, because agentic workflows are action-oriented. Add a nuance to show depth: the same data can be offered as both a resource and a tool. The difference is control — a resource is placed into context by the host when it decides to, while a tool is called when the model decides to. If the data is large and not always needed, the tool form is cheaper.

Server primitive	What it is	Android example
Tools	Functions the model can invoke — they take action	`get_crash_details(issue_id)`, `run_instrumented_test(module)`
Resources	Data sources for context — they are read	Internal API docs, design-system tokens
Prompts	Reusable interaction templates	A "triage this crash" template

MCP architecture: host, client, server

📚 Sources and documentation