# The MCP Layer

At the heart of PILSO OS lies the **Model Context Protocol (MCP)** — a standardized interface between intelligent agents and operational tools.

The MCP Layer is where **intent becomes action**.

***

### What is the Model Context Protocol?

**MCP** defines how language models (LLMs) interact with external tools in a modular, composable, and secure way. Each **MCP server** is a standalone service that exposes one or more tools an agent can use — such as compiling a contract, checking a token balance, or preparing a transaction.

Instead of hardcoding logic inside the agent, PILSO delegates each step of execution to specialized, isolated MCP servers that handle **just one task well**.

This architecture allows you to:

* Extend functionality without modifying agent logic
* Limit trust and risk per server
* Debug, test, and audit each module independently
* Build new capabilities in a plug-and-play way

***

### Anatomy of an MCP Server

Each MCP server typically consists of:

| Component                        | Description                                                                                              |
| -------------------------------- | -------------------------------------------------------------------------------------------------------- |
| **Tool Definition**              | JSON or code definition that describes what the tool does and what arguments it needs                    |
| **Execution Handler**            | The logic to actually perform the task (e.g. encode a transaction, compile a contract, fetch chain data) |
| **Schema Validator**             | Ensures correct input/output formatting                                                                  |
| **Logging/Telemetry (optional)** | Tracks usage for auditing or debugging                                                                   |
| **Rate Limiting (optional)**     | Prevents abuse or misfire from agents                                                                    |

All servers follow a predictable I/O format:

* Input: tool name + arguments
* Output: payload or next-step instruction

***

#### Agent-to-Tool Call (Example)

```json
{
  "tool": "erc20.transfer",
  "args": {
    "token": "USDC",
    "to": "0x123...abc",
    "amount": "100"
  }
}
```

The agent makes this call via the MCP runtime, which resolves the `erc20-mcp` server, sends the request, and waits for a result (a transaction payload, in this case).

***

### Core Server Modules in PILSO

| Server                                                                | Purpose                                         |
| --------------------------------------------------------------------- | ----------------------------------------------- |
| [**`metamask-mcp`**](/mcp-server-models/metamask-mcp-signing.md)      | Prepares transactions to be signed by MetaMask  |
| [**`chainlist-mcp`**](/mcp-server-models/chainlist-mcp-chain-info.md) | Fetches chain IDs, RPC endpoints, explorer info |
| [**`erc20-mcp`**](/mcp-server-models/erc20-mcp-token-operations.md)   | Handles token transfers, approvals, balances    |
| [**`solc-mcp`**](/mcp-server-models/solc-mcp-contract-compile.md)     | Compiles Solidity smart contracts               |

***

### Lifecycle of a Tool Call

```plaintext
1. Prompt → “Send 100 USDC to Alice”
2. Agent selects tool: erc20.transfer
3. MCP runtime prepares call to erc20-mcp
4. Server validates input → prepares tx data
5. Response: raw transaction payload
6. User signs via wallet
7. Tx is broadcasted
```

Every call is deterministic, isolated, and scoped — giving agents the ability to act **without giving them control**.

***

### Why the MCP Layer is the Heart of PILSO

* It’s the **execution engine** behind every intelligent agent instruction
* It enables **safe automation** without risk of key exposure
* It creates a **composable plug-in system** for any blockchain tool or protocol
* It future-proofs PILSO for evolving agent architectures, zk tooling, and more complex coordination flows

If agents are the pilots, MCP tools are the cockpit controls — and you decide which ones to give them access to.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.pil.so/core-concepts/the-mcp-layer.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.