bump-sh · scharrier · Mar 23, 2026 · Mar 20, 2026 · Mar 20, 2026 · Mar 20, 2026
diff --git a/frontend/styles/atoms/table.css b/frontend/styles/atoms/table.css
@@ -49,11 +49,15 @@ thead {
 }
 
 th, td {
-  padding: var(--spacing-4);
+  padding: var(--spacing-2) var(--spacing-4);
 }
 
 td {
   border-bottom: var(--border-default);
+
+  code {
+    white-space: nowrap;
+  }
 }
 
 tr {
@@ -64,12 +68,12 @@ tr {
   td:last-child {
     border-right: var(--border-default);
   }
-  
+
   &:last-child {
     td:first-child {
       border-bottom-left-radius: var(--border-radius-large);
     }
-  
+
     td:last-child {
       border-bottom-right-radius: var(--border-radius-large);
     }

diff --git a/frontend/styles/layouts/documentation.css b/frontend/styles/layouts/documentation.css
@@ -70,6 +70,10 @@
       max-width: 100%;
       max-height: 600px;
     }
+
+    table {
+      margin: 1em 0;
+    }
   }
 
   @media(max-width: 800px) {

diff --git a/src/_components/shared/sidebar/item.erb b/src/_components/shared/sidebar/item.erb
@@ -20,7 +20,7 @@
     <ul class="sidebar-sublist">
       <% @items.each do |item| %>
         <li>
-          <%= render Shared::Sidebar::Item.new(page: item, current: @current) %>
+          <%= render Shared::Sidebar::Item.new(page: item, current: @current, parent_id: category_id) %>
         </li>
       <% end %>
     </ul>

diff --git a/src/_components/shared/sidebar/item.rb b/src/_components/shared/sidebar/item.rb
@@ -1,7 +1,8 @@
 class Shared::Sidebar::Item < Bridgetown::Component
-  def initialize(page:, current:)
+  def initialize(page:, current:, parent_id: nil)
     @page = page
     @current = current
+    @parent_id = parent_id
     @resource = @page[:resource]
     @icon = @page[:icon]
     @label = @page[:label]
@@ -11,7 +12,11 @@ def initialize(page:, current:)
   end
 
   def category_id
-    @label.parameterize
+    if @parent_id
+      "#{@parent_id}--#{@label.parameterize}"
+    else
+      @label.parameterize
+    end
   end
 
   def is_parent

diff --git a/src/_data/sidebars/help.yml b/src/_data/sidebars/help.yml
@@ -11,6 +11,8 @@ resources:
         link: /getting-started/concepts/
       - label: Upload your first API definition
         link: /getting-started/upload-your-first-definition/
+      - label: Start your first MCP server
+        link: /getting-started/start-your-first-mcp-server/
       - label: Going further
         link: /getting-started/going-further/
     icon: zap
@@ -142,6 +144,31 @@ resources:
         link: /continuous-integration/cli/
       - label: API (advanced)
         link: /continuous-integration/api/
+  - type: category
+    label: MCP servers
+    link: /mcp-servers/
+    icon: mcp
+    items:
+      - label: Create and manage MCP servers
+        link: /mcp-servers/create-and-manage-mcp-servers/
+      - label: Deploy workflows
+        link: /mcp-servers/deploy-workflows/
+      - label: Use an MCP server
+        link: /mcp-servers/use-mcp-server/
+      - label: Access management
+        link: /mcp-servers/access-management/
+      - label: Secrets
+        link: /mcp-servers/secrets/
+      - label: Runtime expressions
+        link: /mcp-servers/runtime-expressions/
+      - label: Debug sessions
+        link: /mcp-servers/debug-sessions/
+      - label: Security
+        link: /mcp-servers/security/
+      - label: Specification support
+        items:
+          - label: Flower support
+            link: /mcp-servers/specification-support/flower-support/
   - type: category
     label: Organizations
     link: /organizations/

diff --git a/src/_help/continuous-integration/cli.md b/src/_help/continuous-integration/cli.md
@@ -15,6 +15,10 @@ Using [OpenAPI](https://spec.openapis.org/) (v3.x and v2.0) or [AsyncAPI](https:
 
 Under the hood, it uses the API of [developers.bump.sh](https://developers.bump.sh). And is built with the [`oclif`](https://oclif.io) framework in Typescript.
 
+> You can use the CLI to interact with your MCP server:
+> see how to [deploy a workflow document on your MCP server](#deploy-a-workflow-document-on-your-mcp-server).
+{: .info}
+
 ## Installation
 
 The Bump.sh CLI is a node package currently distributed via NPM. This means you must have the Node v20+ interpreter installed on your computer or CI servers.
@@ -72,7 +76,7 @@ $ bump --help
 The Bump.sh CLI is used to interact with your API documentation hosted on Bump.sh by using the API of developers.bump.sh
 
 VERSION
-  bump-cli/2.9.2 linux-x64 node-v20.18.1
+  bump-cli/2.9.12 linux-x64 node-v20.18.1
 
 USAGE
   $ bump [COMMAND]
@@ -113,10 +117,14 @@ bump deploy path/to/api-document.yml --doc my-documentation --token $DOC_TOKEN
 
 You can also deploy a given API document to a different branch of your documentation with the `--branch <branch-name>` parameter. Please note the branch will be created if it doesn’t exist. More details about the branching feature are available on [this dedicated help page](/help/branching). E.g. deploy the API document to the `staging` branch of the documentation:
 
+
 ```shell
 bump deploy path/to/api-document.yml --doc my-documentation --token $DOC_TOKEN --branch staging
 ```
 
+> You can also use this command to interact with your MCP server, see [how to deploy a workflow definition](#deploy-a-workflow-document-on-your-mcp-server).
+{: .info}
+
 #### Deploy a folder all at once
 
 If you already have a hub in your [Bump.sh](https://bump.sh) account, you can automatically create documentation and deploy it into that hub by publishing a whole directory containing multiple API documents in a single command:
@@ -159,10 +167,24 @@ bump deploy path/to/api-document.yml --dry-run --doc my-documentation --token $D
 
 Please check `bump deploy --help` for more usage details.
 
+#### Deploy a workflow document on your MCP server
+
+Use the `bump deploy` command with the `--mcp-server` flag to deploy a [Flower](/help/mcp-servers/specification-support/flower-support/) or Arazzo (soon) workflow document.
+
+```shell
+bump deploy path/to/flower-document.yml --mcp-server my-mcp-server-id-or-slug --token $BUMP_TOKEN
+```
+
+> You can find your `mcp-server-id-or-slug` and `$BUMP_TOKEN` API key in your MCP server settings.
+{: .info}
+
+This feature is currently in closed beta.
+Request an early access at [hello@bump.sh](mailto:hello@bump.sh)
+
 ### The `diff` command
 
 Using the `diff` command can help to spot differences between the local API
-document and the latest deployed version. 
+document and the latest deployed version.
 
 #### Public API diffs
 
@@ -180,7 +202,7 @@ Modified: GET /consommations
 By default the command will always exit with a successful return code. If you
 want to use this command in a CI environment and want the command to fail **in
 case of a breaking change**, you will need to add the `--fail-on-breaking` flag
-to your diff command. 
+to your diff command.
 
 By default if the environment variable `CI=1` is present (in most continuous
 integration environment), the flag will be enabled. In that case you can disable
@@ -254,7 +276,7 @@ Please check `bump preview --help` for more usage details
 
 ### The `overlay` command
 
-The [Overlay Specification](https://spec.openapis.org/overlay/v1.0.0.html) from the OpenAPI Initiative makes it possible to modify the content of an API definition by adding a layer on top of it. That layer helps adding, removing or changing some or all of the content of the original definition. 
+The [Overlay Specification](https://spec.openapis.org/overlay/v1.0.0.html) from the OpenAPI Initiative makes it possible to modify the content of an API definition by adding a layer on top of it. That layer helps adding, removing or changing some or all of the content of the original definition.
 
 The `bump overlay` command takes an original API document (an OpenAPI or AsyncAPI document), applies the changes from the overlay document, and outputs a modified version. No changes are made directly to the original document.
 

diff --git a/src/_help/continuous-integration/github-actions.md b/src/_help/continuous-integration/github-actions.md
@@ -23,6 +23,10 @@ Then you can pick from one of the three following API workflow files.
 - [Deploy documentation only](#deploy-documentation-only)
 - [Diff on pull requests only](#diff-on-pull-requests-only)
 
+> You can use the GitHub Action to interact with your MCP server:
+> see how to [deploy a workflow document on your MCP server](#deploy-a-workflow-document-for-your-mcp-server).
+{: .info}
+
 ### Deploy documentation & diff on pull requests
 
 This is the [recommended workflow](/help/continuous-integration#integrate-with-your-ci), which will create two steps in your automation flow: a validation & diff step on code reviews, followed by a deployment step on merged changes.
@@ -154,7 +158,7 @@ jobs:
 
 ### Deploy a single documentation on a hub
 
-You can deploy a documentation inside a hub by adding a `hub` slug or id. 
+You can deploy a documentation inside a hub by adding a `hub` slug or id.
 Note that the documentation will be automatically created if it doesn't exist by using the slug you defined with the `doc:` input.
 
 `.github/workflows/bump-deploy.yml`
@@ -249,6 +253,39 @@ In order to deploy the 3 services API definition files from this folder (`privat
           filename_pattern: '*-api-{slug}-service'
 ```
 
+### Deploy a workflow document for your MCP server
+
+Replace `BUMP_MCP_SERVER_ID_OR_SLUG`with the slug (or id) of your MCP server. It can be found in your MCP server settings. Don't forget to replace the `file` path with the path to your [Flower](/help/mcp-servers/specification-support/flower-support/) or Arazzo (soon) workflow document. 
+
+`.github/workflows/bump.yml`
+
+```yaml
+name: Deploy workflow document for your MCP server
+
+on:
+  push:
+    branches:
+      - main
+
+jobs:
+  deploy-workflow-document:
+    name: Deploy workflow document for MCP server on Bump.sh
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+      - name: Deploy workflow document
+        uses: bump-sh/github-action@v1
+        with:
+          command: deploy
+          mcp_server: <BUMP_MCP_SERVER_ID_OR_SLUG>
+          token: ${{secrets.BUMP_TOKEN}}
+          file: doc/flower-document.yml
+```
+
+This feature is currently in closed beta.
+Request an early access at [hello@bump.sh](mailto:hello@bump.sh)
+
 ## Inputs
 
 * `doc` (required unless you deploy a directory on a hub): Documentation slug or id. Can be found in the documentation settings on [your API dashboard](https://bump.sh/dashboard).
@@ -267,7 +304,7 @@ In order to deploy the 3 services API definition files from this folder (`privat
 
 * `command`: Bump.sh command to execute. _Default: `deploy`_
 
-  * `deploy`: deploy a new version of the documentation
+  * `deploy`: deploy a new version of the documentation (or MCP server ✨)
   * `diff`: automatically comment your pull request with the API diff
   * `dry-run`: dry-run a deployment of the API definition file
   * `preview`: create a temporary preview
@@ -276,6 +313,8 @@ In order to deploy the 3 services API definition files from this folder (`privat
 
 * `fail_on_breaking` (optional): Mark the action as failed when a breaking change is detected with the diff command. This is only valid with `diff` command.
 
+* `mcp_server` (required to deploy workflow documents on an MCP server): MCP Server id or slug. It can be found in MCP server settings. This is only valid with the `deploy` command (default command).
+
 ## Contributing
 
 Bug reports and pull requests are welcome on GitHub at [https://github.com/bump-sh/github-action](https://github.com/bump-sh/github-action). This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the [Contributor Covenant](http://contributor-covenant.org) code of conduct.

diff --git a/src/_help/continuous-integration/index.md b/src/_help/continuous-integration/index.md
@@ -27,6 +27,12 @@ We advise to setup two steps in your automation flow:
 - a [**validation** and **diff** step](#api-diff--validation-of-the-documentation-file) during development
 - followed by a [**deployment** step](#deploy-your-api-document) on production merges.
 
+
+> You can use the CI to interact with your MCP server,
+> see examples with [the CLI](/help/continuous-integration/cli#deploy-a-workflow-document-on-your-mcp-server)
+> or [the GitHub Action](/help/continuous-integration/github-actions#deploy-a-workflow-document-for-your-mcp-server).
+{: .info}
+
 ### API diff & validation of the documentation file
 
 When suggesting a change to your API, you probably follow a pull request flow (also known as merge request) and make the changes on a development branch. You can integrate Bump.sh at this stage to generate an API diff or only validate your changed API document.
@@ -49,6 +55,10 @@ The GitHub action example uses a dedicated action we crafted especially for you.
 - [API diff & validation step](/help/continuous-integration/github-actions/#diff-on-pull-requests-only)
 - [Deploy to your documentation](/help/continuous-integration/github-actions/#deploy-documentation-only)
 
+The GitHub Action can be used to interact with your MCP server:
+
+- [Deploy a workflow document for your MCP server](/help/continuous-integration/github-actions/#deploy-a-workflow-document-for-your-mcp-server).
+
 ### Other Continuous Integration tools (CI)
 
 The CI examples are here to help you build a similar process described with our GitHub action. We try to keep some specially crafted scripts for you to build the same experience for your own tools:
@@ -62,7 +72,7 @@ The CI examples are here to help you build a similar process described with our
 The CLI can be used in your custom CI scripts with the two available recommendeded steps:
 
 - [`bump diff`](/help/continuous-integration/cli/#api-diff-of-your-changes) to check the changes & validate the API document
-- [`bump deploy`](/help/continuous-integration/cli/#deploy-a-file) to publish to your Bump.sh documentation
+- [`bump deploy`](/help/continuous-integration/cli/#deploy-a-file) to publish to your Bump.sh documentation, or MCP server
 
 
 ## Recommendation

diff --git a/src/_help/getting-started/concepts.md b/src/_help/getting-started/concepts.md
@@ -10,7 +10,26 @@ The terminology used here aims to be as accurate as possible, but you may encoun
 
 ![Bump.sh global workflow including deploying, release and access management](/docs/images/help/bump-sh-global-workflow.png)
 
-## API definition
+## Global concepts
+
+### Specification
+
+Specifications are the official standards used to describe, among other things:
+- an API (OpenAPI, AsyncAPI, ...),
+- an API workflow (Flower, Arazzo, ...).
+These standards outline a set of elements and rules to follow when writing an API definition.
+
+We support OpenAPI, AsyncAPI (up to 2.6), and Flower (our internal workflow specification). Arazzo will be supported soon. To learn more about the supported specifications, we have written dedicated guides on [OpenAPI](/guides/openapi) and [AsyncAPI](/guides/asyncapi/what-is-asyncapi/). We also made a guide on [Flower](/help/mcp-servers/specification-support/flower-support), our own workflow standard.
+
+### Deployment
+
+A deployment is the processing of an API or a workflow document by Bump.sh: after the upload, it validates the definition against its specification, analyses its content and either:
+- makes it available on the MCP server, for a workflow document,
+- prepares the [release](/help/publish-documentation/deploy-and-release-management/), for an API document.
+
+## API documentation
+
+### API definition
 
 An API definition is the representation of an API written in compliance with an existing specification.
 It is sometimes referred to as an API schema, API contract, or even [API specification](/help/getting-started/concepts/#specification) (which is something different).
@@ -19,33 +38,23 @@ As of today, Bump.sh supports the following specifications: [OpenAPI (Swagger)](
 
 We provide a detailed introduction to API definitions [through this guide](/guides/api-basics/api-contracts-extended-introduction/).
 
-## API contract
+### API contract
 
 An API contract represents the use of an API definition when it defines an agreement, a contract between API developers, its consumers, how it is used, and the tools that surround it.
 
-## API document
+### API document
 
 An API document refers to the file containing an API definition.
 
-## Specification
-
-Specifications are the official standards that define a format for describing an API, such as OpenAPI or AsyncAPI. These standards outline a set of elements and rules to follow when writing an API definition.
-
-To learn more about the supported specifications, we have written dedicated guides on [OpenAPI](/guides/openapi) and [AsyncAPI](/guides/asyncapi/what-is-asyncapi/).
-
-## Deployment
-
-A deployment is the processing of an API document by Bump.sh: after the upload, it validates the definition against its specification, analyses its content and prepares the [release](/help/publish-documentation/deploy-and-release-management/).
-
-## Release
+### Release
 
 The step following a successful deploy. During the [release](/help/publish-documentation/deploy-and-release-management/), the documentation is updated, the changelog reflects the related changes, and notifications, if configured, are sent out. The release step can be automatic, or manual.
 
-## API change
+### API change
 
 An API change refers to a change in the structure of an API. After the release of an API definition, it is represented by a new entry in the [API changelog](/help/changes-management/changelog/).
 
-## Breaking change
+### Breaking change
 
 Breaking changes are the ones your API consumers should not miss and are highlighted in the changelog. Here is a non-exhaustive list of criteria that help us determine if a change is breaking or not:
 - Renaming/Deleting an endpoint or operation
@@ -55,6 +64,24 @@ Breaking changes are the ones your API consumers should not miss and are highlig
 - Marking an existing property as required
 - Add or delete a security requirement
 
-## Changelog
+### Changelog
 
 After each deployment, Bump.sh updates the documentation's [changelog](/help/changes-management/changelog/), listing all API changes between the current deployment and the previous one. If the "Track all changes" option is enabled, the changelog will also display changes in the documentation.
+
+## MCP servers
+
+### MCP server
+
+An MCP (Model Context Protocol) server makes your API workflows available to LLM-based applications and agents. It processes API workflow documents and handles the runtime execution of these workflows. The MCP standard is supported by many AI tools: adding an MCP server is often just a matter of pasting the server URL into the "Connectors" or "Tools" section of the AI app.
+
+### Workflow
+
+A workflow is a chain of multiple API calls designed to achieve specific business goals, rather than just providing a list of endpoints.
+
+### Workflow definition
+
+A workflow definition is the representation of an API workflow written in compliance with a workflow specification like Arazzo or Flower. It describes a sequence of API operations and the goal of this sequence, their dependencies, and the data flow between them (inputs and outputs).
+
+### Workflow document
+
+A workflow document refers to the file containing a workflow definition. These documents are deployed to Bump.sh where they're validated, processed, and made available on MCP servers for execution.