trading-research-agents

Official

by BijectiveLabs

Overview Schema Source Related Servers Discussions Admin

Python

Local

Search the kill ledger

search_ledger

Read-only

Search the kill ledger for past verdicts mentioning query words. Use it to check if an idea already died and at what fee it would reverse.

Instructions

Search the kill ledger for verdicts that mention the words in query.

Matches the subject, note, evidence and axis of every row that stands, and ranks rows by how
many words they contain. Ask here before proposing an idea: if it already died, the row says
of what and at which fee it would reverse. Read-only. Returns the query, the number of rows
matched and up to `limit` of them, best first.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	most rows to return
`query`	Yes	words to look for; a row matches when it contains any of them
`ledger_path`	Yes	path to the kill ledger, ledger.jsonl

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 19, 2026

TDQS

A4.4/5.0

Behavior4/5

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

'Read-only' merely restates readOnlyHint, so it earns no credit, but the description adds real behavior beyond annotations: which fields are matched, that ranking is by word-overlap count rather than recency, and that results come back 'best first'. It does not discuss pagination or cost of a large ledger scan, which is the main remaining gap.

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 action and the matching scope, then the ordering guarantee. It runs five sentences and the domain-flavored clause about 'at which fee it would reverse' is slightly ornamental, but nothing is redundant.

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?

A search tool with three params, 100% schema coverage, full annotations and an output schema needs little more; the description still covers trigger context, matching fields and result ordering. An agent has everything required to call it correctly.

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 description coverage is 100%, so the baseline is 3, but the description adds the ranking/ordering semantics ('ranks rows by how many words they contain', 'up to limit of them, best first') that determine which rows survive the limit. That is meaning the schema itself does not convey.

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?

States a specific verb ('search') plus resource ('the kill ledger') and narrows the scope to 'verdicts that mention the words in query', then names the exact fields searched (subject, note, evidence, axis). This is distinguishable from siblings like show_ledger or list_runs without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

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

'Ask here before proposing an idea: if it already died, the row says of what and at which fee it would reverse' gives a clear trigger condition for when to reach for this tool. It does not explicitly name an alternative (e.g. show_ledger for a full dump), so it stops short of full when-not guidance.

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

Deploy Server