We Use Tembo to Maintain Tembo

Every time we ship an API change, there’s more work to do. Our MCP server needs the updated tools. Our TypeScript, Rust, and Python SDKs need the right types. Our docs need examples that work with the packages people can actually install.

We use a Tembo agent to handle that work.

It starts after an API release, updates the repositories, runs the checks, and opens pull requests. We review and merge them, then continue in the same session to update the docs and deploy the MCP.

Here’s how we set it up.

One spec, six repositories

Our API, SDKs, and MCP share an OpenAPI contract. The MCP generates its tools from it, and Scalar uses it to generate our SDKs.

That takes care of a lot of the code. But someone still has to carry a change through the release process:

• Refresh the MCP’s committed OpenAPI snapshot.
• Regenerate the TypeScript, Rust, and Python SDKs.
• Update API reference navigation and SDK examples.
• Keep our own agents’ instructions current with what the API can do.
• Check the builds, investigate failures, and prepare everything for review.

That work touches six repositories. Each has its own contributing instructions, checks, and release process.

Our Public API release maintainer has access to those repositories, GitHub, and a Scalar API key. It runs in a cloud VM where it can use the repositories’ scripts, build the packages, and investigate failures.

Start with what’s running in production

A completed release workflow doesn’t always mean the API made it to production. A deployment might have been skipped or cancelled. An unrelated job might have failed after the API deployed successfully.

So the agent checks the production deployment jobs before changing anything. If it can’t verify that the API shipped, it stops and tells us why.

Once production is verified, it refreshes the OpenAPI snapshot and uses that same contract across the MCP, SDKs, and docs.

This also explains why the MCP release happens separately from the API release. Our MCP loads a schema bundled into its image. Deploying a new API doesn’t change the tools in an existing MCP image. We review the schema update, merge it, and deploy a new image.

Let Scalar generate. Let the agent follow through.

The agent prepares and validates the SDK schema, updates resource mappings when endpoints are added or removed, and starts a Scalar build. That build generates all three SDKs and refreshes their release PRs.

Changes to existing endpoints matter too. Adding a response field won’t change the endpoint list, but it still changes the types developers use. The agent regenerates the SDKs whenever the spec changes.

Then it checks the result. Did the build reach each repository? Do the release PRs pass CI? Do the generated clients include the operations we expect?

If something fails, the agent reads the logs, investigates the cause, and prepares a focused fix. It follows each repository’s customization process so changes can survive future generator runs.

It can also check beyond what CI covers. For Python, that includes installing the package and importing its modules. A successful package build alone doesn’t tell us whether someone can use it.

We get PRs explaining what changed and how it was checked, along with links to the generated release PRs.

Docs need to match what users can install

The docs update has two parts.

API reference navigation can change alongside the schema. SDK examples need to wait until the package they use has been published.

We don’t want someone copying an example that depends on an unreleased version.

After we merge the SDK release, we return to the session and tell the agent. It checks what’s published, updates the examples to those exact versions, and validates them.

The workflow is straightforward:

Initial PRs → published SDKs → docs examples → MCP deployment.

The session stays attached to the work as it moves through those steps. We can ask what’s blocked, inspect a failure, or tell it that the PRs are merged without starting from scratch.

We still review the changes

The agent opens PRs. We decide what gets merged.

Once the required changes are merged, the agent can run the MCP release workflows. It publishes an image tagged with the MCP commit SHA, then promotes that same image through dev, staging, and production, waiting for each deployment to succeed.

If a workflow fails or needs approval, it stops and links us to the run.

We keep the existing scripts, CI checks, and deployment controls. The agent works through them and brings the results back for review.

Why we use an agent for this

We previously had parts of this flow in CI. Permissions were awkward, and we still ended up working with an agent to get it finished.

Now we give the agent the repositories, credentials, and instructions it needs to do the whole task. Those instructions describe the output we expect, the checks to run, and where it should stop for us.

Some releases only need a schema refresh. Others need a generator fix, a docs follow-up, or help getting a deployment through. The agent can handle that variation while keeping the work visible in one session.

This is one of the ways we use Tembo every day. An API release starts the work. The agent prepares the changes. We review them and keep moving.

If you have a recurring task that crosses repositories and always needs someone to follow through, try giving it to an agent. Start with the instructions you’d give a teammate: what to inspect, what to change, how to verify it, and what needs your review.

Create an automation in Tembo or read more about how automations work.