A WITTIE

AND PLEASANT

COMEDIE

Called

MCP, or not MCP?

Miſplac’d among the Tragedies.

As it is to be acted at the poſit::conf and in the Cloud.

VVritten by NEAL RICHARDSON.

Houston,
Printed for the Author, and are to be had at
enpiar.com/mcp-posit-conf-2026

2026.

Friends, Romans, countrymen, lend me your ears!

I’m here today to talk to you about MCP: what it is, what it’s good for, and how best to use it.

I want to start with a story about how I learned what MCP was for.

Act I

Two houses, both alike in dignity, in fair Posit where we make our scene

One one side, we have the Posit engineering team, where I work. On the other, our users, our customers.

Now, these are not rival clans, but fate, or technology, has conspired to keep them apart.

Posit’s enterprise products run on-premises, which means that if something goes wrong, the engineers can’t see what’s going on directly because we don’t have access to the servers and networks where they’re running.

The user needs to write a everything down in a support ticket and send it to us. Then the engineers need to try to reconstruct what happened from that information, dig through the code base, and try to understand.

Posit uses Zendesk for support, customers can file tickets there and they get fielded by our support team. And there’s usually some back and forth with followup questions and requests for details before it escalates to the engineers.

So by the time the engineers get it, the ticket can be quite long, and there can be large attachments with diagnostic data in them in addition to all of the messages.

By the end of last year, engineering was heavily using AI for lots of things, and one thing we found that models like Claude were good at was reading the codebase, developing an understanding of how it works, and pinpointing bugs. But to use it for support issues, we first had to do all of the analysis of the ticket discussion and diagnostics, and that can be a lot of work.

I thought, 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 5 (1M context) · Claude Enterprise
  ▘▘ ▝▝    ~/code


❯ I prithee, friend, bestow thy help with https://posit.zendesk.com/agent/tickets/129426

However, this doesn’t work.

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


❯ I prithee, friend, bestow thy help with https://posit.zendesk.com/agent/tickets/129426

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

⏺ Alas, that door is locked against my hand:
  the agent view demands a login first,
  and I have neither token, key, nor tool
  that speaks to Zendesk on thy warrant here.
  I fetched the page; it gave an empty shell.

  Wilt thou paste the ticket's text to me
  (the subject, body, and the comment thread),
  and say what aid thou seekest: triage, or
  a bug to reproduce, or answer drafted.

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

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. (don’t say Connect on this slide)

A key point that underlies much of the talk is that:

You can write and host your own MCP servers

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.

If you use Posit Connect, hosting and managing MCP servers is straightforward, and Connect solves authentication, governance, and monitoring for you, as I will touch on at the end. But even if you don’t have Connect, the ideas and concepts I’ll discuss still apply, you just may need to do a bit more work yourself on the hosting side.

Act II: What’s in a Name?

MCP, or Model Context Protocol, sounds really jargony. And there’s lots of buzz and hype around AI today. And AI itself is kinda spooky technology: LLMs are non-deterministic, and kind of a black box.

But MCP is fundamentally simple.

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

This points at another framing for what MCP is:

MCP is an API standard

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

There are many standards for APIs out there, you have REST APIs, JSON RPC, many others, and each API defines its conventions for how you communicate with it. MCP is just another standard for how to make APIs, tailored to the needs of AI applications.

This realization helped demystify it for me. As someone who has worked in software and data for many years, I know how to use APIs, I know how to build and serve them too.

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

Now, there are two kinds of MCP servers:

Local vs. Remote MCP

Local

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

Local MCPs, where the code is running on your machine, potentially downloaded from anywhere really, and…

Local vs. Remote MCP

Local

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

Remote

• Runs somewhere else
• claude mcp add --transport http name-here https://example.com/mcp

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 where MCP really shines relative to the alternatives, and is a great fit for the problem I had with Zendesk, where what I’m trying to do is connect my agent to an external service that requires authentication.

Act III: MCP, or not MCP?

When MCP was first announced in late 2024, there was a lot of enthusiasm because it was really the first standardized way to give external tools to agents.

But, some of this enthusiasm was extreme, and people started to find alternatives.

In particular, people working with coding agents like Claude Code realized that, rather than registering a bunch of MCP tools, one for every thing you might ever want to do, you could give your agent a Bash tool, and it could run anything it could find at the command line.

Why use GitHub’s MCP if gh is already right there?

It’s not just about convenience, there are also practical considerations. MCP tool definitions consume tokens in your context window, and while harnesses like Claude Code have gotten smarter about deferring some of this, there is some overhead. And particularly with the smaller size of context windows that models had at the time, that was a real concern.

So, some took that to the other extreme and declared that MCP is dead, that CLIs were always the way to go.

I come to bury MCP, not to praise it

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

Of course, the truth isn’t so black and white. So let’s walk through the options and tradeoffs. There are three alternatives I want to consider here: MCP, CLIs, and Skills. Let’s start with Skills.

Skills

• Just prose/markdown with additional context and instructions for the agent

• 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)

• Skill + MCP = Plugin

Sometimes the thing you need is just additional context or instructions for the agent, not new tools. That’s where you want a Skill.

MCP vs. CLI

Use CLI when:

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

• Your agent has Bash available to call the CLI

The strongest case for using a CLI over MCP, particularly for the case I’m interested in here where we’re trying to connect a remote service to my agent, is when…

This is the exact case of the gh command line utility I mentioned. You save on lots of context because you don’t even need a Skill to explain how to use it, the model has already been trained on it.

But the advantages of a CLI over MCP are weaker if the CLI is something new you’re writing: it’s not in the training data, so you have to teach the agent how to use it–that’s context you have to take up. By the time your agent has “learned” how to use your new CLI, you’ve consumed all of the context savings you were hoping to have. Plus, if it is a new CLI you have written, you have a distribution problem, you have to get everyone to install it.

MCP vs. CLI

Use CLI when:

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

• Your agent has Bash available to call the CLI

But…

• Now we have to worry about running shell commands

• CLIs often general purpose, hard to allow agent to run only some of its commands

Plus, there are other tradeoffs that come with the convenience of using an existing CLI, which typically was not designed for use in AI.

Something like gh that can communicate to a remote service, sure it can read issues, but it can also act on your behalf with anything else that you can do in GitHub. Once your agent can run stuff in bash, it is difficult to allow it to do run certain CLI commands but prevent it, with certainty, from running others.

To be clear, I use gh in Claude Code on my laptop with “auto mode”, and I feel good about that, but there are other more autonomous agentic contexts where I want to be stricter than that. Because there are plenty of examples of agents going rogue and deleting the production database and whatnot. If a tool is available, an agent may be able to invoke it. You can do a reasonable job of managing what CLI commands it can run with allow lists and PreToolHooks and such, but what is your risk tolerance?

Now that I’ve raised the prospect of rogue agents and our risk tolerance, we need to talk a bit more about security and AI.

Act IV: Something Wicked This Way Comes

Agentic AI can be so valuable for us because it can, so to speak, “be creative” with how it uses the tools available to it to do tasks we want it to. But that same power, that same creativity, brings risks, because it could also do destructive things, whether on accident while trying to creatively solve our problem—or because someone else has given it different directions.

One framing that is useful for thinking about this risk is the “lethal trifecta”:

The 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.”

It’s disturbingly easy to get this. Let’s assume that you’re working with private data with your agent. 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 the second of the three of the trifecta. Even just the ability to make an arbitrary HTTP request using WebFetch is enough to satisfy the trifecta.

Now, we can’t solve this with a well designed MCP server or CLI, because it’s about the agent context where you’re using it, and it may be only in the combination of multiple tools, outside of a single MCP or CLI, that the trifecta is met. But…

We can make good choices when we write our own tools

But if we keep this in mind when designing our MCP servers, we can mitigate some risks.

How should we do that? How can we get the best results, and how do we avoid some of the bad things that can happen when agents go rogue? Here are three best practices to keep in mind.

Best practices

space

These best practices are relevant for security, but also help you be more efficient with your agent, which is cheaper and gets better results.

Best practices

1. Only define the tools you need

One reason is for efficiency: fewer tools means less context consumed by tool definitions, and less opportunity for confusion, for the agent to pick the wrong tool.

Another reason is security: the best way to prevent an agent from calling a dangerous tool is to never give it the tool at all.

In particular, I would be really mindful of creating tools that allow writes or deletes. Not that you shouldn’t ever do it, but think about how the lethal trifecta works. It’s about the full agent context, not any single set of tools. So tools that can do writes may be fine if this is the only MCP server your agent has, but not in combination with other tools.

But since we’re talking about writing your own, you can freely write multiple servers that have different combinations of tools, for use in different agents, if you want.

Best practices

2. Make responses concise

Brevity is the soul of wit.

Everything the MCP tool returns goes into the context. So if we’re building something in front of an external service’s API, we need to strip out the details that it returns that aren’t useful for our purposes. Extraneous stuff just burns more tokens and can confuse the model.

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.

So, these are some things to keep in mind when writing your own. And…

If you’re going to write your own, make it remote MCP

• Easy distribution: just share the URL, nothing to download and run locally

• No shell access required, so it works everywhere

• Easy authentication: MCP supports OAuth, so no long-lived credentials, no passwords in the agent context

Exception: when you need to access local files

If you’re going to write your own, unless the purpose of the tool is to manipulate things on your local file system, make it a remote MCP server that you host. It works everywhere, doesn’t have to execute code on your machine, and on a hosting platform like Posit Connect, you get lots of nice support, like authentication, which is built into the MCP standard.

---

Ok. I want to wrap up by putting this all together. On the title side, I said this play was a comedy, not a tragedy. So, despite the lethal trifecta, everyone doesn’t die, and we do have a happy ending.

Act V: All’s Well That Ends Well

We started with a zendesk ticket I wanted to get Claude Code to read directly. Let’s speed-run through how to solve this type of problem by deploying an MCP server to Posit Connect and then using it in Claude Code. First we have to create the MCP server, which we’ll do like this:

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


❯ Please use `fastmcp` to make an MCP server that ...

It’s weird to give a technical talk where I tell you to just go write your own servers and not show any code, but here we are in 2026. You may need some back and forth to guide the agent to make exactly what you want, but it’s pretty straightforward.

Now, we’re going to deploy this to Posit Connect, just as we do any other kind of app or API that we host there. And the first thing that Connect is going to solve for us is authentication to Zendesk. If we ran this MCP server locally, me and everyone else who wanted to use it would need to get an API key for Zendesk and manage their credentials somehow on their local machines. That’s a bit of a burden, and my Security team wouldn’t let me anyway.

Posit Connect integration, not Zendesk API keys

So instead, we set up an OAuth integration between Zendesk and Connect, and then added this to my MCP server on Connect. So there is no long-lived API key anywhere, and users of the MCP server don’t need to get special access to Zendesk–we manage their access to the MCP server the same way we manage access to any other app on Connect.

Connect has a dedicated view that shows you all MCP servers you have access to.

Connect serves this page here, which shows you the URL of the server, instructions for how to connect to it in various AI applications, and then a list of the tools it exposes. You can dig into them, see the same tool description that your agent will see, and even call the tools and see what data they will return back to the model.

Ok, so I copied that command and added it to my Claude Code. Notice that there is no API key in that command, so when I start Claude Code, I need to authenticate.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
   Zendesk-mcp MCP Server

   Status:           △ needs authentication
   Auth:             ✘ not authenticated
   URL:              https://connect.example.com/zendesk-mcp/mcp
   Config location:  ~/.claude.json [project: ~/code/mcp-posit-conf-2026]

   ❯ 1. Authenticate
     2. Disable

   ↑/↓ to navigate · Enter to select · Esc to back

This is the next place that Posit Connect really helps us because it supports that OAuth flow I mentioned before. So we open up the MCP tools, select “Authenticate”, and it opens up a web browser for us to authenticate to Connect. When it’s done it automatically closes the browser and returns you here.

❯ /mcp
  ⎿  Authentication successful. Connected to zendesk-mcp.

and now we’re ready to go

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

❯ I prithee, friend, bestow thy help with https://posit.zendesk.com/agent/tickets/129426

⏺ I'll fetch that ticket up anon.

⏺ zendesk - get_ticket (ticket_id: 129426)

⏺ zendesk - list_ticket_comments (ticket_id: 129426)

⏺ Ticket 129426 — "Posit Connect Authentication Migration"

  The customer's concern, as it now stands:

  Today their Connect binds to Active Directory,
  yet they would move to Entra ID for SSO,
  that MFA might guard each entering soul.
  They ask: is such a passage yet supported,
  by SAML or OIDC — and which of these
  doth Posit counsel for the enterprise?
  ...

Usage monitoring on Connect

There are a number of other benefits of hosting MCP servers on Connect, and one I just want to briefly mention here is that you get some analytics

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 (and your agent) can easily write custom MCP servers

• Posit Connect is a great place to host them

Shall I compare thee to an API? Thou art but that, no more, and nothing grand: mere plumbing that is built to serve AI. The agents read your tools and understand

the rest. So write your own, and then deploy it, let your whole team use what you design; and free the locked-out agents to employ your superpowers. And you draw the line

where they should stop. That line is your protection, for models can’t distinguish your commands from text a stranger wrote. That’s prompt injection: so narrow tools leave it with empty hands.

Your server does just what you do direct, so freely build. The rest is for Connect.

Thank you

These slides

Connect MCP user guide