Skip to main content
Glama
Sign In
safe-omada-mcp

safe-omada-mcp

by gaspareduard
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

getAttackDefenseSetting

Get the DDoS and attack defense configuration, including flood protection settings and thresholds.

Instructions

Get the DDoS and attack defense configuration, including flood protection settings and thresholds.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "getAttackDefenseSetting"
  }
}

Input Schema

NameRequiredDescriptionDefault
siteIdNoSite ID to target. If omitted, uses the default site from OMADA_SITE_ID config. Use listSites to discover available site IDs.
customHeadersNoOptional HTTP headers to include in the Omada API request (e.g. {"X-Custom-Header": "value"}). Rarely needed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.18.0

TDQS

B3.2/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden; it does establish that this is a read of existing defense configuration and scopes the payload to flood protection and thresholds. It says nothing about permissions, error behavior, or what happens when no defense config exists, which matters given zero annotation coverage.

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

Conciseness4/5

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

A single front-loaded sentence that names the resource and the notable sub-content. No waste, but also no structure beyond the one line.

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 simple two-parameter read with a fully documented schema and no output schema, the description is minimally adequate: it says what configuration is returned. It leaves the shape of the returned config, site-scoping implications, and any auth expectations unaddressed.

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

Parameters3/5

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

Schema description coverage is 100% and the schema itself documents siteId (including the OMADA_SITE_ID default and the listSites pointer) and customHeaders. The description adds no parameter meaning beyond the schema, so the baseline 3 applies.

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?

States a specific verb ('Get') and resource ('DDoS and attack defense configuration'), plus the content returned (flood protection settings and thresholds). This distinguishes it reasonably from siblings like getFirewallSetting or getAclConfigTypeSetting, though it never explicitly names the adjacent tools it differs from.

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

Usage Guidelines2/5

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

No guidance on when to call this versus the many other config-retrieval siblings, and no prerequisites or exclusions. Usage is only implied by the read-oriented name.

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

Deploy Server

Other Tools