MCP, or not MCP?

Neal Richardson

AI in Production

June 5, 2026

Hi, I’m Neal 👋

• Open source and data

• Apache Arrow PMC member

• Currently VP Engineering at Posit

• enpiar.com

• arrowrbook.com

I’ve done a few things etc. Open source, Apache Arrow for many years, was chair of project management committee last year. Currently at Posit, and one of the teams I oversee is Posit Connect. (any Connect users out there?)

Connect is a platform for deploying and sharing custom apps, dashboards, reports, and APIs, things you write in the language or framework of your choice, whether that’s Streamlit, Shiny, FastAPI, nodejs, quarto, and so on. And, you can host MCP servers on it.

Last year, we found ourselves getting more and more into using Claude Code. One of the great things about our current moment in the industry is that so many things that may have seemed hard or out of reach before are now available for us to do. It lets us be much more responsive to new ideas and requests–now we can just fire off Claude on a git worktree without having to do all of the context switching to consider it, and many times it just gets it done, or pretty close.

So, increasingly, I kept seeing problems and thinking, how can I use Claude to solve it? What else out there have we learned to be hard and painful that maybe isn’t anymore?

Responding to support escalations became one of them. Posit uses Zendesk for support, customers can file tickets there and they get fielded by our support team. When they get a clear bug report, or something that they can’t answer on their own, it escalates to the engineers.

I thought, Claude is good at reading the codebase, developing an understanding of how it works, and pinpointing bugs. But when fielding a support escalation, a human engineer still has to read the full Zendesk ticket history, sometimes download and extract server diagnostics that were uploaded, and synthesize that. How can I just plug Zendesk into Claude and let it figure it out?

I want to just take the ticket URL and give it to Claude Code like this:

 ▐▛███▜▌   Claude Code v2.1.158
▝▜█████▛▘  Opus 4.8 (1M context) · Claude Enterprise
  ▘▘ ▝▝    ~/code

   Opus 4.8 is here! Now defaults to high effort · /effort xhigh for your hardest tasks

❯ please help me with https://posit.zendesk.com/agent/tickets/129426

However, this doesn’t work.

 ▐▛███▜▌   Claude Code v2.1.158
▝▜█████▛▘  Opus 4.8 (1M context) · Claude Enterprise
  ▘▘ ▝▝    ~/code

   Opus 4.8 is here! Now defaults to high effort · /effort xhigh for your hardest tasks

❯ please help me with https://posit.zendesk.com/agent/tickets/129426

⏺ I'll help with that Zendesk ticket. Let me fetch its contents.

⏺ Fetch(https://posit.zendesk.com/agent/tickets/129426)
  ⎿  Received 259 bytes (200 OK)

⏺ The ticket is behind Zendesk's authentication, so I can't fetch it directly — WebFetch only works on public URLs, and
  I don't have a Zendesk integration available in this session.

  Could you paste the ticket contents here?

The first piece is authentication–I can’t provide my credentials to connect to the Zendesk API. But even if I could, I would run into other challenges: the Zendesk REST API is not designed for AI agents to make efficient and secure use of it.

MCP is designed to solve this

space

MCP offers a solution to this.

It provides a way for you to authenticate securely to APIs, without giving your credentials to the agent.

By writing a custom MCP server, you can control exactly what tools are made available and what capabilities they expose. This improves your agent’s performance, and it also allows you to protect against a range of security vulnerabilties.

And by hosting an MCP server, you can easily share it with others.

So today I’m going to talk about MCP, what it’s good for and what it’s less suited for, and some best practices from my experience. When it’s the right tool for the job, MCP can unlock superpowers for your agentic workflows. And when done well, it can actually improve your security posture, which is especially important for AI agents.

A central point I want to land, and that really underlies everything in the talk:

You can write and host your own MCP servers

https://github.com/nealrichardson/zendesk-mcp-server

To do exactly what you need. Because code is now cheap. So my talk is going to be oriented about writing your own, not about whether or not you should use an MCP server that someone else provides. Even when someone else’s hosted MCP server is available to you, you may have reasons for wanting to customize it, as I will show. And thanks to AI, this is all available to you now.

You can write and host your own MCP servers

https://github.com/nealrichardson/zendesk-mcp-server

To do exactly what you need. Because code is now cheap. So my talk is going to be oriented about writing your own, not about whether or not you should use an MCP server that someone else provides. Even when someone else’s hosted MCP server is available to you, you may have reasons for wanting to customize it, as I will show. And thanks to AI, this is all available to you now.

What is MCP?

first want to say what it is not

MCP is specification for providing tools to LLMs

• Tools: functions that LLMs can call, the model “sees” that function exists, with a description telling it what it does, what the inputs are, and what the outputs are.

• MCP defines a standard for servers that host tools, and how to register them in your client, any AI application

Local vs. Remote MCP

Local

• Runs on your machine
• claude mcp add name-here -- uvx --from "git+https://github.com/user/repo"
• Can access your local file system etc.

Local vs. Remote MCP

Local

• Runs on your machine
• claude mcp add name-here -- uvx --from "git+https://github.com/user/repo"
• Can access your local file system etc.

Remote

• Runs somewhere else
• claude mcp add --transport http name-here https://example.com/mcp
• Cannot access your local file system but can access whatever you give the server

For a few reasons, I’m going to focus on remote MCP, and in particular on remote MCP servers that you write to do exactly what you need. I think this is the use case that has the most real value today.

MCP is an API standard

• It’s a standard for how to design APIs that AI applications can use

• Remote MCP servers communicate over HTTP, basically JSON RPC with a set of well known endpoints and a schema for how tools are defined.

• Realizing that MCP was just a convention for how to set up API endpoints helped demystify it for me. As someone who has worked in software and data for many years, I know how to use an HTTP API, I know how to build and serve them too.

You know what this is too. And your coding agents do too.

There was a lot of excitement

https://www.reddit.com/r/mcp/comments/1jn3ykp/mind_blown_with_mcp/

• Originally created by Anthropic in late 2024, and then put under a consortium under the Linux Foundation

Then, a backlash

https://uxplanet.org/mcp-is-dead-cf16b667ba6d

Like most things, there is truth in both the initial excitement for MCP and the hard backlash against it. There weren’t good alternatives to MCP when it came out, so people used it for all kinds of things and in questionable ways that today don’t make sense. It’s ideal for some use cases, and for others you are better off using a CLI.

Critiques

• Best tool for the job

• Inherent risks with agentic AI

• Best practices

MCP, CLI, or Skill?

• If the agent can do everything with tools it already has (Bash, Fetch, etc.) then a Skill is probably enough

• Otherwise, Skill is complement: we’re talking (MCP + Skill) vs. (CLI + Skill)

(MCP + Skill) vs. (CLI + Skill)

Critique that MCP takes up too much context: all tool definitions are loaded up front and take up tokens

Claude Code is good with CLIs: why use GitHub’s MCP if gh is already right there?

Use CLI when:

• CLI already exists, is widely available and in the training data

• Your agent has Bash available to call the CLI

CLI not and option if the AI application can’t run shell commands

More things you can do with remote MCP

• Authentication: OAuth 2.1 flow, or via HTTP header

• Accessing resources not available locally

• Monitoring

• Easy distribution via URL

These are things you just can’t do with a CLI

Distribution for remote MCP is also easier: single command to add a server by URL, rather than install CLI (and authenticate etc.) out of band

You (or your agent) could build these into your server, or you could deploy on a platform (like Connect) that gives you these for free.

Security

Lethal Trifecta

• Access to private data

• Exposure to untrusted content

• Ability to exfiltrate

https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/

“If your agent combines these three features, an attacker can easily trick it into accessing your private data and sending it to that attacker.”

Opening your agent up to external resources and code creates the opportunity for the lethal trifecta. This is not specific to MCP but there were some very public examples of exploits in the early months of MCP.

It’s not just that the MCP server itself may be malicious. Suppose you’re reading GitHub issues on a public repo, whether with GitHub MCP or the gh CLI. Someone could write a prompt injection into an issue, and that gives you one of the three of the trifecta. Presumably you’re doing something with private data already so that’s two. So if your agent has any ability to send data out, some other tool that lets it, you’ve got the trifecta.

Best practices

Brevity is the soul of wit

Best practices

1. Only define the tools you need

To reiterate, I’m talking about writing and deploying your own remote MCP servers

One reason is for efficiency:

Every tool definition consumes context in your agent. That’s tokens. Both money and distraction from what your real question is.

So, unlike when you’re making a REST API to interact with via other software, or a web app, or whatever, you want a small number of tools that do exactly what you want. Any more than that has a cost.

Another reason is security: do you really need tools that can write?

If the answer is “sometimes”, make more than one server, or make it configurable and make different deployments, or have some other means of allowing users of your MCP server to select only what they need?

Best practices

2. Make responses concise

Brevity is the soul of wit (had to get one Hamlet reference in here, given the title)

When you’re working with an API that’s designed for developers to work with, or web apps to build on, the API responses for a given record can include lots of details. And that makes sense when you’re a (human) developer, you can select out the bits you want and ignore the rest.

But with LLMs, everything you return goes into the context. Again, that’s more tokens, and more confusion. So we want to scope our MCP tools to only return the pieces that matter for the task you’re asking the agent to do.

For example, in the Zendesk API for ticket comments, every comment entry includes metadata about whether the comment was sent through the web portal or email or whatever, and potentially things like the user agent string and location of the browser where the person typed their comment. Could be useful for something, I guess, but not for answering the kinds of questions I’m asking. So we can cut it.

Best practices

3. Sanitize sensitive data

n***@posit.co

Finally, thinking back to the lethal trifecta, or even just good data goverance hygiene. If there are personally identifying details in the data you’re pulling in, and you don’t need them to answer your questions, you can either prune them entirely or redact them.

In this example, we can keep the information that a user from Posit reported this issue, which could be useful–maybe I want to look up other issues reported by this company–but the personal identity does not leak out.

MCP, or not MCP?

• MCP is (just) an API standard for AI agents

• Writing and deploying your own remote MCP servers can unlock superpowers for your agentic workflows

• AI brings inherent security risks, but a well designed MCP server can mitigate them

• You (or your agent) can easily write custom MCP servers

Thank you

These slides

Zendesk MCP repo