Skip to main content
Glama
BijectiveLabs

trading-research-agents

Official
by BijectiveLabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Audit a dataset (data gate)

audit_dataset
Read-only

Validate raw trade archives before backtesting or event observation; normalise via venue plugin or column map, then report rejected rows, gaps, scale shifts, and outlier days with severity.

Instructions

Audit a raw trade archive before anything is tested on it.

Normalises the file through a venue plugin (`venue`) or a column map (`mapping_path`), exactly
one of the two, and checks it: rows that do not become trades, gaps longer than
`max_gap_minutes`, price and size scales that change inside the file, and days that carry most
of the rows. Use it on any new dataset; `observe_events` and a backtest assume a file that
passed. Read-only. Returns `passed`, accepted and rejected row counts, the first and last
timestamps, and each finding with its severity ("fail" or "warn").

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
venueNoan archive venue plugin name; leave empty when giving mapping_path
instrumentYesthe instrument the archive should contain, e.g. BTCUSDT
archive_pathYespath to the raw trade archive (csv, csv.gz or zip)
mapping_pathNopath to a column map (mapping.toml); leave empty when giving venue
max_gap_minutesNoa gap between trades longer than this is reported

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / properties / archive_path / description
      Added value: +"path to the raw trade archive (csv, csv.gz or zip)"
    • addedInput schema / properties / instrument / description
      Added value: +"the instrument the archive should contain, e.g. BTCUSDT"
    • addedInput schema / properties / mapping_path / description
      Added value: +"path to a column map (mapping.toml); leave empty when giving venue"
    • addedInput schema / properties / max_gap_minutes / description
      Added value: +"a gap between trades longer than this is reported"
    • addedInput schema / properties / venue / description
      Added value: +"an archive venue plugin name; leave empty when giving mapping_path"
  2. First observedv0.7.1

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description's 'Read-only.' is partly redundant with that. It does add real behavioral context by enumerating the specific checks performed and the 'fail'/'warn' severity model on findings, which annotations cannot express.

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?

Purpose and the exclusivity rule are front-loaded in two tight paragraphs with no filler. The trailing list of return fields is somewhat redundant because an output schema exists, keeping it short of perfect.

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?

It covers the purpose, the precondition chain to observe_events/backtest, the checks performed, the parameter exclusivity rule, and the severity vocabulary. Return-value detail is already handled by the output schema, so nothing an agent needs to call this correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description earns above that by stating the venue/mapping_path parameters are mutually exclusive and one is required, a constraint the schema only hints at. It otherwise leaves format/permission details to 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?

Opens with a specific verb+resource and scope: 'Audit a raw trade archive before anything is tested on it.' It also spells out exactly what the audit covers (non-trade rows, gaps, scale changes, dominant days), which separates it from siblings like validate_trades and observe_events.

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?

'Use it on any new dataset' plus 'observe_events and a backtest assume a file that passed' gives an explicit precondition and names the downstream tools that depend on it. It also states the venue/mapping_path choice is 'exactly one of the two', removing a real invocation ambiguity.

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