Skip to main content
Glama
Sign In
stockscreen-mcp

stockscreen-mcp

by xang1234
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

screen_track_record

Read-only

Track how stocks performed after entering a preset screen at a set holding period, so you can judge how much weight a screen's output deserves or check whether it has a record yet.

Instructions

What happened after stocks newly entered each preset screen, at one holding period.

Use it to judge how much weight a screen's output deserves, or to see whether a screen has a record yet. Use run_screen for today's matches. Each call reports one horizon; call again with horizon=5 or horizon=60 for the others.

Rows in cohorts keep the published order, which is not a ranking. how_to_read in each result defines the fields; read it before quoting a number.

Any response over 80,000 characters of JSON is refused with an error; pass screen for one screen's rows.

A market with no published record returns an error naming the markets that have one. In list_markets those markets show the track_record feature.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "screen_track_record"
  }
}

Input Schema

NameRequiredDescriptionDefault
marketNoMarket code, e.g. US, HK, JP, IN, DE. See list_markets.US
screenNoPreset id, e.g. minervini. Retired screens that list_screens no longer has are still accepted; defaults to every recorded screen.
horizonNoSessions each pick is held: 5, 20 or 60.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.2

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only cover readOnly/openWorld; the description adds genuinely new behavior: an 80,000-character response cap that returns an error, the workaround of passing a single `screen`, and an error naming available markets when no record exists. It also pre-empts misreading by stating cohorts preserve published order and are not a ranking.

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 purpose leads, followed by usage, then output-reading and failure-mode caveats in short paragraphs. Nearly every sentence carries information, though the 'how_to_read in each result' instruction is somewhat procedural and could be folded more tightly.

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 an output schema present, the description needn't enumerate return fields, and it correctly delegates that to how_to_read. It still covers the failure paths, the size limit, and the ordering caveat, leaving nothing an agent needs 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 coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: each call reports only one horizon (so horizon=5 or 60 requires another call), and passing a single screen is the remedy for oversized responses. It also implies screen defaults to all recorded screens, consistent with the schema default.

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 resource and scope: post-entry performance of stocks that newly entered a preset screen, at one holding period. It explicitly contrasts itself with the sibling run_screen ('today's matches'), so an agent can route between the retrospective and the live tool without opening either schema.

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?

Gives two concrete reasons to call it (judge weight of a screen's output, check whether a screen has a record yet) and names the alternative plus the condition that selects it ('Use run_screen for today's matches'). It also tells the agent how to get other horizons by repeat calls, which is the main usage trap for this tool.

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