Detection Workbench

Overview Schema Source Related Servers Discussions Admin

add_finding

Record a concise finding backed by existing run and evidence IDs to keep detection observations traceable; new findings start as open for review.

Instructions

Record a short statement supported by specific runs, e.g. 'SID 1000042 fires 300 times, 95% from 10.0.4.20'. Run and evidence ids must exist. Starts as status 'open'. Example: add_finding(statement="SID 1000042 is dominated by one scanner", run_ids=["r-0002"])

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": {
      "statement": "<statement>",
      "run_ids": "<run_ids>"
    },
    "name": "add_finding"
  }
}

Input Schema

Name	Required	Description	Default
`run_ids`	Yes
`statement`	Yes
`evidence_ids`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 23, 2026

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description carries the full behavioral burden. It discloses that referenced ids must exist and that the new finding starts with status 'open', but it omits permissions, duplicate handling, return behavior, and other mutation 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.

Conciseness5/5

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

The description is front-loaded, compact, and uses examples efficiently. The inline statement example and the example call serve different purposes without adding substantial waste.

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 mutation tool with no annotations, 0% schema coverage, and no output schema, the description covers the core purpose, id existence constraints, initial status, and an example. It still leaves gaps around return values, optional evidence behavior, and side effects.

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 coverage is 0%, so the description must compensate. It explains that statement is a short supported assertion and illustrates run_ids through the example, while also noting evidence ids must exist, but it does not clarify that evidence_ids is optional or define array semantics.

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 states a specific verb and resource: 'Record a short statement supported by specific runs.' It is clear what the tool creates, but it does not explicitly distinguish it from siblings such as update_finding or add_note.

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?

The description gives a prerequisite ('Run and evidence ids must exist') and an invocation example, implying when the tool is appropriate. It does not explain when to use add_finding versus update_finding or add_note, nor does it state exclusions.

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