Skip to main content
Glama
FortiManager MCP Server

FortiManager MCP Server

by rstierli

remove_ips_sensor_signature_override

Remove a signature override entry from an IPS sensor by ID to clean up filter configurations.

Instructions

Remove a signature filter/override entry from an IPS sensor.

Use list_ips_sensor_signature_overrides to find the entry's "id" first if it is not already known.

Args: adom: ADOM name sensor: IPS sensor name entry_id: ID of the entry to remove (as returned in its "id" field)

Returns: dict: Remove result with keys: - status: "success" or "error" - message: Status or error message

Input Schema

NameRequiredDescriptionDefault
adomYes
sensorYes
entry_idYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.12.0

TDQS

A3.9/5.0
Behavior2/5

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

No annotations are provided, so the description must carry the full behavioral burden. It implies a destructive mutation and describes the return shape, but it does not disclose irreversibility, required permissions, ADOM lock requirements, or other side effects.

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?

The description is front-loaded with purpose and the list-first prerequisite, then uses compact Args and Returns sections. The Returns section is somewhat redundant because an output schema exists, but it does not obscure the core instructions.

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

Completeness4/5

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

For a simple three-parameter removal tool with an output schema, the description provides the essential purpose, prerequisite, parameter meanings, and return keys. The main remaining gap is behavioral safety context around a destructive operation, but the definition is otherwise sufficient to invoke it correctly.

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 description coverage is 0%, so the Args section is important. It labels all three parameters and specifically explains that entry_id is the id returned by list_ips_sensor_signature_overrides, though the adom and sensor explanations are minimal.

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

Purpose5/5

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

The description gives a specific verb and resource: removing a signature filter/override entry from an IPS sensor. It also distinguishes the operation from the sibling list_ips_sensor_signature_overrides by telling the agent to use that tool first when the entry id is unknown.

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

Usage Guidelines4/5

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

The description clearly states the key prerequisite: use list_ips_sensor_signature_overrides to find the entry id if it is not already known. It does not explicitly describe when not to use the tool or whether an ADOM lock is required, but the operational context is clear.

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