Do AI Agents Love Your Product?

For decades, product design teams at tech companies have been focused on making software more delightful for humans to use.

When done right, it becomes a clear competitive advantage. Apple is the most famous example of this. To quote the great Steve Jobs (NYT, 2003) -

Design is not just what it looks like and feels like. Design is how it works.

At Airbnb too, we had an internal slogan that pretty much everyone at the company swore by - “every frame matters”.

In today’s world, that work remains as important as ever. It is also woefully incomplete.

The simple reason is that today agents use software far more than humans (per Cloudflare’s CEO, 57.5% of all traffic on the Internet now comes from bots). This will remain true for the rest of our lives. Naturally, product design must therefore extend itself to meet this voracious consumer and figure out how to delight it just as much as its ‘anthropic’ counterpart (see what I did there?).

Companies typically take this to mean investing in AEO. Structured data, llms.txt, lengthy FAQs - all of these are important and well worth your time. But they don’t address two other central questions -

1. How do we bring our product directly where agents live and work?
2. How do we teach an agent the most efficient way to use and showcase our product?

And that’s exactly where MCPs come in.

MCPs - How It All Began

On 25 Nov 2024, Anthropic open-sourced the Model Context Protocol, paving the way for its current standing as “USB-C for AI” i.e. a universal way for LLMs to pull data from external sources into their context to give better responses. Crucially though, MCP usage has since evolved dramatically from “get data from Gmail” to “independently execute tool operations inside complex applications”.

I state openly that I rely on agents for nearly everything at Luminary. This is only possible because all the external software that helps me run the business was specifically chosen based on how well its MCP servers are scoped.

Case in point - I haven’t opened the GUI of Supabase, Vercel, Gamma, Magic Patterns, PostHog, Bitly, and Razorpay basically ever.

What great MCPs look like

Every MCP is basically just two things stapled together - written instructions on what your product can do, connected to machinery (typically an existing REST API) that actually does it.

MCP quality is therefore a function of 2 core vectors i.e. drivability x enablement.

When a client (Claude, ChatGPT) connects, it asks the server “what have you got?” and the server sends a tools menu — names, descriptions, schemas — back as structured data. It is essentially product copy for a robot that determines how well the robot can navigate your product so that the end user (the human) experiences zero friction.

Every MCP is basically just two things stapled together - written instructions connected to machinery that actually does it.

In my experience, two of the greatest MCPs currently in the market -

• Supabase — deep enablement: migrations, raw SQL, logs, security advisors — an agent can operate the whole database lifecycle without the dashboard.
  And it’s the most security-thoughtful one I’ve used: it wraps query results as untrusted data so a malicious row can’t hijack the agent, and requires explicit cost confirmation before anything that bills you.
• Linear — deep drivability: the tool descriptions are so well-scoped that an agent can run the entire PM loop (create issue → link PR → comment → close) first try, unsupervised.
  It passes the test: “what’s the largest task a stranger’s agent can complete in your product, first try, with no human help?”

Does your product need its own MCP server?

Building an MCP is not trivial. It requires you to think deeply about aspects like security, product experience, and design patterns. There is also the recent added complication of whether MCPs are even needed and why not just build a full-fledged CLI instead (typically overkill).

Generally speaking, I advise my clients to consider the following questions independently -

1. Do your users do repeated, multi-step work inside your product?
   If not (say you run a content site), AEO is enough.
2. Do you already have a public API?
   If yes, an MCP is a thin, cheap layer on top of it. If no, the API is your real project.
3. Would a user plausibly delegate that work to an agent?
   Reporting, provisioning, finops, data pulls — if yes, then the demand already exists.
4. Do your users already live in Claude, ChatGPT, or Cursor?
   If yes, build now — you’d be meeting them exactly where they work.

Another aspect to consider (that I have been noticing more of recently) is the native recommendations that come from within agents on which vendor to pick. I don’t have real data to back this up, but anecdotally, it is very obvious that agents promote products they can drive. I don’t think anybody’s looked at this metric yet, but it also seems to favor a well-scoped MCP over not having one.

Agents promote products they can drive.

So, how do you build an MCP?

If you’re still reading, odds are you’re convinced about MCPs being a critical aspect of the AI stack, with the potential to actively benefit companies that invest in building them well.

There are 5 principles that matter most when building an MCP -

1. Which jobs become tools?
   We’re not simply mirroring each API endpoint. The best MCP tools can capture nested workflows in natural language i.e. “book a meeting” vs “POST v2/calendar/”.
2. What do the tool descriptions say?
   This is the highest leverage copy your team writes this year. Remember that every description travels into the model’s context the moment a client connects. Descriptions must be highly specific about what the tool does and when to reach for it. Vague ones will not degrade gracefully, the model just won’t pick them.
3. How to think about security
   3 layers typically cover this - auth and credentials should never exceed what a logged-in user might be able to do, all tool results should come with a warning to check for malicious inputs, and anything destructive or paid should require confirmation.
4. Evaluations from an independent agent / virtual judge
   Mint a fresh agent that plays the role of your least aware user. Look for wrong tool calls, auth violations, and missed context entirely. Fix with copy updates first, then code, similar to how you may optimize a landing page (theoretically, that’s what it is).
5. Distribution matters as much as product
   List in MCP registries and directories. Make it a single-click install for all the popular harnesses and put a plain English descriptor on your site describing what an agent could do with it.

If you nail each of the above, you’re going to be further ahead than 99% of teams.

Akhil