SaaS platforms

Your users will start sending agents into your product

Not to buy it. To use it: pull a report, create a record, find something. Whether that works is now a product decision.

Free, no account.

What agents are doing here

A customer asks an assistant to get last month's numbers out of a tool they pay for, or to file something, or to find a record. The assistant opens your product in a browser, already signed in as them, and tries to work your interface out from the markup.

Which of these actually apply to you

There are two standards and they do not both matter to every kind of site.

UCP

Does not apply

UCP describes a business selling goods: catalogue, cart, checkout, payment handlers. Almost none of that maps to a subscription product, and there is little point publishing a profile that says nothing useful. Worth understanding, not worth implementing. If you sell physical goods alongside the software, that part may qualify.

What UCP is

WebMCP

Applies to you

This is the one that matters. Declaring typed tools turns your product from something an agent has to reverse engineer into something it can operate deliberately. It is closer to shipping an API than to marketing, and it deserves the same design attention.

What WebMCP is

Where it usually goes wrong

None of these produce an error. Each is a working site doing something an agent cannot follow.

Everything behind an application shell

A single page application renders almost nothing in its served markup. An agent inferring your interface from source sees an empty container, so declared tools are not a nicety here, they are the only reliable route in.

Destructive actions left exposed

A tool is a documented, machine readable entry point. Deleting, cancelling and changing billing deserve far more thought than searching does, because the agent may be acting on a loosely worded instruction from someone who has stopped watching.

Authorisation assumed rather than checked

Never rely on a tool not being advertised. Every tool must authorise inside its own handler, exactly as an API endpoint would.

Tools nobody can choose between

An agent picks a tool by reading its description. Three tools described as "search" is three tools it will use interchangeably and wrongly.

What to do about it

  1. 1 Pick the three or four operations customers most often ask support to do for them. Those are your first tools.
  2. 2 Write descriptions for a competent new colleague, not for yourself. The description decides whether the tool gets used correctly.
  3. 3 Authorise inside every handler and rate limit tool calls, on the assumption they will be called far faster than a person clicks.
  4. 4 Test the contracts in your build. A renamed entry point registers nothing and throws no error.

See where your site stands

One address, no account. You get a grade, what is worth fixing, and how to fix it.

Run a different kind of site? See the other sectors.