# How to Rent Out an AI Agent via MCP (Signed Keys, Metering, and Getting Paid)

> If you've already got an agent that works — it qualifies leads, drafts research, checks compliance, whatever — the question isn't "what is MCP," it's "how do I turn this into recurring revenue without becoming a support desk." Renting it out over MCP is one real answer. Here's what that actually takes, DIY and otherwise.

Reviewed by Maxime Houle, Founder, SeldonFrame. Facts checked July 2026.

HTML version: https://www.seldonframe.com/guides/how-to-rent-out-an-ai-agent-via-mcp

## The model, in one paragraph

Instead of shipping your agent as code someone has to run, or hosting a UI someone has to log into, you expose it as a remote MCP server — a live endpoint.

A customer connects their own AI client to that endpoint using a key you issued them. From that point on, your agent is just another tool their client can call — the same way it calls a calendar or a database.

You meter what they use and bill for it. **"Renting," here, means access, not ownership** — you keep the agent, its accumulated knowledge, and every improvement you make to it going forward.

The customer never gets a copy to walk away with.

> 💡 Kind of like: MCP works like a universal power outlet for AI tools: any compliant client plugs into any compliant server the same way, so building your agent to the spec once means every compatible AI app can use it without a custom adapter.

**The rental loop, start to finish**

Publish endpoint → Issue key → Customer connects → Meter usage → Bill

## What has to be true technically

First, your agent has to be reachable as a remote MCP server — not just a local one.

The MCP spec defines two standard transports. *Stdio* is where a client launches your server as a local subprocess. *Streamable HTTP* is where your server runs as an independent process, handling multiple client connections over a single HTTP endpoint.

Renting to someone else's client **requires the HTTP transport**. Stdio is for a client launching a process it controls directly — that's not the shape of a rental at all.

Second, you need per-customer credentials you can revoke.

The spec's authorization framework covers exactly this, but **only for HTTP-based MCP servers**. It's built on *OAuth 2.1*: your server acts as an OAuth resource server that validates bearer tokens on every request.

Authorization is **optional in the spec** — a server can choose not to implement it. For a rental business, it's not optional in practice: without per-key credentials, you can't meter one customer separately from another, or cut one off without cutting off everyone.

Third, you need usage logging per key. Metering and billing both depend on knowing which key made which call.

Fourth, you need rate limits. A rented endpoint calls your model provider on every request — without a ceiling, one customer's usage spike becomes your token bill.

This is exactly where the two payment models diverge. **Renter-pays-BYOK** means the customer supplies their own model-provider key, and you charge only for access to the agent's logic and knowledge. **Owner-pays-metered** means you front the model cost and bill a margin on top — which makes rate limits a financial necessity, not just good hygiene.

> ⚠️ Watch out: Authorization being optional in the spec doesn't mean optional for a rental business. Skip it and you can't meter usage per customer or revoke one customer without revoking everyone.

## The commercial layer the protocol doesn't give you

MCP defines how a client and server talk to each other and authenticate. It says nothing about what you charge, how you invoice, or what happens when someone stops paying — that's a separate layer you build or buy.

**Pricing** is the first decision. Flat monthly per key is simpler to sell and simpler to reason about. Metered per call maps cost to usage more precisely, but means building usage tracking before you can bill anything.

**Key lifecycle** is the second: issuing a key at signup, rotating it on request, and revoking it cleanly on nonpayment or abuse. Without a revocation path, a rental business has no way to actually stop serving a customer who stops paying.

**Terms** are the third — what the agent may and may not be used for, since you're the one liable if it gets pointed at something it shouldn't be.

And **support** is the fourth. A black-box endpoint that breaks with no explanation is a much worse experience than software a customer can at least read the error logs of themselves.

## Two honest paths: DIY or a marketplace

The **DIY path** is real, fully-yours plumbing. Stand up your agent behind a Streamable HTTP endpoint, wire OAuth or a simpler API-key scheme for per-customer auth, build the usage-logging table, connect Stripe for billing, and write your own terms of use.

Nothing here is exotic — it's the same shape of work as standing up any metered API. But it is real, ongoing work: keys need a rotation and revocation flow, usage data needs to reconcile against invoices, and none of it stays done once you ship it once.

The **marketplace path** trades that plumbing for listing overhead. You publish once, and the marketplace handles discovery, key issuance, metering, and payouts.

Disclosed plainly, since we build this product: SeldonFrame is one such marketplace. Publish an agent and it becomes rentable via MCP with **signed rental keys** the platform issues and can revoke — you don't build the auth layer yourself.

The base platform is **$29/mo flat**, [BYOK](/guides/what-is-byok-ai) (bring your own model-provider keys, so there's no markup on tokens baked into the base price), with the first workspace free.

Neither path is objectively correct. If you want full control over pricing, terms, and the customer relationship, DIY is legitimate and not much harder than building any other metered API. If getting listed and getting paid matters more than owning every layer, starting from a [marketplace](/guides/what-is-an-mcp-marketplace) gets you there faster.

> 💡 Kind of like: A signed rental key works like a hotel key card: the issuer codes it to open exactly one room, and canceling the reservation deactivates the card instantly instead of forcing anyone to rekey the lock.

**DIY vs. marketplace**

DIY:
- Full control of pricing & terms
- You build auth, billing, revocation
- Ongoing plumbing upkeep

Marketplace (e.g. SeldonFrame):
- Publish once, listed for discovery
- Signed rental keys issued & revoked for you
- $29/mo flat, BYOK, first workspace free

## What rents well, and what doesn't

Agents that **rent well** have accumulated, maintained knowledge behind them — a vertical qualifier that's learned a specific industry's disqualifying questions, a compliance checker tuned to a specific regulatory area, a research agent with a curated set of sources for a niche.

The moat in those cases isn't the prompt. It's the **ongoing upkeep** that keeps the knowledge current — exactly the part a renting customer can't replicate by reading your system prompt once.

Agents that **don't rent well** are thin wrappers: a single well-phrased prompt around a general-purpose model with no accumulated context behind it. A customer who can rebuild the same result in an afternoon of their own prompting has no reason to keep paying you monthly for it.

## Trust is the sales blocker, and the unlock

A renter can't read the code behind your MCP endpoint before connecting to it. They're buying access to a black box, sight unseen — a harder sell than software they can inspect first.

What converts that hesitation into a sale are **legible reliability signals**: a published eval pass rate, guardrails you can describe concretely rather than just assert, and usage logs or a track record you're willing to show.

It's worth being honest that this norm is still forming across the MCP ecosystem. There isn't yet a widely agreed way to vet or display trust signals for a rented agent endpoint — so whatever you show a prospective renter today is **you setting the bar**, not meeting an established one.

> 💡 Tip: Show what you'd want to see if you were the one connecting a black-box endpoint to your own AI client: a pass rate number, a plain description of what the guardrails actually block, and a few real usage logs. Specifics beat a trust badge.

## FAQ

**Who pays for the model tokens — me or the renter?**

Either — and it's a decision you make explicitly, not something MCP settles for you. **Renter-pays-BYOK** means the customer supplies their own model-provider key, and your charge covers access to the agent's logic and knowledge only. **Owner-pays-metered** means you front the token cost and bill a margin on top — which makes rate limits per key a financial necessity, not just abuse prevention.

**What stops a customer from just copying my agent?**

Nothing stops them from copying a prompt, if that's all there is. The honest answer: a well-run agent's moat is the **accumulated, maintained knowledge** behind it — sources kept current, edge cases handled over time — not secrecy around the prompt itself. If a customer can rebuild your result in an afternoon, it wasn't a defensible rental in the first place. If they can't, it's because the upkeep is the hard part, and upkeep doesn't copy.

**Can I revoke a customer's access if they stop paying?**

You should be able to — worth confirming before you rent to anyone. MCP's authorization framework is built on **OAuth 2.1 bearer tokens** validated per request, which is the mechanism that makes revocation possible: invalidate the token and the next request fails. Whether that revocation is easy or painful depends entirely on how you built the key-issuance layer, DIY or marketplace.

**What should I charge?**

There's no established market rate to cite here — treat any number you see quoted elsewhere with the same skepticism. The two common shapes are **flat monthly per key** (simpler to sell, simpler to reason about) and **metered per call** (maps cost to usage more precisely, but requires usage tracking before you can bill anything). Pick the shape that matches how unevenly your customers will actually use the agent, then price to cover your token costs plus the upkeep time the previous section describes — that upkeep is what you're actually charging for.

## Try it

- Related free tool: https://www.seldonframe.com/tools/claude-project-brief-generator
- Go deeper: https://www.seldonframe.com/marketplace
- Build your AI front office free (about 3 minutes): https://www.seldonframe.com/signup

## Sources

- [Model Context Protocol — Transports specification](https://modelcontextprotocol.io/docs/concepts/transports)
- [Model Context Protocol — Authorization specification (2025-06-18)](https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization)