secobserve-mcp

Call SecObserve Action

secobserve_call_action

Destructive

Run non-CRUD operations on SecObserve resources: apply rules, simulate, export data, and more. Specify resource, action, and optional id/body/params to get results or export file paths.

Instructions

Invoke a named non-CRUD action on a resource (apply_rules, copy, simulate, exports, ...).

This is the escape hatch for the long tail of SecObserve endpoints that are neither CRUD nor common enough to deserve their own tool. secobserve_list_resources lists every action with its verb and whether it needs an id. Actions that return a file are written to the server's export directory and the path is reported.

Prefer the dedicated tools where they exist: secobserve_assess_observation, secobserve_bulk_assess_observations, secobserve_approve_observation_log, secobserve_run_periodic_task. They validate the payload; this tool does not.

Args: params (CallActionInput): Validated input containing: - resource (str): Resource owning the action. - action (str): Action name (bare name, no slashes). - id (Optional[int]): Required for detail actions, omitted for collection ones. - body (Optional[dict]): JSON body for POST/PATCH actions. - params (Optional[dict]): Query parameters for GET actions. - method (Optional[str]): Override the default verb (only needed for product_notifications/override, which is POST to set and DELETE to clear). - filename (Optional[str]): Base filename for file-returning actions. - response_format (ResponseFormat): "markdown" or "json".

Returns: str: For JSON actions, the response body as markdown or JSON (a list response is rendered as items with pagination-style metadata). For file actions, a line giving the absolute path and byte size written. For empty 204 responses, a confirmation that the action was accepted.

Examples: - Use when: "re-apply rules to product 12" -> resource="products", action="apply_rules", id=12 - Use when: "how many observations would this rule match?" -> resource="general_rules", action="simulate", id=4, body={...rule definition...} - Use when: "export product 12's observations to Excel" -> resource="products", action="export_observations_excel", id=12 - Don't use when: a dedicated tool covers it (assessments, approvals, imports, scans, metrics, periodic tasks).

Error Handling: Unknown action -> error listing the resource's valid actions. Missing or stray id -> error saying which the action needs. Read-only mode blocks every non-GET action.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.2Sep 17, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations mark the tool destructive and non-idempotent, and the description adds important context: it does not validate payloads, read-only mode blocks non-GET actions, unknown actions produce errors listing valid actions, and file-returning actions write to the server export directory with the path reported. No annotation contradiction exists.

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?

The description is long but tightly organized with clear sections (Args, Returns, Examples, Error Handling). Information is front-loaded with the core purpose and escape-hatch framing, and each section earns its place by answering likely agent questions.

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

Completeness5/5

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

For a flexible, high-complexity tool with many possible actions, the description is complete: it explains how to discover actions, what parameters mean, what return formats look like, how errors surface, and how read-only mode constrains calls. The output schema and existing annotations cover the remaining structured details.

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?

The description repeats the property list from the schema but adds practical meaning: id detail-vs-collection guidance, method override only needed for product_notifications/override, response_format values, filename behavior, and concrete natural-language examples mapping to params. Since the schema itself also documents each property, the description adds strong usage context without being redundant.

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 opens with a specific verb and resource: 'Invoke a named non-CRUD action on a resource', then examples. It explicitly names the escape-hatch role and distinguishes itself from dedicated sibling tools like secobserve_assess_observation and secobserve_bulk_assess_observations.

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

Usage Guidelines5/5

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

The description states when to use this tool ('long tail of SecObserve endpoints'), when not to use it ('Don't use when: a dedicated tool covers it'), and names the preferred alternatives explicitly. It also directs users to secobserve_list_resources to discover valid actions.

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

Deploy Server