Should I import every endpoint in the spec?

No. Pick the few operations staff actually need. A large API turned into hundreds of tools makes the AI worse at choosing; OrgRelay also stops at 100 tools per connection.

Which operations count as read-only?

GET and HEAD default to read. POST, PUT, PATCH and DELETE default to write and therefore need approval. The owner can change the default per operation, for example a POST that only runs a search.

Can I import a Swagger 2.0 file?

Yes. OrgRelay accepts both OpenAPI 3.x and Swagger 2.0, as JSON or YAML, by URL or file upload, up to 40 MB.

Import an OpenAPI or Swagger API

If a platform already publishes an API description, nobody needs to build a connector. Give OrgRelay the file, tick the operations staff need, and they become tools with the same approvals and permissions as any other connector.

This is the fastest route for SaaS platforms that are not in the connector directory. It is also how many teams prototype before building a proper connector with standard tool names.

What OrgRelay accepts

Item	Rule
Format	OpenAPI 3.x or Swagger 2.0, JSON or YAML
Source	A URL (`http://` or `https://`, 30 s download timeout) or an uploaded file
Size	Up to 40 MB
Must contain	An `openapi` or `swagger` field and at least one entry under `paths`
Methods	GET, HEAD, POST, PUT, PATCH, DELETE
Tools per connection	100 at most

Large specs with thousands of schemas are fine. OrgRelay follows $ref with a depth and size budget, keeps up to 60 properties per object and 40 enum values per field, so a tool description never balloons past what the AI can read.

Step by step

In OrgRelay, the owner opens Admin → Business systems → Add connection and chooses Import OpenAPI.
Paste the spec URL or upload the file. OrgRelay lists every operation with its method, path and summary.
Tick the operations to expose. Start with three to five.
Check each operation's access. GET and HEAD start as read, everything else as write. Change it where the default is wrong.
Enter the base URL if the spec's servers entry is wrong for this customer, then the credentials. If the spec declares an API key scheme, OrgRelay pre-fills whether it goes in a header or the query string. See authentication for the options.
Click Test connection, then grant the connection to roles or departments.

Write operations behave exactly like write tools from a hand-built connector: OrgRelay creates an approval first and calls the API only after a person approves. The flow is described in approvals and write tools.

How tools are named

OrgRelay turns each operation into a domain.action name, following the rule in the connector spec:

Domain comes from the operation's first tag. Without tags, it is the first path segment that is neither a parameter nor a version (/v2/orders/{id} gives orders). Up to 16 characters.
Action comes from operationId, converted to snake case. Without one, it is the method plus path. Up to 30 characters.
Duplicates get a numeric suffix.

Spec	Tool name
`tags: [Orders]`, `operationId: listOrders`	`orders.list_orders`
`GET /v2/invoices/{id}`, no tag, no operationId	`invoices.get_v2_invoices_id`

Good operationId values produce good tool names. If the platform's spec has none, the names are still unique but less readable; that is a reason to build a small connector later.

Parameters and bodies

Path, query and header parameters become tool arguments. Authorization, Accept and Content-Type headers are excluded, since OrgRelay sets them. A request body becomes one body argument with the body's schema. Form fields are sent as form data.

When import is not enough

OpenAPI import exposes the API as it is. Teams usually outgrow it when:

The useful answer needs two calls joined, for example orders plus their shipments.
Responses are huge and need trimming before the AI sees them (the AI reads about 12,000 characters of a result).
The API's operationIds are cryptic and the AI picks the wrong one.

Then build a connector with a template and give it standard tool names. One connector can call the same API underneath.

A well-known criticism of auto-generating MCP tools from OpenAPI is that you end up with too many tools that mirror endpoints instead of tasks. OrgRelay's answer is to make selection explicit: nothing is exposed until someone ticks it.

GraphQL and existing MCP servers

If the platform has a GraphQL endpoint instead, use GraphQL import.
If the vendor already runs an MCP server, connect it directly with third-party MCP.

Common questions

Import every endpoint? No. Pick what staff need. The limit is 100 per connection, and fewer is better.

Which operations are read-only? GET and HEAD by default. The owner can override per operation.

Swagger 2.0? Yes, along with OpenAPI 3.x, as JSON or YAML, up to 40 MB.

Protect the credentials you enter: security requirements.
Let staff reach the imported tools from their own AI client through the MCP guide.
For owners deciding which systems to connect at all, orgrelay.com explains the business side.
Tool names you would choose by hand instead: standard tools and the connector spec.
Check the directory first; WooCommerce and Stripe are already covered.
Writes from imported operations still go through approvals.
Test imported tools from an AI client such as Claude Code.
Company-wide rollout rules: enterprise MCP patterns. Why writes wait for a person: human-in-the-loop.

Quickstart: run a template and pass the self-test in 15 minutes.
MCP transport: serve a connector over Streamable HTTP.
Self-test tool: the self-test tool and what each check means.
Events: signed event push for new orders and alerts.

Import an OpenAPI or Swagger API

#What OrgRelay accepts

#Step by step

#How tools are named

#Parameters and bodies

#When import is not enough

#GraphQL and existing MCP servers

#Common questions

#Next

#Related pages