Backtrader MCP

Overview Schema Source Related Servers Discussions Admin

Register Local Dataset

register_local_dataset

Idempotent

Register local market data feeds from a DataSpec v1, supporting CSV, pandas, and custom formats with direct, resample, or replay options.

Instructions

    Accepts the six typed adapters (generic_csv, backtrader_csv, yahoo_csv,
    mt5_csv, pandas, pandas_custom_lines) with optional bar_operation
    (direct/resample/replay). Rejections enumerate the valid values.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`data_spec`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Sep 20, 2026

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already establish that this mutation is idempotent and non-destructive. The description adds useful behavioral detail: the set of accepted adapters, valid bar_operation modes, and the fact that invalid values are rejected with an enumeration of valid options.

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?

The description is compact and front-loaded with the core purpose, followed by the key allowed values. The unexplained 'hash-bound' terminology costs some clarity, but no sentence is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite an output schema and useful annotations, the open, nested data_spec parameter is underdocumented: an agent cannot confidently construct the DataSpec v1 or understand what 'one or more local feeds' requires. The description also fails to position the tool against the closely named register_dataset sibling.

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?

With 0% schema description coverage, the description is the only source of meaning for the data_spec object. It contributes adapter names and bar_operation values, but does not define the structure or semantics of a 'hash-bound DataSpec v1' or how multiple feeds are expressed, leaving a substantial gap.

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 identifies a concrete action, registering local feeds, and the resource (a hash-bound DataSpec v1). The 'local' qualifier and the adapter list distinguish it from sibling register_dataset, though it does not explicitly contrast them.

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 tool's scope is implied by 'local feeds' and by listing the six accepted adapters, but there is no explicit when-to-use guidance, no exclusion criteria, and no mention of register_dataset as the alternative for non-local registration.

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