DEV Community: Bhavy Shekhaliya

How to Update MCP Tools When the Underlying API Changes

Bhavy Shekhaliya — Sun, 30 Aug 2026 02:54:20 +0000

An MCP tool is only as reliable as the API contract behind it.

If the underlying API changes, the tool can break even when the MCP server is still running. A renamed field, a new required parameter, a changed enum, a stricter permission rule, or a different response shape can all affect how an AI client calls the tool.

For API-backed MCP servers, the safe update process is:

detect the API change
identify affected MCP tools
classify the change as compatible or breaking
update schemas, names, descriptions, and authentication details
test valid and invalid calls
publish a versioned update
keep a rollback path
monitor the first production calls

The goal is boring in the best way: existing users should not wake up to broken tool calls because an API route changed quietly.

Start by treating MCP tools as contracts

An MCP tool is not a random wrapper around an endpoint. It is a contract exposed to an AI client.

That contract includes:

tool name
tool description
input schema
required fields
optional fields
enums
default behavior
response shape
authentication expectations
side effects
error behavior

If the underlying API changes any of those things, the MCP tool may need an update.

For example, this API change looks small:

- GET /v1/customers/{id}
+ GET /v1/customers/{customer_id}

But if the MCP tool schema still expects id, clients may call the tool with the wrong field.

Another small-looking change:

- status: "open" | "closed"
+ status: "open" | "pending" | "resolved"

Can affect validation, tool descriptions, examples, and the user's mental model.

The MCP server may still initialize. The tool may still be discoverable. The break appears when real calls start failing or returning unexpected data.

Create an API change checklist

When the API changes, scan for changes that affect MCP tools.

I would check:

paths
HTTP methods
path parameters
query parameters
request bodies
required fields
field names
field types
enum values
pagination behavior
response objects
error objects
authentication scheme
required scopes
tenant or workspace rules
rate limits
timeout behavior
deprecated endpoints
removed endpoints

This is the boring list that saves production pain.

If you use OpenAPI or Swagger, diff the API definition. If the source is a Postman collection, compare the exported requests and variables. If your MCP server was hand-written, compare the code and tool schemas directly.

The important part is to map API changes back to MCP capability changes.

Classify changes before updating tools

Do not treat every API change the same way.

I usually classify changes into three groups.

Compatible changes can often be released with normal testing:

adding an optional response field
adding a new optional input
improving descriptions
exposing a new read-only tool
adding a new endpoint without changing existing tools

Review-required changes need closer testing:

changing default pagination limits
adding new enum values
changing error messages
tightening validation
changing rate-limit behavior
adding a write tool
changing authentication scopes

Breaking changes need migration planning:

renaming a tool
removing a tool
removing an endpoint
changing a required input
changing a field type
removing enum values
changing response shape
moving from one auth model to another
changing tenant or role behavior

This classification helps your team decide whether the update can ship quietly or needs coordination with users.

Update input schemas first

The input schema is where many API changes become visible to the AI client.

Suppose your API changes a ticket update endpoint:

PATCH /v1/tickets/{ticket_id}/status

{
-  "status": "closed"
+  "status": "resolved",
+  "resolution_reason": "fixed"
}

Your MCP schema may need to change from:

{
  "type": "object",
  "properties": {
    "ticket_id": {
      "type": "string"
    },
    "status": {
      "type": "string",
      "enum": ["open", "closed"]
    }
  },
  "required": ["ticket_id", "status"]
}

To:

{
  "type": "object",
  "properties": {
    "ticket_id": {
      "type": "string",
      "description": "The ticket to update."
    },
    "status": {
      "type": "string",
      "enum": ["open", "pending", "resolved"],
      "description": "The new ticket status."
    },
    "resolution_reason": {
      "type": "string",
      "description": "Reason for resolving the ticket."
    }
  },
  "required": ["ticket_id", "status"]
}

Then decide if resolution_reason should become required when status is resolved. If your schema cannot express that cleanly, explain the rule in the tool description and enforce it in the API.

The schema should guide the client. The API should still validate the request.

Update descriptions when behavior changes

Descriptions are part of the interface.

If the underlying API behavior changes, the tool description may also need to change.

Example before:

Close a support ticket.

Example after:

Mark a support ticket as resolved after the user confirms the resolution. Requires a resolution reason when status is resolved.

The second version tells the client when the tool is appropriate and what extra context it needs.

Review descriptions when:

the tool changes data
a field becomes required
a field has new accepted values
the response includes new states
a permission rule changes
the tool should be used later or earlier in the workflow
the operation becomes risky

This is especially important for AI clients because they choose tools based on names, descriptions, and schemas. A technically correct schema with an outdated description can still cause bad calls.

Recheck authentication and authorization

API changes often touch authentication quietly.

A tool that worked yesterday may fail after:

a new scope requirement
a new tenant check
an OAuth audience change
a token expiry rule change
an API key permission update
a stricter record-level authorization check
a move from one auth header to another

Test the happy path, then test failure paths:

missing API key
invalid API key
expired Bearer token
revoked OAuth access
insufficient scope
wrong tenant
authenticated user without record access
authenticated user without action permission

Authentication success does not guarantee authorization success. A user can be logged in and still be blocked from reading a record, updating billing, exporting data, or changing workspace settings.

For API-backed MCP, the original API should remain the authority for identity, tenant boundaries, role checks, scopes, and record permissions.

Check response changes too

Request schemas get most of the attention, but response changes can break workflows too.

Watch for:

renamed response fields
removed response fields
fields changing type
dates changing format
IDs changing format
nested objects becoming arrays
arrays becoming paginated objects
error bodies changing shape
empty results changing from [] to null
large response payloads

An AI client may rely on a response field to decide the next step.

For example, if the response changes from:

{
  "status": "open",
  "assignee_id": "usr_123"
}

To:

{
  "state": "active",
  "owner": {
    "id": "usr_123"
  }
}

Your tool may still return valid JSON, but the workflow has changed. Test downstream prompts or agent actions that depend on the old shape.

Version the API and MCP configuration together

There are three layers to track:

the upstream API version
the MCP configuration version
the MCP protocol/client compatibility layer

Do not blur them.

The API version tells you what the backend supports. The MCP configuration version tells you which tools, schemas, descriptions, resources, and prompts are exposed. The protocol/client layer tells you whether the MCP server and client can communicate correctly.

For each release, record:

release:
  api_source: openapi-2026-08-26.yaml
  api_environment: production
  mcp_configuration: support-tools-v12
  changed_tools:
    - update_ticket_status
    - list_customer_tickets
  change_type: review-required
  rollback_to: support-tools-v11

You do not need this exact format. You do need traceability.

When a user reports "the agent can no longer update a ticket," you should be able to find which API change and which MCP configuration shipped together.

Test old workflows before publishing

Every update should include regression tests for existing workflows.

Use saved fixtures or test prompts such as:

Find open tickets for customer cus_123.

Update ticket tick_456 to resolved with reason "customer confirmed fix."

Show the latest unpaid invoice for customer cus_123.

Then test at three levels:

tool discovery: does the client see the expected tools?
schema validation: do valid and invalid inputs behave correctly?
workflow behavior: can the client complete the same user task?

Also test failure cases:

missing required field
invalid enum
unauthorized credential
wrong tenant
missing record
upstream timeout
rate limit
changed response shape

If you only test the newly changed tool, you may miss a workflow that depends on two or three tools together.

Keep rollback realistic

Rollback is not always as simple as restoring the previous MCP configuration.

If you changed only tool descriptions or selected operations, restoring an older configuration may be enough.

If the upstream API removed a field or endpoint, the old MCP configuration may still fail because it depends on the old API contract.

Ask before every release:

Can we restore the previous MCP configuration?
Does the previous API behavior still exist?
Did a database migration remove required data?
Did auth scopes change permanently?
Are old enum values still accepted?
Can both old and new clients run during migration?
Who owns the rollback decision?

Safe rollback usually requires both sides: MCP configuration and API compatibility.

How 0mcp helps with safer updates

With 0mcp, teams can import supported Swagger, OpenAPI, or Postman definitions, select which API operations are exposed, edit tool names and descriptions, test in the Playground, and host the MCP server over Streamable HTTP.

For updates, the useful part is configuration versioning. Teams can save configuration versions, review changes, and restore an earlier version when needed. Saving an updated MCP configuration changes the hosted server without requiring a rebuild or changing its URL.

There is still an important boundary: 0mcp does not replace your API's own compatibility and authorization work. The original API remains responsible for business logic, tenant checks, permissions, pagination, rate limits, and validation.

0mcp currently supports hosted Streamable HTTP servers, not local stdio servers. Existing API authentication continues through API key, Bearer token, or OAuth pass-through, and customer credentials are passed through during requests rather than stored by 0mcp.

For the full website version of this topic, see MCP server versioning and safe updates.

Mapping API Path, Query, Header, and Body Parameters to MCP Tool Schemas

Bhavy Shekhaliya — Sat, 29 Aug 2026 03:57:47 +0000

An API operation can receive input from several places.

Path parameters identify the record. Query parameters filter or paginate the result. Headers carry metadata or authentication. The request body contains structured data for create and update operations.

An MCP tool should give the AI client one clear input schema.

That is the mapping problem:

HTTP API inputs
  path + query + headers + body

become

MCP tool input
  one structured schema the AI client can understand

This tutorial walks through that mapping with practical examples. The goal is to make the tool easy for an AI client to call without hiding the real API contract.

Example API operation

Imagine a project-management API with this endpoint:

PATCH /workspaces/{workspace_id}/projects/{project_id}/tasks/{task_id}

It updates one task.

The API accepts:

path parameters for workspace_id, project_id, and task_id;
query parameters such as notify_assignee;
a request body with the fields to update;
authentication through a Bearer token header;
an optional request header such as Idempotency-Key.

A shortened OpenAPI-style version might look like this:

paths:
  /workspaces/{workspace_id}/projects/{project_id}/tasks/{task_id}:
    patch:
      operationId: updateTask
      summary: Update a task
      description: "Update the title, status, assignee, or due date for one task."
      parameters:
        - name: workspace_id
          in: path
          required: true
          schema:
            type: string
        - name: project_id
          in: path
          required: true
          schema:
            type: string
        - name: task_id
          in: path
          required: true
          schema:
            type: string
        - name: notify_assignee
          in: query
          required: false
          schema:
            type: boolean
            default: false
        - name: Idempotency-Key
          in: header
          required: false
          schema:
            type: string
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              properties:
                title: ""
                  type: string
                status:
                  type: string
                  enum: [todo, in_progress, blocked, done]
                assignee_id:
                  type: string
                due_date:
                  type: string
                  format: date
              minProperties: 1
      security:
        - bearerAuth: []

The API shape is split across the HTTP request. The MCP tool should present the editable parts in one schema.

Step 1: name the tool from the operation, not the route

The route is useful for the adapter, but it is not a good tool name.

This is weak:

{
  "name": "patch_workspaces_projects_tasks"
}

This is clearer:

{
  "name": "update_task"
}

If your API has several update operations, use the object and action to remove ambiguity:

update_task
update_task_status
assign_task
reschedule_task

The right name depends on what the endpoint actually does. If the endpoint updates many fields, update_task may be correct. If the endpoint only changes status, update_task_status is better.

Step 2: bring path parameters into the input schema

Path parameters usually identify the exact resource being addressed. In an MCP tool schema, they are usually required fields.

From the route:

/workspaces/{workspace_id}/projects/{project_id}/tasks/{task_id}

The tool needs:

{
  "workspace_id": "wrk_123",
  "project_id": "prj_456",
  "task_id": "tsk_789"
}

In the MCP tool schema:

{
  "type": "object",
  "properties": {
    "workspace_id": {
      "type": "string",
      "description": "The workspace that contains the project."
    },
    "project_id": {
      "type": "string",
      "description": "The project that contains the task."
    },
    "task_id": {
      "type": "string",
      "description": "The task to update."
    }
  },
  "required": ["workspace_id", "project_id", "task_id"]
}

Keep the path identifiers explicit. Do not collapse them into one generic id field if the API needs all three values. The AI client should not guess which ID belongs to which level.

Step 3: map query parameters as filters and options

Query parameters often change how the operation behaves:

filtering;
sorting;
pagination;
flags;
optional behavior.

In the example, notify_assignee controls whether the API sends a notification after the update.

That should appear as an optional tool input:

{
  "notify_assignee": {
    "type": "boolean",
    "description": "Whether to notify the assigned user after the task is updated.",
    "default": false
  }
}

For list operations, query parameters may be the main tool inputs:

GET /customers/{customer_id}/tickets?status=open&limit=20&cursor=abc

The MCP schema might expose:

{
  "type": "object",
  "properties": {
    "customer_id": {
      "type": "string",
      "description": "The customer whose tickets should be listed."
    },
    "status": {
      "type": "string",
      "enum": ["open", "pending", "closed"],
      "description": "Optional ticket status filter."
    },
    "limit": {
      "type": "integer",
      "minimum": 1,
      "maximum": 100,
      "default": 20,
      "description": "Maximum number of tickets to return."
    },
    "cursor": {
      "type": "string",
      "description": "Pagination cursor from a previous response."
    }
  },
  "required": ["customer_id"]
}

Good query mapping keeps list tools bounded. If a search endpoint accepts unlimited free-form parameters, the agent may produce slow, broad, or invalid calls.

Step 4: treat authentication headers separately

Headers are tricky because some are normal inputs and some are credentials.

Authentication headers should not become normal tool inputs.

Do not expose this:

{
  "authorization": {
    "type": "string",
    "description": "Bearer token for the API request."
  }
}

That would make the credential model-visible.

Instead, the tool input should stay focused on the business operation:

{
  "workspace_id": "wrk_123",
  "project_id": "prj_456",
  "task_id": "tsk_789",
  "status": "blocked"
}

The adapter or hosted MCP runtime should receive credentials through the authentication path and forward them to the upstream API:

Authorization: Bearer <runtime credential>

The upstream API still enforces identity, tenant, role, record, and action permissions. The MCP schema should not become a place where the model supplies secrets.

0mcp supports API key, Bearer token, and OAuth pass-through. Credentials are supplied through the MCP client at request time and passed to the original API rather than stored by 0mcp. That keeps the generated tool schema focused on the task inputs.

Step 5: decide what to do with non-auth headers

Some headers are not secrets. They may still matter.

Examples:

Idempotency-Key;
X-Request-Id;
Accept-Language;
If-Match;
X-Client-Version.

Do not automatically expose every header to the AI client. Ask what role the header plays.

Expose a header as a tool input when:

the caller can safely provide it;
it changes behavior in a useful way;
the value is not secret;
the format can be validated;
the AI client understands why it exists.

For Idempotency-Key, you may decide to generate it inside the MCP server instead of asking the AI client to provide it. That reduces friction and avoids duplicate-write bugs.

For Accept-Language, you might expose language as a business-friendly field rather than the raw HTTP header:

{
  "language": {
    "type": "string",
    "enum": ["en", "es", "fr"],
    "description": "Preferred language for localized response text."
  }
}

Then the adapter maps it to:

Accept-Language: en

The schema should describe the product-level input, not force the agent to think in low-level HTTP details when a cleaner field works.

Step 6: map the request body into structured inputs

For create and update operations, the request body often becomes the largest part of the tool schema.

From the PATCH /tasks/{task_id} example, the request body allows:

title;
status;
assignee_id;
due_date.

The combined MCP input schema can include path, query, and body fields together:

{
  "name": "update_task",
  "description": "Update the title, status, assignee, or due date for one task. Use this only after the user has identified the workspace, project, task, and requested change.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "workspace_id": {
        "type": "string",
        "description": "The workspace that contains the project."
      },
      "project_id": {
        "type": "string",
        "description": "The project that contains the task."
      },
      "task_id": {
        "type": "string",
        "description": "The task to update."
      },
      "title": {
        "type": "string",
        "description": "New task title."
      },
      "status": {
        "type": "string",
        "enum": ["todo", "in_progress", "blocked", "done"],
        "description": "New task status."
      },
      "assignee_id": {
        "type": "string",
        "description": "User ID of the new assignee."
      },
      "due_date": {
        "type": "string",
        "format": "date",
        "description": "New due date in YYYY-MM-DD format."
      },
      "notify_assignee": {
        "type": "boolean",
        "default": false,
        "description": "Whether to notify the assignee after the update."
      }
    },
    "required": ["workspace_id", "project_id", "task_id"]
  }
}

Notice that the body fields are optional in the schema because this is a patch operation. But the API should still reject a request that updates nothing. You can express that with validation logic if the schema format you use cannot represent it cleanly.

For example:

const updateFields = ["title", "status", "assignee_id", "due_date"];

if (!updateFields.some((field) => input[field] !== undefined)) {
  throw new Error("Provide at least one task field to update.");
}

The tool should guide the model toward valid updates without making every field required.

Step 7: handle naming conflicts deliberately

Naming conflicts happen often when you combine path, query, header, and body inputs into one schema.

Example:

PATCH /projects/{id}

Request body:

{
  "id": "external-project-id",
  "name": "New project name"
}

Now there are two id values:

path id, which identifies the project being updated;
body id, which might represent an external ID or imported ID.

Do not expose both as id.

Use names that preserve meaning:

{
  "project_id": "prj_123",
  "external_project_id": "ext_999",
  "name": "New project name"
}

Other common conflicts:

user_id in both path and body;
status in query and body;
version in header and body;
limit in query and nested request body;
id fields inside nested objects.

When in doubt, name the field by its role in the operation. The model should know whether it is selecting a resource, filtering a result, updating a value, or controlling request behavior.

Step 8: build the API request from the tool input

After the AI client sends the MCP tool input, the handler maps it back to the API request.

For update_task, the handler might do this:

async function updateTaskTool(input, auth) {
  validateUpdateTaskInput(input);

  const url = new URL(
    `/workspaces/${input.workspace_id}/projects/${input.project_id}/tasks/${input.task_id}`,
    API_BASE_URL
  );

  if (input.notify_assignee !== undefined) {
    url.searchParams.set("notify_assignee", String(input.notify_assignee));
  }

  const body = {};

  for (const field of ["title", "status", "assignee_id", "due_date"]) {
    if (input[field] !== undefined) {
      body[field] = input[field];
    }
  }

  const response = await fetch(url, {
    method: "PATCH",
    headers: {
      Authorization: `Bearer ${auth.accessToken}`,
      "Content-Type": "application/json",
      Accept: "application/json"
    },
    body: JSON.stringify(body),
    signal: AbortSignal.timeout(10000)
  });

  return mapTaskResponse(response);
}

This keeps the direction clear:

the tool schema receives product-level inputs;
the handler validates those inputs;
the handler places each value in the correct HTTP location;
authentication comes from runtime context;
the API response becomes the tool result.

Avoid handlers that accept arbitrary paths, methods, headers, or bodies from the model. That turns a structured MCP tool back into a generic API proxy.

Step 9: validate before calling the API

Validation should happen before the adapter sends the API request.

At minimum, check:

required path identifiers exist;
string, boolean, integer, array, and object types are correct;
enum values are allowed;
date, email, URL, and ID formats match expectations;
pagination limits stay within bounds;
at least one update field exists for patch operations;
body fields do not contain unsupported properties;
non-auth headers are safe and well formed;
authentication is present in runtime context.

Some validation belongs in the MCP schema. Some belongs in code. Some still belongs in the upstream API.

The upstream API remains the final enforcement point for business rules. The MCP layer should prevent obvious bad calls and make errors easier to understand, but it should not replace the API's authorization and data validation.

Step 10: map responses and errors clearly

For a successful update, the API might return:

{
  "id": "tsk_789",
  "status": "blocked",
  "title": "Fix webhook retries",
  "assignee_id": "usr_456",
  "updated_at": "2026-08-26T10:00:00Z"
}

The MCP tool result should preserve the useful fields:

{
  "task_id": "tsk_789",
  "status": "blocked",
  "title": "Fix webhook retries",
  "assignee_id": "usr_456",
  "updated_at": "2026-08-26T10:00:00Z"
}

For errors, keep the categories distinct:

400 means the request was invalid;
401 means authentication failed;
403 means the caller lacks permission;
404 means the resource was not found;
409 may mean a version or state conflict;
429 means the API rate limit was hit;
5xx means the upstream API failed.

Do not turn every error into "Tool failed." The agent and the developer both need the failure to say what kind of problem happened.

Step 11: test the mapping with real tool calls

Test each input location separately.

For path parameters:

omit workspace_id;
use a valid project_id with an invalid task_id;
try a task ID that belongs to another workspace.

For query parameters:

omit optional fields;
pass notify_assignee: true;
pass the wrong type, such as "yes" instead of true;
test pagination boundaries on list tools.

For headers:

test missing credentials;
test expired credentials;
test credentials without write permission;
test a generated idempotency key if the operation supports it.

For request bodies:

update one field;
update multiple fields;
send an invalid enum;
send an unsupported field;
send an empty patch body.

For responses:

verify the result contains the fields the AI client needs;
check empty and missing-resource cases;
check rate-limit and timeout behavior;
confirm sensitive headers, tokens, and internal debugging fields are not returned.

Testing should answer a larger question than "does the API return 200?" An AI client has to discover the tool, send valid structured input, get a useful result, and understand failures.

How this works in 0mcp

With 0mcp, the same mapping starts from a supported API definition or Postman collection.

The hosted workflow is:

import a Swagger 2.0, OpenAPI 3.0, OpenAPI 3.1, or Postman definition;
review validation warnings and detected operations;
select the API functions that should become AI-facing capabilities;
create or update tools, resources, and prompts;
edit tool names and descriptions where the imported wording needs work;
use API key, Bearer token, or OAuth pass-through at runtime;
test the hosted Streamable HTTP server in the Playground;
review logs, analytics, and configuration versions as the API changes.

0mcp currently supports hosted Streamable HTTP servers, not local stdio servers. The original API remains responsible for business logic, authorization, pagination, rate limits, and data validation.

If your OpenAPI contract has weak parameter definitions, fix the source document first. The OpenAPI requirements guide covers the checks that matter before import.

Common mistakes

Exposing auth headers as tool inputs

Keep credentials out of the schema. Use runtime authentication and pass credentials to the upstream API from the server side.

Collapsing every identifier into `id`

Use workspace_id, project_id, task_id, and similar names when the hierarchy matters. The AI client should not guess which ID goes where.

Making patch fields required

For update operations, identifiers are usually required, but editable fields may be optional. Add validation that requires at least one change instead of requiring every possible update field.

Ignoring query bounds

List and search tools need limits, cursors, allowed filters, and clear defaults. An unbounded query tool is hard to test and easy to misuse.

Returning vague error messages

Map authentication, authorization, validation, not-found, conflict, rate-limit, timeout, and upstream errors separately. Vague failures slow down debugging.

Checklist

Before publishing a parameter-mapped MCP tool, check:

path parameters are required and clearly named;
query parameters have defaults, enums, bounds, and descriptions;
authentication headers stay out of model-visible inputs;
safe non-auth headers are either generated server-side or exposed as product-level inputs;
body fields preserve required fields, types, formats, enums, and nested objects;
naming conflicts are resolved with meaningful field names;
validation runs before the API request;
API errors map to understandable tool errors;
response fields give the AI client enough information to continue;
valid, invalid, unauthorized, forbidden, missing-resource, timeout, and rate-limit cases are tested.

Good MCP tool schemas do not make the AI client think in raw HTTP. They give the client a clear set of product-level inputs, then let the adapter place each value in the correct part of the API request.

How to Create an MCP Server for an API: From Operation Mapping to Tool Calls

Bhavy Shekhaliya — Wed, 26 Aug 2026 16:18:55 +0000

If you already have a working API, you are most of the way toward an MCP server.

The API already knows how to create records, fetch data, enforce permissions, validate inputs, and return responses. The MCP server adds a different interface on top: tools an AI client can discover and call with structured arguments.

In this tutorial, I will walk through the practical mapping:

API endpoint to MCP tool
path, query, and body parameters to tool input schema
API authentication to runtime credential handling
API response to MCP tool result
API errors to useful tool errors
local or hosted MCP testing before production

I will use a small support-ticket API as the example because it is easy to understand and still covers the parts that matter.

The example API

Imagine your SaaS product has these API operations:

GET  /tickets/{ticket_id}
POST /tickets
GET  /customers/{customer_id}/tickets

The user workflows are:

get the current status of one ticket;
create a new support ticket;
list tickets for a customer.

A basic OpenAPI-style summary might look like this:

paths:
  /tickets/{ticket_id}:
    get:
      operationId: getTicket
      summary: Get one support ticket
      parameters:
        - name: ticket_id
          in: path
          required: true
          schema:
            type: string
        - name: include_comments
          in: query
          required: false
          schema:
            type: boolean
      security:
        - bearerAuth: []

  /tickets:
    post:
      operationId: createTicket
      summary: Create a support ticket
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              required:
                - customer_id
                - title
                - description
              properties:
                customer_id:
                  type: string
                title: ""
                  type: string
                description: ""
                  type: string
                priority:
                  type: string
                  enum: [low, normal, high]
      security:
        - bearerAuth: []

This gives us enough to map real API behavior into tools.

Step 1: choose the operations that should become tools

Do not start by exposing the full API.

Start with one workflow and select the operations needed for that workflow. For the support example, the first MCP server might expose:

get_ticket
create_ticket
list_customer_tickets

It probably should not expose:

delete_ticket
bulk_export_tickets
admin_reassign_all_tickets
debug_ticket_index
login or token endpoints

This selection is part of the product design. An AI client has to choose from the tools you expose. A smaller, clearer tool list is easier to use than a huge list of overlapping endpoints.

Step 2: turn each API operation into a clear MCP tool

An MCP tool needs a name, description, and input schema. The API route is only the starting point.

For GET /tickets/{ticket_id}, a weak tool would look like this:

{
  "name": "getTicket",
  "description": "Get ticket",
  "inputSchema": {
    "type": "object"
  }
}

The route is recognizable to a developer, but the AI client still has very little to work with.

A better tool is more explicit:

{
  "name": "get_ticket",
  "description": "Return the status, priority, requester, and latest update for one support ticket. Use this when the user already knows the ticket ID.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "ticket_id": {
        "type": "string",
        "description": "The ID of the support ticket to retrieve."
      },
      "include_comments": {
        "type": "boolean",
        "description": "Whether to include recent ticket comments in the response.",
        "default": false
      }
    },
    "required": ["ticket_id"]
  }
}

This gives the AI client enough information to choose the tool and build a valid call.

Step 3: map parameters into one input schema

HTTP APIs split inputs across different locations:

path parameters;
query parameters;
headers;
request bodies;
sometimes cookies or form fields.

An MCP tool should present the useful business inputs as one schema.

For GET /tickets/{ticket_id}?include_comments=true, the mapping is:

ticket_id comes from the path;
include_comments comes from the query string;
the Bearer token comes from authentication, not the tool input.

The tool input might be:

{
  "ticket_id": "tck_123",
  "include_comments": true
}

The adapter then constructs the API request:

GET /tickets/tck_123?include_comments=true
Authorization: Bearer <token from runtime auth>

For POST /tickets, the request body becomes the tool input:

{
  "customer_id": "cus_456",
  "title": "Cannot access dashboard",
  "description": "The user sees a 403 after logging in.",
  "priority": "high"
}

Preserve API constraints when you build the schema. If priority only accepts low, normal, or high, keep that enum. If customer_id, title, and description are required, mark them required. If the API expects a date in ISO format, say so.

Bad schemas make the model guess. Good schemas reduce invalid calls.

Step 4: write descriptions that help tool selection

Descriptions are not decoration. They affect which tool the AI client chooses.

For similar tools, the description should explain the difference:

{
  "name": "list_customer_tickets",
  "description": "List support tickets for one customer. Use this when the user knows the customer ID and wants to review several tickets. For one known ticket ID, use get_ticket."
}

Compare that with the vague version:

{
  "name": "list_customer_tickets",
  "description": "Lists tickets."
}

A useful tool description often includes:

what the tool does;
when to use it;
what input must already be known;
whether it reads or changes data;
what it returns;
when another tool is a better fit.

The API endpoint tells you what route to call. The tool description tells the AI client why and when to call it.

Step 5: keep authentication out of normal tool inputs

Your API might use API keys, Bearer tokens, or OAuth.

Those credentials should not become ordinary tool arguments like this:

{
  "ticket_id": "tck_123",
  "api_key": "secret-key-here"
}

That is a bad pattern. It makes credentials model-visible and easy to leak into prompts, logs, examples, or retries.

Instead, keep the tool input focused on the business operation:

{
  "ticket_id": "tck_123",
  "include_comments": true
}

The MCP server should receive or access credentials through the runtime authentication path, then forward the credential to the original API.

The API still owns authorization. It should check:

which user or service identity is calling;
which tenant or workspace the caller belongs to;
which role or scope the caller has;
whether the caller can access the requested record;
whether the caller can perform the requested action.

The MCP layer should not become a shortcut around your API's permission model.

Step 6: implement the tool handler

The tool handler connects the MCP call to the API request.

Conceptually, a handler for get_ticket does this:

async function getTicketTool(input, auth) {
  validate(input, {
    required: ["ticket_id"],
    properties: {
      ticket_id: "string",
      include_comments: "boolean"
    }
  });

  const url = new URL(`/tickets/${input.ticket_id}`, API_BASE_URL);

  if (input.include_comments !== undefined) {
    url.searchParams.set("include_comments", String(input.include_comments));
  }

  const response = await fetch(url, {
    method: "GET",
    headers: {
      Authorization: `Bearer ${auth.accessToken}`,
      Accept: "application/json"
    },
    signal: AbortSignal.timeout(10000)
  });

  return mapApiResponseToToolResult(response);
}

Keep the handler specific. The tool should call the known route for get_ticket. Avoid a generic handler that accepts any path or method from the model.

For create_ticket, the handler would:

validate customer_id, title, description, and priority;
create a JSON request body;
call POST /tickets;
forward the runtime credential;
map the created ticket into a useful result.

The handler should also treat failures deliberately. A 401 should not look like "no tickets found." A validation error should tell the caller which input is wrong. A timeout should be visible as a timeout, not a generic failure.

Step 7: map API responses into useful tool results

Raw API responses are sometimes fine. But the tool result should help the AI client continue the workflow.

For get_ticket, the API might return:

{
  "id": "tck_123",
  "status": "open",
  "priority": "high",
  "title": "Cannot access dashboard",
  "requester": {
    "id": "usr_789",
    "email": "user@example.com"
  },
  "latest_update": "Customer sees a 403 after login."
}

The MCP tool result should preserve the useful fields and avoid hiding the shape behind a vague string.

For example:

{
  "ticket_id": "tck_123",
  "status": "open",
  "priority": "high",
  "title": "Cannot access dashboard",
  "requester_id": "usr_789",
  "latest_update": "Customer sees a 403 after login."
}

Do not include secrets, internal headers, stack traces, or private debugging fields. If the API returns more data than the AI workflow needs, consider filtering or documenting the output carefully.

For list operations, return pagination metadata when it matters:

{
  "tickets": [
    {
      "ticket_id": "tck_123",
      "status": "open",
      "priority": "high",
      "title": "Cannot access dashboard"
    }
  ],
  "next_cursor": "cursor_abc"
}

The agent can now explain the result and continue if the user asks for more.

Step 8: test the MCP tool path

API tests usually start with a known route and a known payload. MCP testing should also check discovery and selection.

Before production, test these cases:

the MCP client can connect to the server;
get_ticket appears in the tool list;
the description makes it clear when to use the tool;
missing ticket_id fails before the API request;
invalid input types fail clearly;
a valid ticket ID reaches the right API route;
a missing ticket returns a clear not-found result;
missing credentials produce an authentication error;
insufficient permissions produce an authorization error;
create_ticket works with the minimum valid body;
invalid priority values are rejected or clearly reported;
timeouts and rate limits are visible.

Also test the agent workflow:

User: "Find ticket tck_123 and tell me whether it is still open."

The expected behavior is:

the client chooses get_ticket;
it sends ticket_id;
the API authenticates the request;
the tool returns ticket status;
the client answers based on the returned data.

If the agent chooses the wrong tool, the problem might be the name, description, or tool overload. If the tool call fails, the problem might be schema mapping, authentication, authorization, or the upstream API.

Step 9: decide where the MCP server runs

For a prototype, a local server can be enough. For a SaaS product used by customers or remote AI clients, you need a hosted endpoint and an operational plan.

For a self-hosted MCP server, you own:

deployment;
transport;
TLS;
authentication handling;
secrets and credential rotation;
timeouts and retries;
logs;
metrics;
versioning;
rollback;
client compatibility testing.

For a managed workflow, the goal is to avoid maintaining the MCP infrastructure yourself while still controlling which API capabilities are exposed.

With 0mcp, the hosted workflow is:

import a supported Swagger, OpenAPI, or Postman definition;
review detected operations and validation feedback;
select the API functions you want to expose;
create or edit tools, resources, and prompts;
use API key, Bearer token, or OAuth pass-through;
test in the Playground;
use the hosted Streamable HTTP endpoint from an MCP-compatible client;
review logs, analytics, and configuration versions as the API changes.

0mcp currently supports hosted Streamable HTTP servers, not local stdio servers. Your original API remains responsible for business logic, authorization, pagination, rate limits, and data validation.

A practical checklist before launch

Before you share the MCP endpoint, check:

The selected tools match real user workflows.
Tool names are clear and stable.
Descriptions explain when to use each tool.
Path, query, and body parameters are mapped into the schema.
Required fields, enums, defaults, and formats are accurate.
Credentials are passed through runtime auth, not exposed as tool inputs.
The upstream API enforces tenant, role, record, and action permissions.
Valid, invalid, missing-auth, and forbidden cases have been tested.
Tool results include enough data for the AI client to continue.
Logs and analytics are available for debugging after launch.
API changes have a versioning and rollback path.

If a tool fails several of these checks, fix the API contract or tool configuration before adding more capabilities.

Common mistakes

Exposing every endpoint

More tools can make selection harder. Start with a small workflow and add tools when tests or usage show a need.

Using vague tool names

api_request or manage_ticket forces the AI client to infer too much. Prefer names like get_ticket, create_ticket, and list_customer_tickets.

Putting credentials into the schema

Keep API keys, Bearer tokens, and OAuth credentials out of tool inputs. Pass them through the runtime authentication path.

Ignoring response shape

If the response is poorly documented, the agent may not know what it can safely say or do next. Keep response fields clear and predictable.

Testing only happy paths

Broken auth, invalid inputs, missing records, rate limits, and timeouts are part of production. Test them early.

Wrap up

Creating an MCP server from an API starts with careful mapping.

The endpoint becomes a tool. Parameters become the input schema. Authentication becomes runtime credential handling. The response becomes the tool result. Errors become diagnosable failure paths.

Once that mapping is clear, you can decide whether to build the server yourself or use a hosted workflow. If you want the detailed 0mcp version of this process, start with the guide on how to create an MCP server from an API.

The n8n Community Node You Need Might Already Exist

Bhavy Shekhaliya — Wed, 26 Aug 2026 03:21:15 +0000

You know that moment when you're building an n8n workflow and realize:

“Wait… does n8n already have a node for this?”

Maybe you need a specific AI provider.

Or a browser automation tool.

Or some obscure database.

Or a service that isn't part of n8n's core integrations.

The first instinct is usually to reach for the HTTP Request node.

But before writing API calls yourself, there's another possibility:

Someone may have already built the node.

That's one of the reasons I created Awesome n8n Community Nodes.

The n8n ecosystem is bigger than it looks

One of the best things about n8n is that it isn't limited to its built-in integrations.

Developers can create community nodes and publish them as npm packages, extending n8n with new services, triggers, actions, AI capabilities, utilities, and more.

The ecosystem has grown significantly. One existing ecosystem tracker had already indexed thousands of community nodes, showing just how quickly the space is expanding.

That's great for n8n users.

But it creates a new problem:

Discovery.

Having thousands of nodes is useful only if you can actually find the one you need.

So I built a directory

I created:

Awesome n8n Community Nodes

🔗 https://github.com/bhavyshekhaliya/awesome-n8n-community-nodes

It's an open-source, curated directory for discovering community-built n8n integrations and utilities.

Instead of organizing everything as one massive list, I grouped nodes around what you're actually trying to automate.

🤖 AI, Agents & Search

Looking for AI, LLM, search, agent, or AI-media capabilities?

There's a dedicated section for that.

🌐 Browser, Web & Scraping

Need browser automation, crawling, scraping, or web extraction?

You'll find those together.

💬 Communication & Messaging

WhatsApp, email, chat, notifications, and other communication-related nodes have their own category.

🗄️ Data, Storage & Observability

Database, storage, infrastructure, monitoring, and data-related integrations live here.

📄 Documents, Media & Productivity

For document processing, media, transcription, content, and productivity workflows.

🎯 CRM & Sales

Integrations that are useful for lead generation, sales, CRM, and customer workflows.

🛠️ Utilities

And the smaller but extremely useful tools that don't fit neatly elsewhere.

The repository currently links each entry to its npm package and, when available, its public source repository.

Why not just use npm search?

You can.

In fact, the repository points users toward npm's n8n-community-node-package search as another way to explore the broader ecosystem.

But package discovery and use-case discovery are different things.

If I search npm for a package, I need to already know roughly what I'm looking for.

If I browse a categorized directory, I can discover things I didn't even know existed.

That's the experience I wanted to improve.

A small example

Imagine you're building an AI workflow.

You want to:

Search the web → extract information → process it with an LLM → send the result somewhere

You might start thinking about several APIs and custom HTTP Request nodes.

But there may already be community nodes covering parts of that workflow.

The directory makes it easier to explore those possibilities before rebuilding something yourself.

That's the real value of a good ecosystem directory.

It doesn't just help you find what you were searching for.

It helps you discover what you didn't know you needed.

This isn't a security audit

There's an important distinction here.

The repository is a curated directory, not an endorsement or security audit.

Community nodes run third-party code inside your n8n environment, so you should review the source, release history, permissions, dependencies, and license before installing one.

Open source makes discovery easier.

It doesn't remove the need for due diligence.

I want this to be community-built

The directory is intentionally open source.

If you maintain an n8n community node, you can contribute it.

If you use a node that isn't listed, add it.

If something is categorized incorrectly or outdated, open a PR or issue.

The goal isn't to create another list that gets published once and forgotten.

The goal is to make this a living map of the n8n community-node ecosystem.

And the more people contribute, the more useful that map becomes.

One more thing

I think we're going to see even more interesting n8n nodes as AI agents, MCP, browser automation, and specialized APIs become part of everyday automation workflows.

That means the number of possible building blocks will keep increasing.

And when the number of building blocks increases, discovery becomes infrastructure.

That's what I'm experimenting with here.

If you're an n8n user, take a look:

🔗 GitHub: https://github.com/bhavyshekhaliya/awesome-n8n-community-nodes

And if you know a great community node that isn't there yet:

Send it my way.

Let's build the directory together.

How to Turn an OpenAPI Specification into MCP Tools

Bhavy Shekhaliya — Tue, 11 Aug 2026 04:57:13 +0000

If you already maintain an API, you probably have most of the information needed to create an MCP interface.

Your OpenAPI specification already describes:

available operations;
paths and methods;
required and optional parameters;
request bodies;
response formats; and
authentication schemes.

The work is not simply renaming an HTTP endpoint. An MCP tool needs to be understandable to an AI client: it needs a clear name, an accurate description, a useful input schema, and controlled access to the underlying API.

This guide walks through that mapping with a small support-ticket API example.

OpenAPI to MCP: the basic mapping

An OpenAPI operation can provide the foundation for one MCP capability:

OpenAPI	MCP tool
`operationId`	Starting point for the tool name
`summary` and `description`	Tool description
Path parameters	Usually required tool inputs
Query parameters	Optional or required tool inputs
Request body schema	Structured tool input
Response schema	Information about the returned result
Security scheme	Runtime authentication for the API request
Selected operations	The allowlist of capabilities exposed to the AI client

The exact presentation can vary by implementation, but the important principle is stable: the tool should preserve the API's real contract instead of hiding it behind a vague "call endpoint" action.

Start with a useful OpenAPI operation

Here is a shortened but concrete OpenAPI example for a support API:

openapi: 3.0.3
info:
  title: Support API
  version: 1.0.0
servers:
  - url: https://api.example.com

paths:
  /tickets/{ticket_id}:
    get:
      operationId: getTicket
      summary: Get a support ticket
      description: Return the status, priority, requester, and latest update for one ticket.
      parameters:
        - name: ticket_id
          in: path
          required: true
          schema:
            type: string
        - name: include_comments
          in: query
          required: false
          schema:
            type: boolean
            default: false
      responses:
        "200":
          description: Ticket returned
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Ticket"
      security:
        - bearerAuth: []

  /tickets:
    post:
      operationId: createTicket
      summary: Create a support ticket
      description: Create a ticket for a customer issue.
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              required:
                - title
                - description
              properties:
                title:
                  type: string
                description:
                  type: string
                priority:
                  type: string
                  enum: [low, normal, high]
      responses:
        "201":
          description: Ticket created
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Ticket"
      security:
        - bearerAuth: []

components:
  schemas:
    Ticket:
      type: object
      properties:
        id:
          type: string
        status:
          type: string
        priority:
          type: string
        title:
          type: string

  securitySchemes:
    bearerAuth:
      type: http
      scheme: bearer

This example gives an MCP generator enough information to create two candidate tools:

getTicket, which needs ticket_id and can optionally receive include_comments;
createTicket, which needs title and description and accepts a constrained priority value.

The API remains responsible for business logic. MCP adds a structured interface through which an AI client can discover and call the selected capabilities.

1. Validate the specification before importing it

Fix the API definition before you use it as the source for tools. At minimum, check that:

every operation has a unique, meaningful identifier;
summaries and descriptions explain what an operation does;
parameter types match the values the API actually accepts;
required fields are marked as required;
request and response schemas match real JSON responses;
authentication schemes are documented; and
references such as #/components/schemas/Ticket resolve correctly.

An incomplete specification can still look valid to a human while producing confusing tools. A missing description, an incorrectly optional field, or a stale response schema gives the AI client the wrong information at the moment it chooses an action.

0mcp supports Swagger 2.0, OpenAPI 3.0, OpenAPI 3.1, and Postman collections. For an OpenAPI workflow, import the specification rather than treating a raw REST base URL as the source. 0mcp validates the imported definition and shows warnings or errors before you publish the server.

For more detail on the supported OpenAPI path, see the OpenAPI-to-MCP documentation.

2. Choose the operations that should become tools

Do not expose every endpoint just because it exists.

Start with the smallest set that represents a useful workflow. For the support API above, that might be:

getTicket for reading the current state of a ticket;
createTicket for opening a new issue; and
a separate operation for adding an internal note, if that action is genuinely needed.

This selection is an access-control decision as well as a usability decision. Internal administration endpoints, destructive actions, debugging routes, and duplicate operations should not automatically become AI capabilities.

HTTP methods are useful clues, but they do not decide the tool boundary by themselves. A GET operation might provide data for a tool or resource, while a POST operation might represent a state-changing tool. Consider what the capability means to the user, what permissions it needs, and whether an AI client can use it safely.

In 0mcp, you can review the detected operations and select which API functions to expose. You can also create or update tools, resources, and prompts as the integration becomes more deliberate.

3. Map parameters into one tool schema

HTTP APIs distribute inputs across several locations. An MCP tool presents the inputs as one structured schema.

For the getTicket operation:

ticket_id comes from the path and is required;
include_comments comes from the query string and is optional;
the bearer credential is used for authentication, not exposed as a normal tool argument.

A conceptual MCP tool schema could look like this:

{
  "name": "get_ticket",
  "description": "Return the status, priority, requester, and latest update for one support ticket.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "ticket_id": {
        "type": "string",
        "description": "The ID of the ticket to retrieve."
      },
      "include_comments": {
        "type": "boolean",
        "description": "Whether to include ticket comments.",
        "default": false
      }
    },
    "required": ["ticket_id"]
  }
}

For createTicket, the request body becomes a structured input with required title and description fields. The priority enum should stay an enum. Preserving constraints helps the AI client form a valid request instead of guessing at allowed values.

When a path parameter and a body field have the same name, resolve the collision deliberately. When a schema is reused through $ref, make sure the generated tool still presents the fields and descriptions the client needs. When an API uses pagination, document the cursor or page inputs clearly; the API owner remains responsible for pagination behavior and rate-limit handling.

In 0mcp, tool names and descriptions can be edited in the dashboard. The underlying API schema should be corrected in the original OpenAPI definition so the API contract and the MCP interface do not drift apart.

4. Keep authentication out of the tool input

The example uses a bearer security scheme. That tells the integration how the original API expects requests to be authenticated, but the token should not appear in a tool description, example payload, or ordinary user argument.

0mcp supports API key, Bearer token, and OAuth authentication. Credentials are provided by the user through the MCP client at request time and passed through to the original API. 0mcp does not store those API keys, Bearer tokens, or OAuth credentials.

You should still apply the same security practices you use for the API itself:

use least-privilege credentials;
test with a staging account before exposing write operations;
avoid placing secrets in the OpenAPI description;
verify which operations each credential can access; and
review error responses for accidental sensitive data.

The 0mcp Trust page explains the platform's credential pass-through and data-minimization approach.

5. Import, configure, and create the hosted server

The managed workflow is straightforward:

Create an 0mcp account.
Import the OpenAPI specification.
Review detected operations and any validation warnings.
Select the operations to expose.
Edit tool names and descriptions where the API wording is not clear enough for an AI client.
Create the MCP server.

0mcp hosts the resulting server and provides a Streamable HTTP endpoint. The default endpoint has this shape:

yourservername.0mcp.dev/mcp

The endpoint can be used by an MCP-compatible client. 0mcp does not require you to run a local stdio server, and local/stdio MCP servers are not currently supported by the platform.

6. Test the tools before sharing the endpoint

A successful import does not prove that the resulting tools are useful. Test the interface in the 0mcp Playground before connecting it to a production workflow. Inspect the available capabilities, call the tools with realistic inputs, verify authentication, and review the individual usage logs.

For the support-ticket example, a useful test matrix looks like this:

Test	What to verify
`getTicket` with a valid ID	The path parameter is placed correctly and the returned JSON is understandable
`getTicket` without `ticket_id`	The tool rejects an incomplete request before the API receives it
`getTicket` with an unauthorized credential	The authentication failure is visible and does not look like a successful empty result
`createTicket` with the minimum valid body	Required fields and the request body are mapped correctly
`createTicket` with an invalid priority	The enum constraint prevents or clearly reports an invalid value
A response containing pagination	The tool description makes the next-page behavior clear

Also test the failure paths that matter to your users: expired credentials, missing records, permission errors, API timeouts, and validation failures. A tool that only works on the happy path is not ready for an AI workflow.

If you need a lower-level protocol inspection, the MCP Inspector guide is a useful companion to application-level tests.

7. Plan for API changes

The first tool call is only the start of the integration. APIs change, and those changes can affect:

required parameters;
operation names and descriptions;
authentication schemes;
response shapes;
pagination; and
permissions.

When the API changes, update the source OpenAPI specification, review the affected operations, and test the tools again. In 0mcp, configuration versions let you save changes, review them, and restore an earlier configuration when needed. Saving an MCP configuration updates the hosted server without requiring a rebuild or changing its URL.

Do not assume that an old MCP tool remains correct just because its name still exists. A schema change can turn a previously valid tool call into a bad request or cause the AI client to misunderstand the result.

Common problems

An operation did not become a tool

Check the import warnings, the operation's HTTP method and path, whether the operation was selected, and whether required schema references resolve.

The tool has poor or generic descriptions

Improve the OpenAPI summary, description, operationId, parameter descriptions, and response documentation. AI clients rely on this text when deciding which capability to call.

Calls fail with authentication errors

Compare the OpenAPI security scheme with the credential supplied at runtime. Check whether the API expects a bearer header, an API key in a specific location, or an OAuth flow. Do not solve the problem by putting the credential into the tool schema.

The server exposes too many tools

Reduce the selected operation set or separate unrelated product areas into different MCP servers. A large API surface is not automatically a useful AI interface.

The response is not usable

Check that the endpoint returns the JSON data your workflow needs. 0mcp currently focuses on JSON-based API responses; file uploads, file downloads, and binary API responses are not supported.

A practical launch checklist

Before sharing an API-derived MCP server, confirm that:

the OpenAPI specification is valid and uses a supported version;
operations have clear names and descriptions;
only necessary capabilities are exposed;
path, query, body, and response schemas match real API behavior;
authentication is documented and credentials are passed at runtime;
valid and invalid calls have been tested;
pagination, rate limits, and permissions are understood; and
a versioned update process exists for future API changes.

An OpenAPI specification is not an MCP server by itself. It is a strong source for building one when the contract is accurate and the exposed capability surface is intentional.

If you want to take the hosted route, explore the 0mcp API-to-MCP workflow or follow the OpenAPI-to-MCP documentation to review the implementation path.

Is Every SaaS Company Going to Need an MCP Server?

Bhavy Shekhaliya — Sat, 01 Aug 2026 01:53:35 +0000

Over the last year, I've noticed an interesting pattern.

A few years ago, every software company wanted a REST API.

Today, many of those same companies are asking a different question:

"How do we make our product work with AI agents?"

That shift made me wonder:

Will having an MCP server eventually become as common as having an API?

I'm not convinced we're there yet.

But I do think we're heading in that direction.

Let's discuss why.

We've Seen This Story Before

Think back to the early days of APIs.

Many businesses didn't expose one publicly.

Integrations were built manually.

Partners requested CSV exports.

Developers wrote custom scripts.

Everything worked—but only until the next integration request arrived.

Eventually, APIs became the standard because they reduced friction for everyone involved.

Now AI is creating a similar moment.

AI Doesn't Want Another Dashboard

When people use tools like ChatGPT, Claude, Cursor, or other AI assistants, they don't want to switch between five browser tabs just to complete a task.

Instead, they expect to say something like:

"Create a customer in our CRM."

"Generate this invoice."

"Show today's failed deployments."

For that to work, the AI needs a reliable way to interact with your product.

That's where the conversation around MCP starts.

So... Why Can't AI Just Call My REST API?

This is probably the most common question.

Technically, AI can call a REST API.

But here's the problem.

REST APIs were designed for software developers.

Developers read documentation.

Developers understand authentication.

Developers know which endpoint to call first.

Developers combine multiple requests together.

AI agents don't "read documentation" the same way humans do.

They need structured descriptions of available actions.

They need context.

They need discoverable tools.

That's exactly what MCP provides.

MCP Isn't Replacing APIs

This is probably the biggest misconception I see online.

Some people talk about MCP as if REST APIs are becoming obsolete.

I don't think that's true.

Your API is still the foundation.

The MCP server simply becomes another interface for accessing it.

A simple way to think about it is:

REST API → Built for applications and developers.
MCP → Built for AI models and AI agents.

One doesn't replace the other.

They solve different problems.

What Makes This Different From Previous Integrations?

Historically, if you wanted your product to work with different platforms, you often built separate integrations.

One for Slack.

One for Zapier.

One for Teams.

One for internal automation.

Now imagine doing the same thing for every AI platform that appears over the next few years.

That doesn't seem sustainable.

Standards become valuable when ecosystems grow.

That's why MCP has attracted so much attention.

An Observation From Building Around MCP

While working on 0mcp (https://0mcp.io), one thing became very clear.

Most teams already have everything they need.

They have:

A REST API.
An OpenAPI specification.
Authentication.
Documentation.

The missing piece isn't the API.

It's making that API understandable to AI systems.

That's why 0mcp focuses on turning existing OpenAPI specifications into hosted MCP servers instead of asking teams to rebuild everything from scratch. If you're curious how the workflow looks, the documentation at https://docs.0mcp.io walks through the process from importing an API to exposing AI-ready tools.

Will Every Company Need One?

Probably not.

At least, not today.

If your software has no need to interact with AI agents, adding an MCP server just because it's trendy doesn't make much sense.

Technology should solve a real problem.

But if your customers are already asking questions like:

"Can I use ChatGPT with your product?"
"Can Claude perform actions in our account?"
"Can Cursor access our internal APIs?"
"Can we automate this using AI?"

...then it's worth paying attention.

What I Think Happens Next

I don't think every product will suddenly launch an MCP server next month.

But I do think we'll see a gradual shift.

Five years ago, companies proudly announced they had an API.

Today, nobody makes that announcement because it's expected.

I wouldn't be surprised if MCP follows a similar path.

Not because it's fashionable.

But because AI tools need a consistent way to interact with software.

If You're Building Today...

I wouldn't recommend throwing away your existing APIs.

Invest in them.

Keep your OpenAPI specification up to date.

Design clear endpoints.

Good APIs become even more valuable in the AI era.

When you're ready to expose those capabilities to AI clients, standards like MCP can build on top of the work you've already done rather than replacing it.

That's one of the reasons we built 0mcp—to help teams reuse the APIs they already have instead of starting from zero. You can learn more on the homepage (https://0mcp.io) or explore the guides and examples in the documentation (https://docs.0mcp.io).

I'd Love to Hear Your Thoughts

This is still an evolving space.

Some teams are already exposing MCP servers.

Others are experimenting.

Many are still deciding whether they need one at all.

So I'm curious:

Do you think MCP servers will become as common as REST APIs, or will they remain a niche tool for AI-focused products?

Let's discuss in the comments.

[Boost]

Bhavy Shekhaliya — Wed, 29 Jul 2026 10:20:54 +0000

Bhavy Shekhaliya

Jul 29

Stop Building Custom AI Integrations. Use MCP Instead.

#mcp

4 min read

Stop Building Custom AI Integrations. Use MCP Instead.

Bhavy Shekhaliya — Wed, 29 Jul 2026 10:20:03 +0000

AI agents are becoming part of everyday software.

Customers want to ask ChatGPT to create tickets, update records, retrieve reports, trigger workflows, and interact with SaaS products using natural language.

For many teams, the first instinct is simple:

"Let's build a custom AI integration."

A few weeks later, the reality starts to look different.

You need to support multiple AI platforms.

You need authentication.

You need tool definitions.

You need documentation.

You need versioning.

You need monitoring.

You need to maintain everything as APIs evolve.

What started as a small integration suddenly becomes another platform your team has to maintain.

After helping teams expose APIs to AI systems, I've seen the same pattern repeatedly:

The challenge isn't connecting one AI model. The challenge is supporting an ecosystem of AI clients.

That's exactly why MCP exists.

The Problem With Custom AI Integrations

Imagine you run a SaaS product with a REST API.

Your customers ask:

Can ChatGPT create records?
Can Claude access our data?
Can Cursor trigger actions?
Can AI agents automate workflows?

A common solution is building a custom integration for each platform.

The result often looks like this:

Custom ChatGPT integration
Custom Claude integration
Custom internal agent integration
Custom documentation
Custom authentication flow
Custom maintenance process

Every new AI platform introduces additional work.

Instead of maintaining one API, you're maintaining multiple AI-specific layers.

APIs Were Built for Applications, Not AI Agents

REST APIs were designed for developers.

Developers can:

Read documentation
Understand request formats
Handle authentication
Manage errors
Combine multiple endpoints

AI agents operate differently.

They need structured descriptions of available actions.

They need clear tool definitions.

They need a consistent way to discover capabilities.

They need context about when and how actions should be used.

Without that layer, every AI integration becomes a custom project.

Enter MCP

MCP (Model Context Protocol) provides a standard way for AI systems to interact with software.

Instead of creating a separate integration for every AI platform, you expose capabilities through a common protocol.

Think of it this way:

REST API = Designed for developers
MCP = Designed for AI agents

Your API remains the source of truth.

MCP becomes the layer that makes those capabilities understandable and usable for AI systems.

Why More SaaS Companies Are Launching MCP Servers

The shift is similar to what happened with APIs years ago.

At one point, companies built custom integrations for every partner.

Eventually APIs became the standard.

Today we're seeing a similar transition with AI.

Instead of building custom AI connections repeatedly, companies are creating MCP servers that work across multiple AI tools.

This provides:

Better interoperability
Faster adoption
Lower maintenance costs
Easier onboarding for customers
Consistent AI experiences

The Hidden Cost Nobody Talks About

Most discussions focus on implementation.

Few teams discuss maintenance.

Let's say your API changes.

You now need to update:

Documentation
Tool descriptions
Integrations
Authentication logic
AI-specific configurations

As your product grows, maintenance becomes the biggest expense.

The more custom integrations you build, the larger that burden becomes.

A standard approach reduces that complexity.

Where OpenAPI Fits In

Many SaaS companies already maintain OpenAPI specifications.

Those specifications already describe:

Endpoints
Parameters
Request schemas
Response schemas
Authentication requirements

That information is extremely valuable.

Instead of recreating everything for AI systems, it can be used as the foundation for an MCP server.

This allows existing API investments to continue delivering value in the AI era.

How We Solved This at 0mcp

While working with API-driven products, we noticed teams repeatedly facing the same problem:

They already had APIs.

They already had documentation.

They already had OpenAPI specifications.

But turning those assets into production-ready MCP servers required significant effort.

That's why we built 0mcp.

Instead of building custom AI integrations from scratch, teams can import an OpenAPI specification, choose which operations should become AI tools, and deploy an MCP endpoint.

The goal isn't replacing APIs.

The goal is making existing APIs accessible to AI systems through a standard interface.

If you're exploring MCP, these resources may help:

Home: https://0mcp.io
Documentation: https://docs.0mcp.io
OpenAPI to MCP: https://0mcp.io
Getting Started: https://docs.0mcp.io

What This Means for SaaS Teams

The question is no longer:

"Should we support AI?"

Most companies already know the answer is yes.

The better question is:

"How do we support AI without creating years of integration debt?"

For many teams, the answer won't be another custom integration.

It will be adopting standards that allow AI systems to interact with software in a consistent way.

That's where MCP is heading.

And just like APIs became a requirement for modern software, MCP is rapidly becoming part of the foundation for AI-ready products.

Final Thoughts

Custom AI integrations seem fast at the beginning.

But every new platform increases complexity.

Every new tool increases maintenance.

Every new workflow creates another system to support.

Standards exist for a reason.

If your product already has an API, the next step may not be building another custom integration.

It may be making that API accessible through MCP.

The companies that solve this early will be much better positioned as AI agents become a standard part of how users interact with software.

REST vs. GraphQL: The Future of API Development

Bhavy Shekhaliya — Mon, 17 Jun 2024 10:11:15 +0000

APIs (Application Programming Interfaces) are the backbone of modern web development, enabling communication between different software systems. Two of the most popular paradigms for building APIs are REST (Representational State Transfer) and GraphQL. Understanding the differences between these two approaches can help developers choose the best tool for their projects.

Understanding REST:

- REST Overview :
┍ REST is an architectural style for designing networked applications. It relies on a stateless, client-server communication model and uses standard HTTP methods such as GET, POST, PUT, DELETE, and PATCH to perform CRUD (Create, Read, Update, Delete) operations.

- Key Characteristics of REST:

Statelessness: Each request from a client to a server must contain all the information needed to understand and process the request. The server does not store any client context between requests.
Scalability: RESTful services can handle a large number of requests and scale horizontally by distributing them across multiple servers.
Uniform Interface: REST APIs have a uniform interface, simplifying and decoupling the architecture. Resources are identified by URLs, and actions are performed using standard HTTP methods.
Caching: Responses from the server can be cached to improve performance and reduce the load on the server.

Understanding GraphQL:

- GraphQL Overview:
┍ GraphQL, developed by Facebook in 2012 and released publicly in 2015, is a query language for APIs and a runtime for executing those queries. It provides a more flexible and efficient approach to data fetching compared to REST.

- Key Characteristics of GraphQL:

Client-Specified Queries: Clients specify exactly what data they need, avoiding over-fetching and under-fetching issues.
Single Endpoint: All queries are sent to a single endpoint, simplifying the API structure.
Real-time Data: Supports real-time updates with subscriptions.
Strongly Typed Schema: GraphQL APIs are defined by a schema that describes the types of data available and the relationships between them.

When to Use REST:

Simple CRUD applications where the API structure is straightforward.
Scenarios where caching is crucial for performance.
When working with clients that do not require complex querying capabilities.
Legacy systems where REST is already in place.

When to Use GraphQL:

Applications requiring a flexible and efficient data-fetching mechanism.
Complex applications where multiple resources need to be queried simultaneously.
Real-time applications needing subscriptions for live updates.
Projects where minimizing the number of API requests is essential for performance.

Conclusion :

┍ Choosing between GraphQL and REST depends on the specific needs and constraints of your project. REST is a proven and reliable approach, especially for simple, scalable APIs. On the other hand, GraphQL offers a more flexible and efficient way to interact with your data, particularly suited for complex applications and real-time requirements.

DEV Community: Bhavy Shekhaliya

How to Update MCP Tools When the Underlying API Changes

Start by treating MCP tools as contracts

Create an API change checklist

Classify changes before updating tools

Update input schemas first

Update descriptions when behavior changes

Recheck authentication and authorization

Check response changes too

Version the API and MCP configuration together

Test old workflows before publishing

Keep rollback realistic

How 0mcp helps with safer updates

Mapping API Path, Query, Header, and Body Parameters to MCP Tool Schemas

Example API operation

Step 1: name the tool from the operation, not the route

Step 2: bring path parameters into the input schema

Step 3: map query parameters as filters and options

Step 4: treat authentication headers separately

Step 5: decide what to do with non-auth headers

Step 6: map the request body into structured inputs

Step 7: handle naming conflicts deliberately

Step 8: build the API request from the tool input

Step 9: validate before calling the API

Step 10: map responses and errors clearly

Step 11: test the mapping with real tool calls

How this works in 0mcp

Common mistakes

Exposing auth headers as tool inputs

Collapsing every identifier into id

Making patch fields required

Ignoring query bounds

Returning vague error messages

Checklist

How to Create an MCP Server for an API: From Operation Mapping to Tool Calls

The example API

Step 1: choose the operations that should become tools

Step 2: turn each API operation into a clear MCP tool

Step 3: map parameters into one input schema

Step 4: write descriptions that help tool selection

Step 5: keep authentication out of normal tool inputs

Step 6: implement the tool handler

Step 7: map API responses into useful tool results

Step 8: test the MCP tool path

Step 9: decide where the MCP server runs

A practical checklist before launch

Common mistakes

Exposing every endpoint

Using vague tool names

Putting credentials into the schema

Ignoring response shape

Testing only happy paths

Wrap up

The n8n Community Node You Need Might Already Exist

The n8n ecosystem is bigger than it looks

So I built a directory

🤖 AI, Agents & Search

🌐 Browser, Web & Scraping

💬 Communication & Messaging

🗄️ Data, Storage & Observability

📄 Documents, Media & Productivity

🎯 CRM & Sales

🛠️ Utilities

Why not just use npm search?

A small example

This isn't a security audit

I want this to be community-built

One more thing

How to Turn an OpenAPI Specification into MCP Tools

OpenAPI to MCP: the basic mapping

Start with a useful OpenAPI operation

1. Validate the specification before importing it

2. Choose the operations that should become tools

3. Map parameters into one tool schema

4. Keep authentication out of the tool input

5. Import, configure, and create the hosted server

6. Test the tools before sharing the endpoint

7. Plan for API changes

Common problems

An operation did not become a tool

Collapsing every identifier into `id`