Field notes. John Arndt, Soxoa. Published .Written November 2026 as a planning guide for 2027. It will be revised when its facts are re-checked.
To make a SaaS product agent-ready in 2027, give AI assistants a production MCP server whose tools match the jobs your users do, OAuth sign-in so an agent acts as a real user within per-tool scopes, discovery files and directory listings so people can find it, and tests run in the assistants your users have. If your API already has a clean OpenAPI spec and one tool per endpoint is close to what assistants need, generating the server may be enough.
The Model Context Protocol (MCP) is the open standard ChatGPT, Claude and other assistants use to call tools in other software. Soxoa's glossary defines an agent-ready product as one an assistant can use on a signed-in user's behalf, and each part of that can be checked, which is what this guide does. It does not predict how the protocol or the assistants will change, and every vendor fact in it carries the date it was read.
What an agent needs from your product
Tools shaped around jobs
An assistant chooses tools from their names and descriptions. Start from the jobs users ask for, such as finding an overdue invoice or drafting a reply, rather than from your endpoint list. Give each tool a clear name, a description that says when to use it and when not to, bounded inputs, and a limit on how much it returns.
Errors it can recover from
When a call fails, return a message that says what was wrong and what would work, such as a missing field or a date out of range. A rate limit should say when to try again.
Sign-in as a real user
OAuth lets a user connect their existing account from the assistant, so the agent acts as that user rather than with a shared API key. Give each tool a scope. Anything that spends money, deletes data or sends a message can require confirmation in your product before it runs.
A way to be found
A connect page on your site, an entry in the Official MCP Registry, and submissions to the directories where assistant users look for tools. Curated directories review submissions on their own schedule.
Machine-readable discovery files
Files at known addresses that describe what you offer. As one example of what a site publishes today, soxoa.com serves an MCP server card, an A2A agent card, an agent skills index, an API catalog, an OpenAPI description and an llms.txt summary. Check which of these the assistants and directories you care about actually read before building each one.
Tests in real assistants
Ask real questions in the assistants your users have, and log what was asked, which tool ran, and what you changed when the model misread or misused a tool.
An owner
The code in your repository, a runbook, and a named person who maintains the server when the product or the protocol changes.
Tests to run before launch, and again during 2027
Keep these as a regression set, and run it again when you change a tool, when your API changes, and when an assistant your users rely on changes how it calls tools. Ask to see the evals describes what a useful test record shows.
- Ordinary jobs
- The requests users make most, phrased the way users phrase them. Check that the right tool ran with the right inputs and that the result is correct in the product, not just in the reply.
- Ambiguous requests
- A request that could match two tools. Check whether the assistant asks or picks the safe one, and tighten the descriptions where it guesses.
- Scope boundaries
- A user without permission for an action, and a token without the scope. Check that the server refuses and that nothing changed in the product.
- Confirmation
- An action that needs confirmation, with the confirmation missing, refused and expired. Check that nothing runs without it.
- Interrupted actions
- A timeout after the product received a write. Check that a retry does not create a duplicate.
When a generator is enough
Not every product needs tools designed by hand. If your API already has a clean OpenAPI spec and one tool per operation is close to what assistants need, a generator can produce the server. Soxoa publishes this guide and sells the agent-ready build, one of the options compared here, so each fact below is taken from the vendor's own site and dated; the full comparison links every source. They were read on 12 November 2026. Check the vendor's site again before relying on them.
- liblab
- MCP server generated and hosted from an OpenAPI spec. liblab says it can generate and host an MCP server directly from an OpenAPI spec, without the customer deploying or setting up infrastructure. Published price, as the vendor states it: 100 MCP calls a month free (first year only), then $5 for every 100 calls. Read on the vendor's own site on 12 November 2026 (source). A better fit than a designed build when your API already has a clean OpenAPI spec, one tool per endpoint is close enough to what an assistant needs, and you would rather pay by usage than for a build.
- Fern
- MCP server generated from an OpenAPI spec, hosted or self-run. Fern's MCP generator builds a server from an OpenAPI spec and generates one tool per supported API operation. No price was stated on the pages read. Read on the vendor's own site on 12 November 2026 (source). A better fit than a designed build when you already use Fern for SDKs or docs, your engineers are comfortable owning a generated server, and a tool for every operation is what you want to expose.
- Mintlify
- Search MCP server for a documentation site. Mintlify generates a search MCP server for a documentation site and hosts it at the /mcp path of the site. No price was stated on the pages read. Read on the vendor's own site on 12 November 2026 (source). A better fit than a designed build when your docs already run on Mintlify and the goal is for assistants to answer questions from your documentation, not to take actions in your product.
When to design the tools instead
Design the tools when the jobs users ask for span several endpoints, when some operations should never be in an agent's reach, when actions need confirmation in your product, or when users need to connect their own accounts with per-tool limits. Building in house against the open protocol is another option if your engineers have the time; the cost is their time now and the upkeep afterwards.
For reference, Soxoa runs MCP servers for Postedly, Intakra, MentionedOn, Portravo, Dokyumi, Ocolta and Soxoa planning tools (checked on 9 November 2026); the MCP guide shows how to connect the public planning tools.
What Soxoa's agent-ready build covers
The agent-ready build is a fixed-scope build of ten working days, done by John Arndt in your repository. Its fixed price sits within a range published on that page, set exactly on the scoping call and agreed in writing before work starts; what Soxoa costs lists how every offer is priced, and the alternatives to Soxoa include building in house. It delivers four things:
- A production MCP server
- The tools an assistant needs to do real jobs in your product, with names and descriptions the model reads correctly. Deployed to your infrastructure and tested in ChatGPT, Claude and a coding agent.
- Agent sign-in
- OAuth so a user connects their existing account from the assistant, with a scope for each tool. Anything that spends money, deletes data or sends a message can require confirmation in your product first.
- Directory listings
- A connect page on your site, an Official MCP Registry entry, and prepared submissions to the directories where assistant users find tools.
- Handover
- The code in your repository, a short runbook, and a walkthrough with whoever will maintain it.
A worked example: an invoicing app
A fictional invoicing app for trade contractors has a documented API with dozens of operations. Its users mostly ask for four jobs: find unpaid invoices, draft an invoice from a finished job, send a payment reminder, and record a payment.
The team plans four tools rather than one per operation: list_unpaid_invoices with a read scope; create_draft_invoice with a draft scope, where the invoice stays a draft until a person sends it; send_payment_reminder with a send scope and confirmation in the app before it goes; and record_payment with a payments scope and confirmation required. Deleting customers, issuing refunds and changing bank details stay out of the agent's reach.
The test log includes a contractor asking which invoices are more than 30 days late; a bookkeeper's account without the send scope asking for a reminder, which the server refuses; a confirmed reminder retried after a timeout, which must not send twice; and a vague request to tidy up old invoices, which should get a question back, not a deletion. If its users only needed answers from the documentation, a docs MCP server would be simpler; if the API were small and every operation safe to expose, a generator would be worth trying first.
A planning checklist for 2027
List the jobs
The requests users would make of an assistant, in their own words, ranked by how often they come up.
Mark the risky actions
Which tools spend money, delete data or send a message, and what confirmation each one needs.
Check your API and identity
A documented API the tools can call, and OAuth or an identity provider agents can sign in through. Both change the size of the work.
Decide: design, generate or wait
Compare designed tools, a generator, a docs server, or nothing yet, using the dated facts above and a fresh look at the vendors' sites.
Prepare discovery
A connect page, a registry entry, directory submissions, and the discovery files the assistants you care about read.
Write the test set
The cases above, kept as a regression set and run again after every change.
Name the owner
Who maintains the server, the runbook and the listings after launch.
What would change this advice
This guide was written in November 2026 and will be revised when its facts are re-checked.
- The protocol changes
- If the MCP specification changes how authorization, discovery or transport work, follow the specification over this guide and re-test. Record the version you built against.
- Directories change their rules
- Each directory sets its own submission rules and review times. Check them when you submit, not from this page.
- Vendor facts change
- The generator facts above were read on 12 November 2026. When a re-check finds something different, the comparison and this guide are updated from the vendor's own site.
- Your users do not use assistants
- If nobody asks to use your product from an assistant, a documented API and a good docs site may be the better investment for now.
Common questions
- Do we need an MCP server if we already have a public API?
- The API is what the server calls; the MCP server is the part an assistant reads and uses on a signed-in user's behalf. Having an API makes the server much easier to build.
- Can we generate an MCP server from our OpenAPI spec?
- Yes, if one tool per operation is close to what assistants need. liblab and Fern both describe generating a server from an OpenAPI spec on their own sites, as read on 12 November 2026; the comparison page links the sources.
- Which agent actions should require confirmation?
- Anything that spends money, deletes data or sends a message on a user's behalf. Make the confirmation happen in your product, not only in the assistant's reply.
- How do people find an MCP server?
- Through a connect page on your site, the Official MCP Registry, and the directories where assistant users look for tools, which review submissions on their own schedule.