MCP After Year One — Six Design Lessons the Industry Is Still Learning

---

title: "MCP After Year One — Six Design Lessons the Industry Is Still Learning"

published: true

published_at: 2026-06-23 12:00 -0400

description: "Anthropic announced the Model Context Protocol in November 2024. A year and a half later it is the closest thing the agent ecosystem has to a standard, with Anthropic's reference servers, a long tail…"

tags: mcp, aiagents, anthropic, llm

canonical_url: https://pickles.news/posts/mcp-after-year-one/

cover_image: https://pickles.news/posts/mcp-after-year-one/header.jpg

---

[Anthropic announced the Model Context Protocol in November 2024](https://www.anthropic.com/news/model-context-protocol). A year and a half later it is the closest thing the agent ecosystem has to a standard, with Anthropic's reference servers, a long tail of community implementations, IDE-level integrations in Cursor and Zed, and a [W3C-adopted browser-side variant called WebMCP](https://github.com/webmachinelearning/webmcp). The protocol is no longer the question. The question is what to build on top of it.

David Soria Parra, the MCP co-creator at Anthropic, recently gave a talk on the design lessons of the protocol's first year — the things teams keep doing wrong, and the design discipline the second year is going to require. The talk is the kind of artifact you don't normally get from a protocol author at this stage of an ecosystem's life: a clear, opinionated summary of where the mistakes are concentrated and what the corrective shape looks like.

This piece is my summary of those lessons, with the design rationale I think a developer building an MCP server in May 2026 actually needs. There are six of them.

1. Don't wrap REST as MCP

This is the design mistake every team makes once.

A REST API is a contract for developers and CRUD operations. It is structured around resources. The verbs are HTTP verbs. The granularity is *one row at a time*: `GET /users`, `POST /orders`, `PATCH /documents/:id`. That granularity is correct for a developer writing a frontend. It is wrong for an agent.

An agent wants to perform an *action* — a piece of work the user actually cares about. *Prepare a customer for onboarding.* *Find the contract and check it for risk clauses.* *Draft a response to the open support ticket.* Each of those actions, in CRUD terms, is a sequence of dozens of REST calls, each of which the agent has to plan, sequence, and check the result of. The agent ends up doing the work of an ORM and a controller, in a context window that has better things to do.

The bad version of an MCP server looks like this:

# DON'T: REST-style MCP server (one tool per API method)
@server.tool()
def get_user(user_id: str) -> dict: ...

@server.tool()
def create_order(user_id: str, items: list) -> dict: ...

@server.tool()
def patch_document(doc_id: str, fields: dict) -> dict: ...

@server.tool()
def list_permissions(user_id: str) -> list: ...

# ... seventeen more atomic CRUD wrappers

The good version is the same backend e