Skip to main content
Glama
Sign In
OpenCDR MCP

OpenCDR MCP

Official
by dbnz-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

opencdr_detection_handling

Read-onlyIdempotent

Retrieve a detection’s Core-owned handling details or immutable audit history by detection ID; use history for audit trails and supply agent_id in fleet mode.

Instructions

Read Core-owned handling or immutable audit history via the configured owner.

Unlike indexed browsing, Fleet forwards this selected-record request to its Core. SIEM references are manual and unverified; investigation remains in the SIEM.

In fleet mode, supply agent_id explicitly. Core mode leaves agent_id unset.

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": {
      "detection_id": "<detection_id>"
    },
    "name": "opencdr_detection_handling"
  }
}

Input Schema

NameRequiredDescriptionDefault
afterNo
limitNo
historyNo
agent_idNo
detection_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.0

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds a genuinely useful caveat that SIEM references are manual and unverified with investigation remaining in the SIEM, plus the fleet/Core routing behavior. It says nothing about pagination behavior or what the history mode returns differently.

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?

Content is front-loaded and short, with the routing constraint placed before the mode instructions. The fragmented sentences and blank-line breaks make it slightly choppy, but there is little wasted wording.

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 five-parameter, no-output-schema tool with zero schema descriptions, the definition covers routing and one caveat but omits the meaning of history, the paging parameters, and the return shape. It is workable but leaves meaningful gaps.

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

Parameters2/5

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

Schema description coverage is 0% across five parameters, so the description carries the full burden. It explains only agent_id (fleet vs Core) and leaves after, limit, history, and detection_id entirely undocumented in both places.

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 names a specific verb ('Read') and resource ('Core-owned handling or immutable audit history') tied to a selected record, and contrasts it with 'indexed browsing'. 'Handling' remains jargon that isn't defined, and no sibling tool is named, so the agent must infer the boundary from context.

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?

It gives real mode-selection guidance: in fleet mode pass agent_id, in Core mode leave it unset, and Fleet forwards the request to Core. It does not say when to choose this over opencdr_detection_detail or opencdr_detection_handoff_status, so alternatives are left to inference.

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