DEV Community: Bhavy Shekhaliya

I Wanted to Create an n8n Node. Then I Realized How Much Work Was Around It.

Bhavy Shekhaliya — Fri, 02 Oct 2026 02:33:19 +0000

I love n8n.

But creating a proper community node isn't just about writing the code.

There’s the structure.

The UI.
Credentials.
Operations and resources.
Tooltips, hints and placeholders.
Icons and naming.
Builds.
GitHub.
npm.
Publishing.

And then keeping everything clean as the node evolves.

At some point, I thought:

There should be a better way to do all of this.

So I built NativeShip.

What is NativeShip?

NativeShip helps you create, customize and ship your own n8n community nodes without turning the whole process into a weekend-long setup project.

You start with what you want your node to do.

NativeShip helps take care of the structure and the boring parts around it, while still keeping your code and accounts under your control.

Your code stays on your GitHub.

Your package stays on your npm account.

NativeShip doesn't take ownership of what you ship.

That part was important to me.

I didn't want another "node generator"

There are plenty of tools that can generate code.

That wasn't really the problem.

The harder part is creating a node that actually feels like a good n8n node.

Something users can understand immediately.

Something that follows n8n's conventions.

Something you can maintain after version 1.0.

That's why NativeShip focuses on the whole node creation lifecycle, not just generating some TypeScript.

The Node Editor

One of the features I'm most excited about is the Node Editor.

You can see your node inside a real n8n-style experience while you're working on it.

So instead of constantly thinking:

"I wonder how this will actually look in n8n?"

You can see it.

You can work on things like:

Operations
Resources
Field names
Descriptions
Tooltips
Hints
Placeholders
Credentials
Icons
Node UX

It's a small thing, but it changes how you build.

You stop thinking only about the code.

You start thinking about the person who will actually use the node.

Following n8n conventions

NativeShip is designed around n8n's official node development guidance.

That includes the details that are easy to overlook when you're building alone.

Things like:

Naming

Resources and operations should feel predictable.

Fields should be understandable without making users guess what to enter.

Tooltips, hints and placeholders

Small pieces of context can make a node dramatically easier to use.

Icons

Your node should feel like it belongs in the n8n ecosystem.

Structure

The generated project follows the expected community-node structure instead of giving you a random pile of generated files.

The goal isn't just:

"Here is some code."

It's:

"Here is a node you can actually work with."

And then there is publishing

Getting the node ready is only half the story.

You eventually need to build it, commit it, publish it and maintain it.

NativeShip connects that workflow with your own GitHub and npm accounts.

You stay in control.

Your repository is yours.

Your npm package is yours.

Your credentials stay with you.

And the workflow is designed around the official n8n community-node ecosystem rather than trying to create a completely separate system.

Why I built it

Honestly, NativeShip started from a simple frustration.

I wanted to make a good n8n node without spending most of my time dealing with everything around the node.

And while working through that process, I realized other people probably had the same problem.

Developers shouldn't have to fight tooling just to ship a good integration.

They should be able to spend more time thinking about:

What should this node do?

Not:

Why is this build failing again?

NativeShip is live 🚢

NativeShip is now available for anyone who wants to create and ship their own n8n community node.

You can check it out here:

https://nativeship.io

I'm still improving it every week, and I'm especially interested in hearing from people who have built n8n community nodes before.

If you've ever thought:

"I could build an n8n node, but..."

I'd love to know what came after the but.

Maybe that's the next thing NativeShip should make easier.

Build the node you wish existed. Ship it with confidence. 🚢

AI accounts, 5 different rate limits, 0 idea which one still worked?

Bhavy Shekhaliya — Sat, 26 Sep 2026 03:34:46 +0000

A few months ago my workflow looked something like this:

3 Claude Pro accounts
1 Codex accounts
1 Cursor account

Not because I'm hoarding subscriptions for fun it's because I lean on AI coding tools all day, and a single account's usage limit just doesn't survive a real working session. So the moment I hit a limit on one, I'd switch to the next.

Sounds fine in theory. In practice it turned into a small nightmare.

The actual problem

I'd be deep in a refactor, hit a wall "you've reached your usage limit" and switch accounts. Cool. But an hour later I'd forget:

Which account did I already burn through?
Which one reset already?
Did account #2 even have limit left, or did I use it yesterday and forget?

So I'd end up opening each tool one by one, logging in, checking usage screens, closing tabs, trying to reconstruct a mental map of "who has what." Every single time I hit a limit. Multiple times a day.

It's a dumb problem to have, but it was eating real time. Context-switching between 5 accounts across 3 different tools just to answer "which one can I use right now" is exactly the kind of friction that shouldn't exist for developers who are supposed to be moving fast.

What I actually needed

Not another dashboard to log into. Not another tab. I just wanted one place that could tell me, at a glance:

Claude account 1 - X% used
Claude account 2 - X% used
Claude account 3 - X% used
Codex account 1 - X% used
Cursor - X% used

That's it. No analytics, no fluff. Just "here's what's left, go use it."

So I built it

I ended up building a small desktop app that connects to your Claude, Codex, and Cursor accounts and shows live usage for each one in a single window. No more guessing, no more tab-hopping, no more "wait, did I already use this one today?"

It's called UsageBuddy, and it exists purely because I got tired of doing manual account bookkeeping instead of writing code.

If you're juggling multiple AI coding accounts too and if you use these tools seriously, you probably are this might save you the same headache it saved me.

👉 usagebuddy.com

I built this for myself first. If it's useful to you too, that's a bonus but I'd genuinely like to know if other devs are hitting the same wall, because right now it feels like something everyone running multiple AI accounts eventually runs into and just quietly tolerates.

If that's you, don't wait until you're mid-refactor and rate-limited again to fix it. Go check your accounts now you might already be sitting on a maxed-out one without knowing it.

How to Deploy a Remote MCP Server with Streamable HTTP

Bhavy Shekhaliya — Thu, 24 Sep 2026 09:06:48 +0000

Building an MCP server locally is useful for development.

Deploying it for production is a different job.

Once the MCP server becomes remote, you need to think about endpoint shape, transport, authentication, API credentials, testing, logs, latency, versioning, and what happens when the upstream API changes.

For API-backed MCP servers, a production deployment usually has one goal:

expose a stable remote MCP endpoint that AI clients can connect to, while the original API remains responsible for business logic and authorization.

This guide walks through the deployment decisions I would check before shipping a remote MCP server over Streamable HTTP.

Local MCP servers and remote MCP servers solve different problems

A local MCP server usually runs on one developer machine. Many local servers use stdio, where the MCP client starts a local process and communicates through standard input and output.

That model is helpful when:

you are building or debugging a server
the tool only needs local machine access
the server is for one developer
the workflow does not need a shared hosted URL
you want a fast feedback loop during development

A remote MCP server is different. It runs as a reachable service and exposes an endpoint that an MCP-compatible client can connect to over the network.

That model makes more sense when:

multiple users or clients need access
your API is already cloud-hosted
the server needs stable HTTPS
your team wants logs and monitoring
customers need to connect from their own environment
the integration should survive laptop restarts and local setup issues

Neither model is automatically better. They fit different stages. Local is good for development and private workflows. Remote is the production path for most SaaS API integrations.

What Streamable HTTP changes

Streamable HTTP gives a remote MCP server a network-friendly transport.

Instead of launching a local process, the client connects to an HTTP endpoint. A production endpoint usually looks like:

https://mcp.example.com/mcp

Or, for a default hosted endpoint:

https://your-server-name.0mcp.dev/mcp

When you deploy with Streamable HTTP, your testing needs to include the full HTTP path:

DNS
HTTPS
endpoint routing
request body handling
response headers
proxy behavior
timeouts
authentication
request and response sizes
client compatibility with the selected transport

The MCP tool may be mapped correctly, but the deployment can still fail because the proxy drops streaming responses, the path is wrong, or the client is pointed at an old endpoint.

Deployment is MCP code plus ordinary web-service work, with the added requirement that clients must discover and call MCP capabilities correctly.

Choose the endpoint shape early

Pick a stable endpoint before production.

For example:

https://mcp.yourcompany.com/mcp

Then write down:

the environment: staging or production
the transport: Streamable HTTP
the exact path
the owning team
the current server version
the upstream API environment
the credential model
the rollback plan

This sounds like admin work, but it prevents real bugs. If the team cannot tell which API environment the MCP server calls, or which version is currently active, debugging gets painful fast.

For custom domains, also check:

CNAME record
domain verification
TLS certificate status
redirect behavior
whether root domains are supported by your hosting model
whether the /mcp path reaches the MCP server rather than a website route

For 0mcp specifically, eligible plans can use custom subdomains such as mcp.example.com. Root domains are not supported. The default hosted endpoint format is yourservername.0mcp.dev/mcp.

Keep authentication separate from tool calls

A remote MCP deployment has two authentication concerns.

First, the MCP client needs to connect to the MCP server.

Second, the MCP server needs to call the original API.

For API-backed tools, avoid turning authentication routes into model-selected tools. The model should not need tools like:

login_user
refresh_token
create_api_key
get_secret

Those operations belong in the connection and credential flow, not in the ordinary tool list.

For an API-to-MCP server, the common pattern is:

the client provides credentials at runtime
the MCP server receives the tool call
the MCP server forwards the relevant credential to the original API
the original API validates identity, scopes, tenant access, and record permissions
the MCP server returns the API result through the MCP interface

Test API keys, Bearer tokens, and OAuth separately. A valid credential should work. A missing, expired, revoked, wrong-tenant, or under-scoped credential should fail safely.

With 0mcp, existing API authentication continues to be used. API keys, Bearer tokens, and OAuth credentials are passed through during requests rather than stored by 0mcp. The hosted MCP server gives teams a Streamable HTTP endpoint, while the original API remains the source of truth for authorization and business rules.

Deploy a focused capability surface

Do not deploy every API endpoint because the importer can see it.

Production remote servers need a smaller, cleaner surface:

tools that map to real user workflows
clear names
clear descriptions
accurate input schemas
predictable JSON responses
narrow permissions
separate review for write actions
separate review for delete, bulk, admin, billing, or export operations

If a tool changes data, say that in the description.

If a tool needs user confirmation, say that too.

If two tools look almost the same, rename them or remove one. Similar tools are one of the easiest ways to confuse an agent during tool selection.

For example, this pair is vague:

update_customer
modify_customer

This pair is better:

update_customer_billing_email
update_customer_support_status

The second pair tells the client what each tool changes. It also helps the developer write focused tests.

Test the deployment before connecting production clients

A production readiness test should cover connection, discovery, calls, auth, errors, and logs.

Start with the connection:

Can a clean client connect to the remote endpoint?
Does it use the expected transport?
Does the server initialize?
Does the endpoint work from outside your local network?
Does the production proxy forward requests correctly?

Then check discovery:

Are the expected tools visible?
Are removed tools really absent?
Are resources and prompts visible if your server exposes them?
Are names unique?
Are descriptions clear enough to choose from?
Do input schemas match the API contract?

Then run tool calls:

valid minimum input
valid full input
missing required input
wrong type
invalid enum
empty result
missing record
upstream API timeout
upstream rate limit
repeated request

For write tools, use a safe environment and test:

invalid state transition
duplicate request
user without permission
locked record
payload with unexpected fields
rollback or restore path if the change is unsafe

The test should prove that the server behaves predictably across realistic cases, beyond one successful response.

Monitor the server after launch

Remote MCP servers need operational visibility.

At minimum, you want to see:

request volume
success and failure status
authentication failures
authorization failures
latency
timeout frequency
rate-limit responses
most-used tools
unused tools
client source
outbound response size

Individual logs help debug one call. Analytics help you see patterns.

For example:

one tool may fail because its schema no longer matches the API
one client source may create most of the traffic
a write tool may be rarely used and too risky to keep enabled
a list tool may return responses that are too large
a rate limit may appear only during a specific workflow

Be careful with what you store. Logs should help debugging without storing secrets, request headers, raw credentials, or full response content unless your privacy model explicitly allows it.

0mcp logs include fields such as time, capability name, source, status, duration or latency, and outbound size. The outbound field stores response size, not response content.

Version deployments like API-facing infrastructure

An MCP server sits between clients and your API. When either side changes, users can feel it.

Version these parts:

imported API definition
selected operations
tool names
tool descriptions
input schemas
authentication configuration
hosted domain or endpoint settings
resources and prompts
production release notes

Some changes are safe:

improving a description
adding an optional field
exposing a new read-only tool after testing

Some changes can break clients:

renaming a tool
removing a tool
changing a required field
changing enum values
changing response shape
moving the endpoint URL
changing credential requirements

For breaking changes, keep a rollback path. If your platform supports restoring previous configuration versions, test that restore flow before you need it under pressure.

0mcp supports saving, reviewing, and restoring configuration versions, so teams can manage selected operations and tool configuration changes without rebuilding the hosted endpoint from scratch.

Hosted deployment versus self-hosting

Self-hosting gives your team direct control over the runtime, network, deployment pipeline, and infrastructure choices.

It also means your team owns:

MCP server hosting
HTTPS and routing
transport behavior
secrets management
deployment automation
uptime monitoring
logs and analytics
schema updates
rollback paths
production support

A hosted platform reduces that infrastructure burden. The tradeoff is that you work inside the platform's supported inputs, transports, configuration model, and product limits.

For 0mcp, that means:

supported inputs are Swagger 2.0, OpenAPI 3.0, OpenAPI 3.1, and Postman collections
hosted transport is Streamable HTTP
local stdio servers are not supported
tools, resources, and prompts are managed through the dashboard
customers select which API operations to expose
existing API auth remains in place through credential pass-through
Playground, logs, analytics, and configuration versions support the hosted workflow

That is a practical fit for SaaS teams that want an MCP endpoint for their existing API but do not want to own the full infrastructure layer.

What to Do When an API Has Too Many Endpoints for One MCP Server

Bhavy Shekhaliya — Sun, 13 Sep 2026 12:59:57 +0000

Large APIs are where MCP design gets interesting.

If your API has 15 endpoints, you can review each one by hand and decide which operations should become tools. If your API has 300 endpoints, exposing everything creates a different problem:

the MCP server becomes technically complete but hard for an AI client to use.

An AI client does not see your product the way your backend team sees it. It sees a list of tool names, descriptions, and input schemas. If that list is too large or too repetitive, the client has to spend more effort choosing a tool than solving the user's request.

The fix is not to dump the whole API into one MCP server. The fix is to design focused capability surfaces.

Why too many endpoints become too many tools

Most APIs grow around product history.

You may have:

old routes kept for backward compatibility
admin-only routes
internal debugging routes
several versions of similar endpoints
narrowly scoped CRUD routes
bulk import and export routes
billing routes
account-management routes
support and reporting routes
endpoints created for specific frontend screens

That API shape may be fine for developers. It is not automatically a good AI-facing interface.

If you convert every endpoint into one MCP tool, the client may see dozens of similar options:

get_customer
get_customer_by_id
fetch_customer
list_customers
search_customers
admin_get_customer
get_customer_summary
get_customer_details

Even if each tool works, the set becomes noisy. The model has to infer which tool is safest, which one returns the right fields, and which one matches the user's intent.

That extra ambiguity leads to wrong calls, more retries, slower workflows, and harder debugging.

Group endpoints by user workflow

The first reduction pass should be workflow-based.

Do not start with:

"Which endpoints do we have?"

Start with:

"Which user task should this MCP server help with?"

For example, a SaaS product may have several possible workflow groups:

customer support context
sales account research
billing and invoice lookup
project management updates
workspace administration
analytics reporting
developer operations

Each group needs a different tool surface.

A support workflow might need:

get_customer
list_customer_tickets
get_ticket
list_customer_subscriptions

It probably does not need:

delete_customer
create_invoice_adjustment
rotate_api_key
update_workspace_permissions
run_internal_report

Grouping by workflow helps you remove endpoints without arguing about whether they are "important." Many endpoints are important to the product, but irrelevant to a specific AI workflow.

Create focused MCP servers instead of one giant server

For a large API, one MCP server can become a junk drawer.

Focused servers are easier to reason about.

For example:

Support MCP server
- get_customer
- list_customer_tickets
- get_ticket
- create_ticket_note

Billing MCP server
- list_customer_invoices
- get_invoice
- get_subscription

Admin MCP server
- get_workspace_settings
- update_workspace_setting

These do not have to be separate products. They are separate AI-facing surfaces.

The advantages are practical:

fewer tools per client connection
cleaner descriptions
simpler permission review
easier testing
clearer logs
safer rollout
less chance that an agent chooses an unrelated admin or billing action

This is especially useful when different roles should have different access. A support agent, sales rep, billing admin, and internal developer should not always see the same MCP tools.

Remove tools that do not map to a user intent

Some endpoints exist because the frontend or backend needs them. That does not mean an AI agent needs them.

Good MCP tools usually map to user requests like:

"Find this customer's open tickets."
"Show the latest invoice."
"Create a ticket from this report."
"Update the status to resolved."
"Summarize recent account activity."

Weak MCP tools often map to implementation details:

"Call endpoint v2."
"Patch object."
"Run admin action."
"Submit generic payload."
"Fetch raw config."

When reviewing a large API, ask this for each endpoint:

What would a real user ask that should cause an AI client to call this tool?

If you cannot write that request clearly, leave the endpoint out for now.

Merge or rename confusing duplicates

Large APIs often contain overlapping endpoints.

For example:

GET /customers/{id}
GET /customers/{customer_id}/profile
GET /crm/customers/{id}
GET /support/customers/{id}

These might serve different backend needs, but they can create confusing MCP tools:

get_customer
get_customer_profile
get_crm_customer
get_support_customer

If the agent's task is support context, expose the one that returns the right support-facing shape. Do not expose all four unless the differences are clear and necessary.

If two tools must remain, name them by user-visible purpose:

get_customer_support_profile
get_customer_sales_profile

That is better than making the model guess the difference between crm and support from internal naming.

Reduce schema complexity

Tool overload can come from the number of tools, and it can also come from one huge schema.

Watch for tools that accept:

arbitrary JSON blobs
many unrelated optional fields
broad filter objects
raw query strings
generic data payloads
fields whose meaning depends on another hidden field

This kind of schema makes the AI client guess how to construct a safe request.

Instead of one giant update tool:

update_customer

Consider smaller tools:

update_customer_billing_email
update_customer_support_status
update_customer_account_owner

The smaller tools are easier to describe, easier to permission, and easier to test.

There is a tradeoff. Too many tiny tools can also become noisy. The line I use is simple: split a tool when the actions have different permissions, side effects, or user intent.

Treat sensitive operations as a separate surface

Some endpoints should not be mixed into a general-purpose MCP server.

Review these carefully:

deletes
bulk updates
exports
billing changes
permission changes
API key creation
OAuth client management
account cancellation
admin impersonation
internal maintenance tasks
notification or message sending

These operations are not forbidden forever. They need stronger review.

For sensitive tools, define:

who can call the tool
which credential scope is required
whether a confirmation step is needed
what records can be touched
whether the action can be reversed
how the action appears in logs
how to test unauthorized calls
how to roll back mistakes

If a sensitive endpoint is useful only to internal staff, do not expose it in the same MCP server used by customers.

Improve descriptions before adding more tools

When an AI client chooses a tool, the description does real work.

For a large API, weak descriptions compound fast.

Bad:

Gets customer.

Better:

Get the support-facing profile for one customer by customer ID. Use this before checking tickets or subscription status.

Bad:

Updates ticket.

Better:

Change the status of one support ticket after the user confirms the new status.

Descriptions should answer:

when to use the tool
what input is needed
what the tool returns
whether the tool changes data
whether the tool has side effects
when another tool is a better fit

If you have 40 tools with vague descriptions, adding 20 more tools makes the system worse. Fix the existing tool interface first.

Use an allowlist, not a denylist

For large APIs, I prefer an allowlist.

A denylist says:

"Expose everything except these dangerous routes."

That is risky because new endpoints may appear later and slip into the MCP surface by default.

An allowlist says:

"Expose only these selected operations."

That is safer and easier to review.

A simple allowlist can look like:

servers:
  support_context:
    expose:
      - GET /v1/customers/{customer_id}
      - GET /v1/tickets
      - GET /v1/tickets/{ticket_id}
      - POST /v1/tickets/{ticket_id}/notes

  billing_lookup:
    expose:
      - GET /v1/invoices
      - GET /v1/invoices/{invoice_id}
      - GET /v1/subscriptions/{subscription_id}

  admin_controls:
    expose:
      - GET /v1/workspaces/{workspace_id}/settings
      - PATCH /v1/workspaces/{workspace_id}/settings

This makes the decision explicit. It also makes reviews cleaner when the API changes.

Test the tool set as a set

Testing each tool by itself is necessary, but it is not enough.

When the API is large, you also need to test tool selection.

Use prompts that resemble real user requests:

Find open tickets for customer cus_123.

Show the latest unpaid invoice for customer cus_123.

Update ticket tick_456 to resolved.

Can you delete this customer?

Then check:

Does the client choose the expected tool?
Does it confuse similar tools?
Does it ask for missing IDs?
Does it avoid high-risk actions without confirmation?
Does it handle permission errors clearly?
Does it recover from empty results?
Does the server log show the tool name, status, latency, and response size?

If the agent keeps choosing the wrong tool, do not patch around it only with prompts. Reduce the tool set, rename tools, improve descriptions, or split the server by workflow.

How 0mcp helps with large APIs

With 0mcp, teams can import a supported Swagger, OpenAPI, or Postman definition, review detected operations, and select which API functions should become MCP capabilities.

That selection step matters for large APIs. The point is not to publish every route. The point is to choose the useful operations, refine names and descriptions, test the result in the Playground, and host the selected server over Streamable HTTP.

0mcp currently supports hosted Streamable HTTP servers, not local stdio servers. Existing API authentication continues to be used through API key, Bearer token, or OAuth pass-through. The original API still owns business logic, authorization, tenant boundaries, pagination, rate limits, and validation.

That division is important. A hosted MCP workflow can make selection, hosting, testing, logs, analytics, and version management easier. It should not replace your product's permission model.

For a deeper website guide on endpoint selection, see how to choose which API endpoints to expose as MCP tools.

Postman Collection to MCP: From Requests to MCP Tools

Bhavy Shekhaliya — Sat, 12 Sep 2026 19:29:57 +0000

A Postman collection can be a surprisingly useful starting point for an MCP server.

Many teams have Postman collections before they have polished OpenAPI documentation. The collection already contains working requests, paths, query parameters, headers, bodies, example responses, and authentication notes. That is enough to begin thinking about MCP tools.

But there is a catch.

A Postman request is still a developer artifact. An MCP tool is an AI-facing capability. Converting one into the other takes review, naming, schema cleanup, authentication decisions, testing, and production preparation.

This article walks through the practical path from Postman requests to MCP tools.

Start by cleaning the collection

Before importing a Postman collection anywhere, clean it.

A real collection often contains more than production-ready API requests:

experiments
duplicate requests
old API versions
internal debug endpoints
local host URLs
temporary headers
personal API keys
copied Bearer tokens
test-only request bodies
admin or destructive operations

Do not treat the collection as safe because it works in Postman.

Before using it for MCP, check:

Is this the current collection?
Does it point to the intended API environment?
Are request names clear?
Are variables understandable?
Are secrets removed?
Are test-only requests removed?
Are old endpoints removed or marked as legacy?
Are destructive requests separated for review?

This cleanup step matters because the MCP tool list will inherit a lot of meaning from the collection. If the collection is messy, the MCP server will probably be messy too.

Understand what maps from Postman to MCP

At a high level, each useful Postman request can become a candidate MCP tool.

A request like this:

GET {{baseUrl}}/v1/customers/{{customer_id}}/tickets?status=open
Authorization: Bearer {{token}}

Can become a tool like:

{
  "name": "list_open_customer_tickets",
  "description": "List open support tickets for one customer.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "customer_id": {
        "type": "string",
        "description": "The customer ID to search tickets for."
      },
      "limit": {
        "type": "integer",
        "description": "Maximum number of tickets to return."
      }
    },
    "required": ["customer_id"]
  }
}

The mapping includes more than method and URL.

You need to review:

request name
folder name
HTTP method
path variables
query parameters
headers
request body
authentication
example response
expected error behavior

Postman gives you the raw request shape. MCP needs a clear tool contract.

Map path variables into required inputs

Path variables usually become required tool inputs.

For example:

GET /v1/customers/{{customer_id}}

Should map to:

{
  "customer_id": {
    "type": "string",
    "description": "The unique ID of the customer to retrieve."
  }
}

If the endpoint cannot run without customer_id, the MCP schema should mark it as required.

Bad schema:

{
  "customer_id": {
    "type": "string"
  }
}

Better schema:

{
  "customer_id": {
    "type": "string",
    "description": "The customer ID from your application."
  }
}

Path variables deserve clear descriptions because the AI client may have several IDs in context. customer_id, workspace_id, ticket_id, and invoice_id should not be blurred into a generic id.

Map query parameters into optional filters

Query parameters often become optional tool inputs.

Example:

GET /v1/tickets?customer_id={{customer_id}}&status={{status}}&limit={{limit}}

Candidate schema:

{
  "type": "object",
  "properties": {
    "customer_id": {
      "type": "string",
      "description": "Return tickets for this customer."
    },
    "status": {
      "type": "string",
      "enum": ["open", "pending", "resolved"],
      "description": "Optional ticket status filter."
    },
    "limit": {
      "type": "integer",
      "minimum": 1,
      "maximum": 50,
      "description": "Maximum number of tickets to return."
    }
  },
  "required": ["customer_id"]
}

Good query-parameter mapping should answer:

Which filters are required for safe use?
Which filters are optional?
Are enum values documented?
Are default limits safe?
Can the request return too much data?
Is pagination clear?

For AI clients, unbounded list endpoints are risky. If your API supports limit, cursor, page, or offset, make those fields clear.

Handle request bodies carefully

Postman bodies often contain example payloads.

That does not automatically mean the MCP tool should accept the same raw JSON blob.

A request like:

POST /v1/tickets
Content-Type: application/json

{
  "customer_id": "{{customer_id}}",
  "subject": "{{subject}}",
  "priority": "{{priority}}",
  "message": "{{message}}"
}

Can become:

{
  "name": "create_support_ticket",
  "description": "Create a support ticket for a customer.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "customer_id": {
        "type": "string",
        "description": "The customer the ticket belongs to."
      },
      "subject": {
        "type": "string",
        "description": "Short ticket subject."
      },
      "priority": {
        "type": "string",
        "enum": ["low", "normal", "high"],
        "description": "Ticket priority."
      },
      "message": {
        "type": "string",
        "description": "Initial support message."
      }
    },
    "required": ["customer_id", "subject", "message"]
  }
}

Avoid schemas that accept one giant payload object unless the API genuinely needs arbitrary JSON. A specific schema gives the AI client better boundaries and gives your team better validation tests.

For write operations, the description should also say what changes.

Do not turn auth requests into normal tools

Many Postman collections contain requests like:

POST /login
POST /oauth/token
POST /refresh-token
GET /api-keys

Those are usually not good MCP tools.

Authentication should be part of the runtime connection and request flow. The model should not need to call login before using product capabilities.

For API-backed MCP tools, the safer pattern is:

the user or client provides credentials through the client flow
the MCP server receives a tool call
the MCP server passes the credential to the original API
the original API enforces identity, scopes, tenant access, and record permissions

When reviewing a Postman collection, remove personal tokens and secrets from the export. Keep variables like {{token}} or {{apiKey}} as placeholders, not real credentials.

Then test:

missing API key
invalid API key
expired Bearer token
revoked OAuth access
insufficient scope
wrong tenant

Authentication that works in Postman with your personal token may fail in MCP for a customer credential. Test that before production.

Select useful operations, not every request

A Postman collection can contain a lot of requests that are useful for developers and bad for AI agents.

Start with a small workflow.

For example:

"Let an AI support assistant look up customer context and create ticket notes."

Useful requests might be:

GET /customers/{customer_id}
GET /tickets?customer_id={customer_id}
GET /tickets/{ticket_id}
POST /tickets/{ticket_id}/notes

Requests to exclude from the first release might be:

DELETE /customers/{customer_id}
POST /admin/reindex
PATCH /users/{user_id}/role
GET /internal/debug
POST /oauth/token

This is the core selection rule:

A request should become an MCP tool only when it maps to a clear, useful, authorized AI capability.

The tool list is an allowlist. Treat it like a product and security decision.

Rename tools for the AI client

Postman request names are often written for humans browsing a collection.

Examples:

Get Customer
Create
Update v2
List
Old invoice route
Test request

Those names are weak MCP tool names.

Prefer names that are stable, specific, and action-oriented:

get_customer
list_customer_tickets
create_ticket_note
get_customer_subscription
list_unpaid_invoices

Tool descriptions should add the missing context:

List unpaid invoices for one customer. Use this when the user asks about outstanding billing or payment status.

The AI client should be able to choose the tool without reading your Postman folder structure.

If two tools sound the same, fix the names before adding more tools.

Test the imported tools

After importing and selecting operations, test the tool set before connecting a real client workflow.

For each tool, test:

valid minimum input
valid full input
missing required path variable
invalid query value
invalid enum
empty response
missing record
unauthorized request
wrong tenant
rate limit
timeout
unexpected upstream error

For write tools, also test:

duplicate submission
invalid state transition
insufficient permission
payload with extra fields
payload missing required business fields
behavior in a safe test environment

Then test discovery:

Are only the intended tools visible?
Are tool names unique?
Are descriptions specific?
Are required inputs obvious?
Are removed or sensitive requests absent?
Are resources and prompts visible only if intended?

This is where Postman-derived tools either become reliable or stay as "requests that worked once on my machine."

Prepare the hosted server for production

A hosted MCP server needs more than a successful import.

Before production, confirm:

the hosted endpoint is stable
the server uses the expected transport
HTTPS works
authentication is tested with real runtime credential paths
the upstream API environment is correct
logs show enough detail to debug calls
analytics can show request volume, error rate, latency, and capability usage
selected tools are versioned
rollback or restore is possible after a bad change
the original API still enforces tenant, role, record, and action permissions

With 0mcp, teams can import Postman collections, review detected requests, select useful API operations, refine tools, test in the Playground, and host the MCP server over Streamable HTTP. Existing API authentication continues to be used through API key, Bearer token, or OAuth pass-through, and customer credentials are passed through during requests rather than stored by 0mcp.

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

For the website version of this workflow, see Postman to MCP.

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.

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

DEV Community: Bhavy Shekhaliya

I Wanted to Create an n8n Node. Then I Realized How Much Work Was Around It.

What is NativeShip?

I didn't want another "node generator"

The Node Editor

Following n8n conventions

And then there is publishing

Why I built it

NativeShip is live 🚢

AI accounts, 5 different rate limits, 0 idea which one still worked?

How to Deploy a Remote MCP Server with Streamable HTTP

Local MCP servers and remote MCP servers solve different problems

What Streamable HTTP changes

Choose the endpoint shape early

Keep authentication separate from tool calls

Deploy a focused capability surface

Test the deployment before connecting production clients

Monitor the server after launch

Version deployments like API-facing infrastructure

Hosted deployment versus self-hosting

What to Do When an API Has Too Many Endpoints for One MCP Server

Why too many endpoints become too many tools

Group endpoints by user workflow

Create focused MCP servers instead of one giant server

Remove tools that do not map to a user intent

Merge or rename confusing duplicates

Reduce schema complexity

Treat sensitive operations as a separate surface

Improve descriptions before adding more tools

Use an allowlist, not a denylist

Test the tool set as a set

How 0mcp helps with large APIs

Postman Collection to MCP: From Requests to MCP Tools

Start by cleaning the collection

Understand what maps from Postman to MCP

Map path variables into required inputs

Map query parameters into optional filters

Handle request bodies carefully

Do not turn auth requests into normal tools

Select useful operations, not every request

Rename tools for the AI client

Test the imported tools

Prepare the hosted server for production

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

Collapsing every identifier into `id`