Public data index › MCP API Launch Pack
Give three useful API operations a small, testable MCP surface.
For a founder, product lead, or engineering lead at a small B2B SaaS company with one stable JSON API, three genuinely read-only operations, and a team that wants inspectable source instead of a generated demo it cannot accept.
The pack turns three documented API operations into three inspectable MCP tools with a test trail your team can rerun.
The fixed offer
$457 one time
Exactly three documented, side-effect-free API operations become three named MCP tools. We agree the operations, schemas, acceptance commands, and exclusions in writing before payment is available. Delivery follows within seven business days after scope acceptance and cleared payment.
What you receive
Readable source
A Python server built on the official MCP SDK, plus an MIT license, dependency lock, Dockerfile, and Compose configuration. The code and configuration are yours to inspect, fork, extend, or retire.
Two local transports
A stdio launch profile and a Streamable HTTP profile. HTTP binds to loopback by default. Your existing gateway is the remote boundary; its route, TLS, and auth configuration are not built or silently assumed by this pack.
Three deliberate tools
Names, descriptions, parameters, and result schemas are written for the operation each tool performs. Endpoint selection follows the API's own side-effect documentation, never a guess based only on an HTTP verb.
Rerunnable evidence
Recorded mock fixtures, an MCP Inspector transcript, and ten deterministic protocol and tool-contract cases. They test the written contract; they are not presented as an AI-model success rate.
The delivery contents
- Typed input and output schemas for all three tools, agreed before implementation.
- Curated tool names, descriptions, parameter help, and compact structured results.
- A configured pagination ceiling so one call cannot return an unbounded upstream result.
- Request timeouts and explicit handling for upstream authentication, rate-limit, client, and server errors.
- Allowlist-only logs: a field is logged because it was approved, not because it happened to appear in an upstream object.
- Environment-only sandbox credential configuration; no credential in source, fixtures, image layers, logs, or the request form.
- A health route that reports the adapter process separately from a sandbox-call result.
- Host configuration snippets for local evaluation in Claude Code and Cursor.
- A short handoff that names what your team must own after delivery: gateway, TLS, auth policy, secrets, deployment, monitoring, and upgrades.
Why this is more than an SDK tutorial
A model can emit an MCP server skeleton quickly. That is useful for exploration, but a skeleton does not tell a buyer what the tool contract is, what the caller sees when the upstream times out, how much of a paginated response can enter context, or which exact command proves a delivered tool still matches its schema.
Fixed schemas create a correction standard
Each input and result shape is written before implementation. If delivered behavior contradicts that written shape, the defect is observable. Without a fixed schema, seller and buyer can both claim the same vague output is correct.
Descriptions are part of the interface
An MCP host exposes tool names and descriptions to a model. A generic name with a broad description can invite the wrong call even when the Python function is technically correct. The pack makes purpose, required arguments, exclusions, and result limits visible in that interface.
Compact output is a product constraint
Ordinary API responses are often designed for software that paginates indefinitely. MCP results enter a model context. The pack preserves agreed decision fields, applies a written page ceiling, and leaves an explicit continuation signal instead of dumping an entire upstream payload.
Failure is an output, not an accident
Timeouts, expired sandbox tokens, upstream 4xx responses, rate limits, and 5xx responses are separate cases. Safe error mapping names the class without echoing secrets, internal URLs, headers, or raw bodies. A health route cannot turn an upstream failure into a green tool result.
Acceptance your team can run
Acceptance does not depend on your external gateway, because gateway integration is not part of the fixed pack. It runs on the buyer's machine with a least-privilege sandbox token set in that machine's environment.
| Check | Passing evidence | Failure remains visible |
|---|---|---|
| Local stdio | initialize, tools/list, and one agreed sandbox call for each of the three tools succeed. | Launch, schema, auth, upstream, and result-shape failures exit nonzero and name their class. |
| Local Streamable HTTP | The same initialization, list, and three sandbox calls succeed over loopback. | A bind, session, protocol, or call failure cannot be replaced by the health route. |
| Contract suite | Ten named deterministic cases pass against the locked code and recorded fixtures. | Each case reports its expected and received contract; no aggregate percentage hides a failed case. |
| Secret receipt | The buyer-side receipt is constructed from an allowlist of test name, verdict, timestamp, and schema hash. | Headers, URLs, tokens, inputs, and response bodies are never copied into the receipt. |
The thirty-day correction window covers failures against the written tool schemas and written acceptance commands. It is not an operations contract and does not cover an upstream API change, a new endpoint, a new host, gateway work, or protocol changes released after delivery.
Fit and no-fit
A good fit
- One stable, documented JSON API.
- Three operations the API owner confirms are read-only and side-effect-free.
- A sandbox or test tier reachable from the buyer's own machine.
- An existing gateway for any future remote access.
- A technical owner who can run Docker, set an environment variable, and own deployment.
Not in this pack
- Write, send, purchase, delete, mutation, or mark-as-read operations.
- OAuth browser flows, webhooks, file uploads, streaming jobs, or scraping.
- API redesign, undocumented endpoints, production credentials, or customer data.
- Hosting account creation, DNS, TLS, gateway authentication, public exposure, or monitoring.
- Operating the server, on-call support, future SDK migration, or a claim of production readiness.
If the docs do not establish that an operation is side-effect-free, it does not enter the pack. If the sandbox cannot exercise a tool, that tool is not accepted into scope. We decline before payment instead of turning either gap into a guess.
Public reference surface checked 2026-08-09
US Tech Automations operates a separate public agent service. On 2026-08-09, its health route and machine-readable service registry returned HTTP 200. Its x402 manifest returned HTTP 200, listed fourteen resources, and named the MCP endpoint. A bare GET to that endpoint returned HTTP 405; the endpoint accepts MCP requests over POST. These are dated observations of our own reference surface, not claims about a future customer adapter or a promise of uptime.
- Reference service health
- Machine-readable service registry
- Resource and MCP endpoint manifest
- MCP endpoint (POST protocol surface; bare GET returned 405 on the dated check)
The launch pack builds against the current official documentation at delivery time: the MCP server guide and the official Python SDK repository. The dependency lock records the version delivered. It does not promise that later protocol or SDK changes will remain compatible without maintenance.
How the scope check works
- Send public docs, not secrets. Name one public API documentation URL and three candidate operations. Describe sanitized field names and types; replace values.
- We test the boundary on paper. The API documentation must establish that each operation is read-only and side-effect-free. We confirm the sandbox, result shape, pagination, and exclusions before accepting the scope.
- You approve a written contract for the artifact. It names the three tools, schemas, ten deterministic cases, acceptance commands, price, delivery clock, correction boundary, and exclusions. No payment is available before that scope is accepted.
- Your team runs acceptance locally. You set the sandbox token in your environment, run the stdio and loopback HTTP checks, and keep the server source and config.