Skip to main content
Glama
Sign In
OpenCDR MCP

OpenCDR MCP

Official
by dbnz-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

opencdr_case_active

Read-onlyIdempotent

Find the accessible active case for one detection across the complete account scope; Fleet reads its own index, and a 404 may indicate scope limits rather than global absence.

Instructions

Find the accessible active case for one detection in a complete account scope.

Fleet reads its own index without contacting a member Core. A 404 does not prove global absence: the case can include accounts outside your grants/scope.

In fleet mode this tool uses the Fleet authority directly; Core mode uses standalone Core.

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": {
      "agent_id": "<agent_id>",
      "detection_id": "<detection_id>",
      "agent_ids": "<agent_ids>"
    },
    "name": "opencdr_case_active"
  }
}

Input Schema

NameRequiredDescriptionDefault
agent_idYes
agent_idsYes
detection_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.0

TDQS

B3.3/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive and open-world behavior, so the bar is lower. The description still adds real context: fleet resolves against its own index without contacting a member Core, a 404 does not prove global absence, and the authority differs between fleet and Core mode. What it omits is what the returned case object contains and any pagination or error semantics beyond 404.

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

Conciseness3/5

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

The core scope statement is front-loaded, but the mode-switching and Fleet-authority sentences are loosely structured and partially redundant with each other. The paragraph breaks fragment a small amount of content without adding hierarchy.

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?

There is no output schema, so the description could describe what a returned case looks like, and with 0% parameter coverage it should at least clarify the two identifier parameters. It does cover the important failure mode (a 404 is scoped, not global), leaving a definition that is adequate but incomplete for a three-required-parameter lookup.

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 coverage is 0%, so all meaning must come from the description, and it supplies none for the three parameters. Most notably it never explains why both agent_id and agent_ids are required, nor how detection_id relates to them, which is the main ambiguity an agent would hit.

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 and resource: find the accessible active case for one detection within a complete account scope. That distinguishes it from the read/list siblings well enough for selection, though it never names an alternative explicitly.

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?

Implies usage via 'for one detection in a complete account scope' and explains the 404 caveat, which is genuinely operational guidance. It stops short of stating when to prefer opencdr_case_read or opencdr_cases_list, so the agent must infer the boundary itself.

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