omada-mcp

Call an Omada API operation

omada_call_operation

Destructive

Run any Omada Open API operation by operationId, passing path/query parameters, JSON body, and multipart files; controller IDs auto-fill and results return as JSON.

Instructions

Run any Omada Open API operation by operationId. params: path and query parameters by name (e.g. {"siteId": "Home", "page": 1, "pageSize": 100}). omadacId/mspId are filled in automatically; siteId accepts a site ID or a site name; page/pageSize default to 1/100 when required. body: JSON request body. files: uploads for multipart operations. Reply is the controller's JSON: {errorCode, msg, result}; errorCode 0 means success.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "operationId": "<operationId>"
    },
    "name": "omada_call_operation"
  }
}

Input Schema

Name	Required	Description
`body`	No	Request body (see omada_describe_operation for the schema)
`files`	No	Files for multipart uploads, keyed by form field name (usually "file"). Each value gives one of path (local file), base64, or text.
`params`	No	Path and query parameters by name
`operationId`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 7, 2026

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already declare readOnlyHint=false, destructiveHint=true and openWorldHint=true, so the safety profile is covered structurally. The description adds genuinely useful behavior the annotations cannot: the auto-filled omadacId/mspId, the siteId name-or-ID convenience, the page/pageSize defaults, and the {errorCode, msg, result} reply envelope with errorCode 0 meaning success. It adds no warning that arbitrary operations may mutate or delete controller configuration, which is a notable omission for a destructive, open-world generic dispatcher.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense paragraph with the core action first, then per-argument conventions, then the response shape — everything is front-loaded and nothing is redundant. Terminology (params/body/files) maps directly onto the schema property names.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a four-parameter generic dispatcher with no output schema, the description does a fair job by documenting the reply envelope and the auto-fill conventions. But it leaves the operationId discovery path unstated and gives no caution about the destructive, open-world operations it can invoke, which is exactly the context an agent needs before calling an arbitrary endpoint.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 75%, and the description goes meaningfully beyond the schema: it explains that params are path/query parameters keyed by name with a concrete example, that siteId accepts a site name as well as an ID, that page/pageSize default to 1/100 when required, and that files are multipart uploads. The one required parameter, operationId, has no schema description and is only loosely explained ("by operationId") with no pointer to where to obtain valid values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: "Run any Omada Open API operation by operationId." That is unambiguous about what the tool does. It does not, however, distinguish this from the sibling omada_request, which an agent would reasonably guess is also a generic API-call escape hatch.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: the agent learns it must already know an operationId, but is not told to use omada_search_operations to find one or omada_describe_operation to learn the body shape (that sibling is only referenced inside the body parameter's schema text, not in the description). No guidance on when to prefer omada_request or the typed siblings instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server