Someone's agent wants our data.

An agent wants to know what TIER 321 builds. Maybe a founder's research bot. Maybe an analyst's sidecar. Maybe Claude, asked a question by an operator who has no patience for ten open tabs.

Two weeks ago, that agent hit tier321.com and did the only thing it could do: parse HTML. Guess at structure. Hope nothing had moved. Today it calls a typed tool over JSON-RPC and gets back a shape it can reason about on the first try. No prompt-engineered scraping. No view-source:. No coincidences.

This is part two of the series. Part one added a Link header and a SKILL.md manifest so agents could find us. This one gives them something to call.

What shipped.

A public MCP server at mcp.tier321.com/mcp, built on Cloudflare Workers. Eight read-only tools. Anonymous. Per-IP rate limited at 20 requests per 10 seconds. Thirty seconds from a fresh MCP client to a live response.

The surface:

  • get_company_info — company facts, positioning, standard attribution.
  • list_products / get_product — shipped + in-development, one page of truth.
  • list_blog_posts / get_blog_post — paginated feed plus full MDX fetch.
  • list_industries, list_use_cases — sectors and workloads with product mapping.
  • get_contact_methods — verified ways to reach a human.

The server card at /.well-known/mcp/server-card.json describes the surface. One call to prove it's real:

curl -X POST https://mcp.tier321.com/mcp 
  -H 'Content-Type: application/json' 
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Try it now.

From Claude.ai: open Settings → Connectors → Add custom connector, paste https://mcp.tier321.com/mcp, name it TIER 321, save. Start a new chat, ask "what does TIER 321 build?", and watch the model reach for list_products instead of guessing. From Cursor or any other MCP client: same URL, same thirty seconds.

Want to inspect the surface before wiring it in? Run npx @modelcontextprotocol/inspector and point it at the endpoint. You'll see eight tools listed in the left pane; selecting get_company_info shows zero required parameters, a typed CompanyInfo return, and a live call button — roundtrip somewhere around 40 ms from the nearest Cloudflare edge.

"Has an API" vs. "is agent-native."

There is a real gap between a site has an API and a site is agent-native, and the gap is not syntactic. An API is a contract for humans to wire into other humans' code. Agent-native is a contract for software acting on behalf of a human — one that shows up at your door with no context, no tribal knowledge, and thirty seconds of patience before the operator interrupts it.

Two things close that gap. First, typed tools with descriptions an agent can read — the MCP tools/list response is, unromantically, a menu written for a stranger. Second, discovery metadata the agent finds without being told: a /.well-known/mcp/server-card.json that names the server, and an api-catalog document that hangs off the root. Both are in place now. A visiting agent follows the Link header from part one, reads the server card, finds the MCP endpoint, calls tools/list, and is operational. No human in the loop. That is the bar.

One real decision.

We wanted the rate limit to sit at the edge, in front of the Worker, invisible to application code. That was the plan.

The specific infrastructure knob we wanted wasn't on the path we could turn today. The contract conversation would have been longer than the thing we were shipping. So we rerouted inside the application: the Workers Rate Limiting binding, scoped per IP, in the same request path, same envelope, same observability. Different knob, same outcome.

Lesson: shipping sometimes means rerouting around infrastructure reality. The edges of your stack are not always where the marketing diagram says they are. Name the constraint, find the other knob that produces the same outcome, keep the ship date.

The source.

The MCP server behind mcp.tier321.com/mcp is open source under Apache 2.0 at github.com/jv-tier321/tier321-mcp. Reference implementation — the same transport, validator, rate-limit binding, and test harness we run in production, with TIER 321 specifics replaced by placeholder data. Fork it, deploy it, extend it.

What's next.

The read layer is done. The next wave is narrower and more interesting: a small set of authenticated write tools that let an agent take an action on its operator's behalf, with real attribution and real consent. And a deeper integration with Tower 321, our flagship orchestration platform, so a logged-in operator's agent can reach their own tenant data through the same protocol.

That is part three.

If you're building internal data an agent should reach.

We build agent-native surfaces in production — on our platforms and on operator infrastructure we own end-to-end. If you are standing up internal data an agent should reach, and you want to talk to the people who just shipped mcp.tier321.com, get in touch.