Your doc portal is now available to AI agents and LLMs with MCP

More and more developers discover and integrate APIs without leaving their IDEs, by querying an agent or asking an LLM to understand how an endpoint works. After pushing optimized Markdown versions a few months ago, your doc portal is now available through an MCP server.

In one click, you can now turn any Bump.sh documentation or hub into an MCP server. No workflow to write, no MCP server to maintain: your existing docs become the source.

What LLMs and AI agents can do with your doc portal MCP server #

The MCP server allows AI tools to search your documentation, browse its structure, and access any doc page. Answers are optimized to keep the token usage low. Three tools are exposed:

• search: find relevant pages by keyword, based on what the user/agent typed in natural language. It can be filtered by type (operation, schema, topic, authentication, etc.)
• list_pages: explore the documentation hierarchy to understand what’s available before going deeper
• get_pages: retrieve the full content of any page, in a clean format built for LLM consumption

An AI tool can answer “how do I create a booking?” by searching your docs (search), reading the right operation (get_pages), and returning a factual answer based on a token-friendly version of your doc portal.

How to add the MCP server #

The Ask AI dropdown in your documentation and hubs includes direct shortcuts to add the MCP server to Cursor, VS Code, or any other tool via a ready-to-use mcp.json snippet, the file used by most IDEs to add MCP servers.

The feature is activated by default on your hubs and docs. You can administrate it in the “Ask AI” section of your hub/doc general settings.

Learn more in the help center.

Any questions or feedback? Reach out at hello@bump.sh.

Run Arazzo workflows on your MCP servers

You can now use your Arazzo documents to run workflows on Bump.sh MCP servers. Arazzo is a workflow specification from the OpenAPI Initiative that extends your existing OpenAPI documents by describing how to sequence operations to accomplish real tasks.

You can deploy Arazzo documents using the CLI or the GitHub Action. Web upload using the dashboard isn’t supported yet.

Wanna learn more about Arazzo? Head over to our Arazzo guide for a full walkthrough of the specification.

Choosing between Arazzo and Flower #

You can now describe your workflows using one of these two specifications:

• Flower, our own lightweight specification.
• Arazzo, the specification supported by the OpenAPI Initiative.

We initially built Flower to describe simple workflows without having to add references to OpenAPI files: the specification felt overkill during our MCP platform building phase. As we started writing more complex workflows, we deepened Flower capabilities. It now supports data transformation between steps that Arazzo doesn’t support.

You can use Arazzo when you have OpenAPI definitions and want the portability of an OAI standard, and use Flower when you need something lighter or deeper data manipulation at the step level.

Any questions or feedback? Reach out to us anytime.

Roles requirements

Your users need to know what authentication methods are required, but they also have to know what access level or roles are needed to start sending requests to specific endpoints. There’s currently no way to describe it in OpenAPI: that’s why we are introducing x-rolesRequirements. Combined with security schemes, it gives your users a complete picture.

The x-rolesRequirements property can be added to any OpenAPI/AsyncAPI operation. It can either be an array of strings or a string:

paths:
  /clusters:
    post:
      summary: Create a new cluster
      x-rolesRequirements:
        - Organization owner
        - Product owner
      # ... rest of operation
  /clusters/{id}:
    get: 
      summary: Get cluster details
      x-rolesRequirements: "Cluster privileges: read"
      # ... rest of operation

Changes to role requirements don’t create changelog entries: you can update them without affecting version history.

Learn more about it in our help center

As always, don’t hesitate to reach out if you have any feedback.

Search in all APIs

Until now, running a search inside an API doc could only search the active doc. With search scopes, you can now search an entire hub without leaving the API doc. This one-click switch from a doc-only search to a global hub-search ensures your users no longer get stuck with an empty search results list and no follow-up actions.

You can change the default search scope (current API or global) in your hub settings. API users can individually activate/deactivate it in the API search modal.

Any requests or feedback? Reach out at hello@bump.sh!

Introducing Bump.sh MCP platform

APIs are no longer consumed only by humans. AI agents need to interact with them too, in a reliable and controlled way.

Most approaches today rely on naive OpenAPI-to-MCP transformations: individual endpoints exposed as tools, no orchestration, no security layer. The result is fragile, hard to maintain, and risky to run in production.

This is why we have built the Bump.sh MCP Platform: thanks to declarative workflows, you can now turn your APIs into deterministic, production-ready MCP servers. No guessing at runtime, no glue code, no credentials leaking to the LLM.

Not a simple OpenAPI-to-MCP conversion #

Bump.sh MCP servers expose ready-to-use workflows, not individual endpoints. You define the goals your API users can achieve (e.g. “book a train trip”), and the MCP server follows the workflow you defined, step by step.

This means you keep full control of the orchestration. AI tools consume fewer tokens, and the execution is predictable and repeatable.

Declarative by design #

Your MCP servers are based on workflow documents written in YAML. No hidden logic: everything is versionable, reviewable, and CI/CD-friendly. If you already use Bump.sh for API documentation, the experience is the same: update your definition, deploy from your CI, iterate with your team.

Two specifications are supported:

• Arazzo (the OpenAPI Initiative standard) if you already have OpenAPI definitions
• Flower, our lightweight specification for simple cases where no OpenAPI document is needed

Built-in security #

Credentials never go through the LLM. Store your API keys using Secrets: they stay server-side, only used to authenticate requests to your APIs.

MCP servers can be private, just like API docs. Manage who gets access directly in Bump.sh or using your own custom authentication server. Thanks to our integrated OAuth support, your users authenticate in one click, directly in their AI tools.

When an AI agent calls your MCP server, the data plane is the component that executes your workflows and forwards requests to your APIs. It runs on a server separated from Bump.sh’s main infrastructure, and no sensitive data is stored or logged. By default (on self-service plans), the data plane is hosted by Bump.sh. For custom plans, you can host it in your own infrastructure to get full control over your data.

Observability and debugging #

When things go wrong with API workflows, identifying the root cause can get tricky. Each MCP server comes with a built-in live debugger that lets you follow each step of a workflow execution in real time. Debug sessions are secured and fully historized: you know exactly who triggered a session and when, giving you a complete audit trail of your debugging activity.

Join the closed beta #

Bump.sh MCP Platform is currently in closed beta. Sign up here to get early access and help us shape the product.

If you have any questions or feedback, reach out to us anytime.

OpenAPI 3.2: partial support

The OpenAPI Initiative released a new version of their OpenAPI specification in September: OpenAPI 3.2.

If you didn’t hear about this new version, feel free to read our OpenAPI complete guide, updated for OpenAPI 3.2.

We started supporting some of the features brought by this new version:

• The QUERY method is now supported in both the documentation and the API Explorer.
• Servers can now have a name, which can be combined with the existing description field to provide users with a clear context about a server’s usage.
• Tags now offers a summary property. Behaving like our existing x-displayName vendor extension, it gives a way to display a group name in the documentation that is different from the tag name.
• summary can be added to responses when the level of detail doesn’t justify the use of the existing description field.
• Security schemes can now be deprecated.

OpenAPI 3.2 definition files can be deployed through your usual deployment process: using our Github Action, our CLI, our API (now in OpenAPI 3.2 ✨), or directly in your Bump.sh dashboard.

As always, you can reach out at hello@bump.sh for any questions/feedback.

Ask AI, Markdown rendering & llms.txt

Many API consumers now rely on AI tools to help them quickly discover API capabilities. Conversational tools such as ChatGPT or Claude can be fed with documentation intended for humans, but that extra “human context” gives them more noise, impacting the AI tools’ relevance and increasing token costs.

Our latest release provides these tools with the right context, empowering your API doc consumers through their favorite AI tools.

Ask AI #

Users can now easily ask questions about an API in their go-to conversational tools and get top-notch results. An “Ask AI” option has been added in documentation next to its introduction, x-topics, groups, and operations, offering access to ChatGPT and Claude with the right, narrowed-down context, alongside a one-click Markdown access.

Markdown rendering #

Bump.sh now offers an alternative context optimized for AI tools through Markdown rendering.

To access the Markdown version of a documentation, simply add .md at the end of the URL (or /source.md if you have a custom domain, when the URL is the root of your documentation).

On a documentation root (example truncated for visibility purposes).

# Bump.sh Api

## Description
This is version `1.0` of this API documentation. Last update on Nov 28, 2025.
This is the official Bump.sh API documentation. Obviously created with Bump.sh.

The Bump.sh API is a REST API. It enables you to [...]


## Servers
- Production: https://bump.sh/api/v1 ()


## Topics
- [Authentication](https://developers.bump.sh/authentication.md)


## Endpoints and operations

### [Branches](https://developers.bump.sh/group/endpoint-branches.md)
- [Promote branch as the default one](https://developers.bump.sh/operation/operation-patch-docs-parameter-branches-parameter-set_default.md)
- [Delete a branch](https://developers.bump.sh/operation/operation-delete-docs-parameter-branches-parameter.md)
- [List available branches](https://developers.bump.sh/operation/operation-get-docs-parameter-branches.md)
- [Create a new branch](https://developers.bump.sh/operation/operation-post-docs-parameter-branches.md)
### [Diffs](https://developers.bump.sh/group/endpoint-diffs.md)
- [...]


## Webhooks

### [Documentation change](https://developers.bump.sh/group/webhook-documentation-change.md)
- [Structure change](https://developers.bump.sh/operation/operation-webhookdocstructurechange.md)

For a specific operation (example truncated for visibility purposes).

# Create a new version

**POST /versions**

Deploy a new version for a given documentation, which will become the current version.


## Servers
- Production: https://bump.sh/api/v1 ()


## Authentication methods
- Authorization token
- Basic token (deprecated)


## Parameters

### Body: application/json (object)
The version creation request object
- **documentation** (string)
  UUID or slug of the documentation.
- [...]


## Responses
### 201
Documentation version successfully created

#### Body: application/json (object)
- **id** (string)
  Unique id of your version.
- [...]

llms.txt #

LLMs crawlers face similar challenges when crawling API docs: they don’t know what they’re looking for, and are flooded with an overabundance of information. llms.txt provides context, telling crawlers what information can be retrieved behind each page of a documentation.

llms.txt is available on both hubs and docs, by adding /llms.txt at the end of the URL.

On a documentation (example truncated for visibility purposes).

# Train Travel API

## Description
API for finding and booking train trips across Europe.

## Servers
- Production: https://api.example.com (Production)

## Topics
- [Getting started](https://bump.sh/bump-examples/doc/train-travel-api/topic/topic-getting-started.md)

## Endpoints and operations

### [Stations](https://bump.sh/bump-examples/doc/train-travel-api/group/endpoint-stations.md)
- [Get a list of train stations](https://bump.sh/bump-examples/doc/train-travel-api/operation/operation-get-stations.md)
- [...]

Don’t hesitate to reach out at hello@bump.sh if you have any questions/feedback.

New search experience

Search is at the core of our doc portal experience: your users need to easily find what they’re looking for, as it’s a key part of their API discovery.

Because we know how crucial it is, we recently completely rebuilt it to make it more relevant, faster, and more reliable.

Relevance #

Having quick results is useless if they aren’t relevant. We have redesigned our relevance rules from scratch to ensure that we provide your users with what they are really looking for:

• We now display a single list of results instead of several categories: users mostly look for operations, so displaying properties and other content “by default” didn’t always make sense.
• That global result list is ordered based on how closely the query matches a result item, and on its type. For example, for the same result weight, an operation will be favored over a property,
• The depth of a result is also taken into consideration to calculate its relevance, because we know that a first-level property is generally more important (and therefore searched) than a deep property,
• We removed the 5 results per type limit and now return all relevant results,
• Typos are also now better managed, ensuring relevant results even when the search query contains typos.

Performance #

Quickly finding the right information is one of the keys to a good API discovery, and search is part of it. Search speed has been increased by a factor of 10. This is particularly visible on larger hubs and complex documentation, reducing the time from almost a second to a few milliseconds, making the search experience instantaneous.

Usability #

All this work is under the hood, but we also made improvements to the search interface itself: the visual hierarchy of result items has been fully reworked to increase readability.

Any feedback? Reach out at hello@bump.sh!

Dark mode customization

Since we started providing dark mode, we applied filters to make your light mode color and logo blend in dark mode. The thing is, it isn’t always enough to ensure branding consistency. You can now define a custom logo and color dedicated to dark mode.

The option is available in your hub/documentation settings, under “Customize UI”.

It’s not mandatory: we’ll keep applying filters if you don’t want/need to customize it, but it gives you flexibility.

Any request or feedback? As usual, you can reach out at hello@bump.sh!

Documentation enhancements and fixes

While achieving milestones on larger projects, we’ve also made many quality-of-life enhancements and bug fixes. Here’s the changelog:

Enhancements:

• Custom meta tags can now be added to the head of your documentation,
• Dead anchors now redirect to their parent operation instead of the top of the documentation,
• In Embed mode, the search placeholders now specify their context (« Search API documentation » vs « Search hub »), so users can differentiate the global search from the documentaion portal search,
• A confirmation modal has been added to the API Explorer before sending destructive requests to avoid unwanted losses,
• The scrolling experience has been globally reworked to ensure its stability,
• Hub categories can now filter the documentation selector in the top navigation bar. This way, readers only see relevant docs from the same category, improving navigation for them and giving admins clearer control over doc organization,
• The browser window.title is now automatically updated when scrolling between operations to display the current navigation context,
• Highlights now work for subtitles inside x-topics, and global/operation descriptions,
• x-feedbackLink now works with Swagger 2.0 definition files,
• Groups in the navigation bar are now collapsible, to facilitate the navigation between groups containing many operations,
• The “add custom domain” module has been reworked to provide better explanations and error messages,
• Branches can now be sorted alphabetically in ascending and descending order,
• Skeletons for previews have been enhanced,
• x-state badges can now have custom colors,
• Accordions can now be added in Markdown using <details> and <summary> tags,
• A logo dedicated to dark mode can now be added to ensure brand consistency,
• The API Explorer beta is completed. 🎉 Thanks a lot to all of our testers. Your feedback has been invaluable and helped us build an even better feature for all.

Fixes:

• Fixed wrong breaking changes when the case of an HTTP header was modified but not its value,
• Fixed a trailing issue that caused the branch switch to return 404s in some contexts,
• Fixed multiple text alignments in documentation,
• Fixed an issue that prevented some descriptions from being displayed in the documentation when defined next to allOfs,
• Fixed an issue with alternatives preventing some generated examples from being displayed in some contexts,
• Fixed a bug with Mermaid rendering that prevented the use of ELK diagrams,
• Fixed an issue that displayed the “Show more” button in properties even when everything was already displayed in some contexts.

Feel free to reach out if you have any questions or features you think are missing from the product. Knock at hello@bump.sh.