fraud-mcp

Flag an investigation case

flag_case

Record an auditable fraud case for an account by citing fired rule IDs, severity, and evidence, enabling human review of investigation outcomes.

Instructions

Record an investigation outcome against an account. THIS WRITES TO THE CASE LOG.

Call this only after `evaluate_fraud_rules`, and only when you can cite the
rule ids that fired. The response includes an `audit` block that independently
re-runs the rules engine and compares your submission against it: if you cite
rules that are not firing, omit rule ids entirely, or set a severity the engine
does not support, the case is still recorded but flagged with warnings for the
human reviewer.

Not idempotent - each call creates a new case. Do not retry on success.

Input Schema

TableJSON Schema

Name	Required	Description
`reason`	Yes	Written justification, minimum 20 characters. MUST name the rule ids that fired and the transaction ids they cite, e.g. 'STRUCTURING fired: five transfers TXN-001234..TXN-001238 of 9.1k-9.7k within 40h, each below the 10k reporting threshold.' A reason without evidence cannot be reviewed by a human analyst and will be marked unsupported.
`rule_ids`	No	The rule ids that justify this case - pass `fired_rule_ids` from the evaluate_fraud_rules response verbatim. Omitting this records the case as UNSUPPORTED and unauditable. Always call evaluate_fraud_rules first so you have real ids to pass.
`severity`	Yes	Case severity. Use the `highest_severity_fired` value returned by evaluate_fraud_rules. Do not pick a severity by intuition - if you deviate from the engine's value, the response will record a warning and you must justify it.
`account_id`	Yes	Account identifier in the exact form 'ACC-####' (e.g. 'ACC-1013'). Copy it from a previous tool response or the user's message; do not invent or reformat it.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 14, 2026

TDQS

A4.7/5.0

Behavior5/5

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

The description goes well beyond the annotations: it discloses that the call writes to the case log, that the response contains an audit block re-running the rules engine, and what happens when the submission mismatches the engine. It also adds actionable non-idempotency guidance: 'Not idempotent - each call creates a new case. Do not retry on success.' No contradiction with annotations.

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 compact and front-loaded with the core purpose, followed by the key usage condition, audit behavior, and idempotency warning. Every sentence adds operational value; there is no filler or repetition that weakens it.

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 write tool with a rich schema and output schema, the description covers prerequisites, correctness constraints, response audit behavior, and retry policy. An agent has everything needed to decide whether and how to call this tool correctly.

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 description coverage is 100%, and the parameter descriptions already document the rule-id source, severity alignment, account format, and reason requirements. The main description reinforces these, but it does not add meaning beyond what the schema already provides, so the baseline of 3 is appropriate.

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: 'Record an investigation outcome against an account.' It also names the case log and the prerequisite sibling (`evaluate_fraud_rules`), so an agent can distinguish this tool from get_transactions and lookup_device_history without needing the schema.

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?

Usage is explicit: 'Call this only after evaluate_fraud_rules, and only when you can cite the rule ids that fired.' This clearly states when the tool should be used and positions it relative to the preceding rules-evaluation step, with no ambiguity about sequencing.

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

Deploy Server