fraud-mcp

Get recent transactions

get_transactions

Read-onlyIdempotent

Retrieve an account's transaction history within a specified lookback window to support fraud investigations. Returns a summary with evidence for review.

Instructions

Return an account's transactions within a lookback window, with a summary.

This is EVIDENCE, not a verdict. It does not evaluate risk. To learn whether
an account has tripped any fraud rule, call `evaluate_fraud_rules` - reading
these rows and forming your own opinion is exactly what this server is built
to prevent.

Returns an error envelope (`ok: false`) for unknown accounts or an out-of-range
`days`. A successful response with zero transactions carries an
`empty_result_guidance` block explaining what the emptiness does and does not
imply; read it before drawing any conclusion.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`days`	Yes	Lookback window in days, counted back from the dataset's frozen `as_of` clock (NOT from today's date). Use 7-30 for a velocity or takeover review; 90+ to establish a spending baseline or to investigate a dormant account. An empty result means the window was too narrow, not that the account is clean.
`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

A5/5.0

Behavior5/5

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

Beyond the readOnlyHint and idempotentHint annotations, the description discloses the error envelope for unknown accounts or out-of-range days, the empty_result_guidance block on empty success responses, and the frozen 'as_of' clock behavior. It also warns that reading these rows does not constitute a risk assessment. 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 main description is three compact, information-dense sentences. The 'EVIDENCE, not a verdict' warning is front-loaded, and the error/empty-result behavior is stated in the last sentence. Parameter descriptions add targeted guidance without redundancy.

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?

With a full input schema, an output schema, and safe-read annotations, the description still covers the essential behavioral edge cases: error responses, empty-result interpretation, and the exact distinction from evaluate_fraud_rules. Nothing critical for a correct call is missing.

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

Parameters5/5

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

Even though the schema already documents both parameters at 100%, the description adds high-value semantics: days are counted from a frozen as_of clock, 7-30 vs 90+ refer to review types, and account_id must be copied exactly as-is. This is a strong layer beyond the schema.

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 object: 'Return an account's transactions within a lookback window, with a summary.' It also explicitly contrasts itself with evaluate_fraud_rules, making the tool's non-verdict role clear and distinguishing it from the most natural sibling.

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?

It states when this tool is appropriate ('EVIDENCE, not a verdict') and explicitly routes to evaluate_fraud_rules when risk evaluation is needed. It also gives concrete lookback guidance: 7-30 days for velocity/takeover reviews and 90+ days for baselines or dormant accounts.

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

Deploy Server