canli-mcp

Run tools

run_tool

Runs one or up to 25 finance tool calls in one batch, executing independent calls concurrently and passing outputs into later calls via file or result references.

Instructions

Run a tool find_tool named: one ({name, arguments}), or up to 25 ({calls: [...]}). Independent calls run concurrently; a failed call returns its own error and the rest still run. Read-only unless the paper-trading pack is on. Any argument can be {"$file": "path.csv", "column": "close"} (or "columns": [...] / "all") instead of pasted numbers. {"$result": i, "path": "close"} passes batch call i's output into a later call; every result also has a ref ("r1", ...) later calls pass the same way, {"$result": "r1", "path": "close"}, so data never needs copying.

Input Schema

Name	Required	Description
`name`	No	Tool name from find_tool (single call).
`view`	No	Draw the whole result for the person (charts, comparisons, option chains, yield curves, statements, backtest dashboards, order tickets) and return you a summary, where MCP Apps are drawn.
`calls`	No	Several calls in one round trip. Calls without $result references run concurrently.
`digits`	No	Round fractional numbers in the results to this many significant figures (4-6 saves output tokens); whole numbers such as counts, shares and IDs are never changed. Default: as each tool returns them.
`return`	No	For a batch: every result (default) or only the last one.
`select`	No	Return only these fields of each result, as dotted paths, e.g. ["verdict", "multiple_testing.best", "rows.0.accession"] (table rows take column names).
`receipt`	No	Add input and output SHA-256 and pack versions so the result can be recomputed and compared.
`arguments`	No	The tool's arguments (single call).

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 30, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Adds real behavior beyond the annotations: independent calls run concurrently, a failed call returns its own error while the rest still run, and results get refs ("r1") for chaining. The "read-only unless the paper-trading pack is on" clause clarifies why readOnlyHint=false despite most targets being reads, though it sits in mild tension with a dispatcher that could reach mutating tools.

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?

Front-loaded with the core call shapes, then the operational details (concurrency, error isolation, file/result injection). It is dense and semicolon-chained, making it harder to parse than it needs to be, but almost no sentence is filler.

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

Completeness4/5

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

For an 8-parameter nested dispatcher with an output schema, the description covers the highest-risk semantics: batch concurrency, partial failure, and the argument-substitution grammar. The remaining parameters are fully documented in the schema, so nothing critical is missing, though the read-only claim could be qualified more precisely.

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 100%, so the baseline is 3, and the description does go further by documenting the $file and $result/ref substitution syntax that appears nowhere in the schema. However, it says nothing about view, digits, select, return, or receipt, leaving those to the schema alone.

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 opens with a concrete verb+resource (run a tool obtained from find_tool) and immediately distinguishes single vs batch forms, which separates it from find_tool and describe_tool. The phrasing "Run a tool find_tool named" is slightly garbled, but an agent can still tell what the tool does without opening 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 Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: "Tool name from find_tool" signals the discovery-then-execute flow, and the batching sentence implies when to use the array form. There is no explicit when-not guidance (e.g., when to prefer describe_tool first, or when a single call is preferable to a batch).

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

Deploy Server