Skip to main content
Glama
Sign In

PropPassCheck

by com.proppasscheck
OverviewDiscussionsAdmin

Test a trader's own trades against challenge rules

test_trades
Read-only

Replays a list of closed trades 1,000 times against prop firm challenge rules and returns, per account: the chance of passing, the chance of reaching a first payout, the usual number of trading days, why failed attempts failed, the average number of attempts, and the likely fees per first payout with the funded profit needed to win them back. Give every closed trade's profit or loss in money and the starting balance of the test. Include each trade's close date when known, so busy and quiet days are kept as they happened. Name up to 10 challenge ids, or a firm, or leave both out to rank every account. Needs real closed trades, not figures made up from a win rate.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "trades": "<trades>",
      "starting_balance": "<starting_balance>"
    },
    "name": "test_trades"
  }
}

Input Schema

NameRequiredDescriptionDefault
firmNoOr: part of a firm name, to test that firm's accounts. Leave both out to rank every account.
scaleNoTrade size multiplier to test, default 1 (as traded).
tradesYesClosed trades in the order they closed.
challenge_idsNoUp to 10 PropPassCheck account ids.
trades_per_dayNoOnly used when the trades have no dates. Default 2.
starting_balanceYesAccount balance the trades started from, in the same currency as the profits.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare this as a safe non-destructive read; the description goes far beyond them by disclosing the 1,000-iteration simulation, the full set of returned per-account metrics (pass chance, first-payout chance, trading days, failure reasons, average attempts, fees and required funded profit), and the data-quality requirement for real trades. That is exactly the context an agent needs before committing to an expensive-looking computation.

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 content is front-loaded with the operation, then the return set, then input requirements, and nothing is redundant. The long enumerated return list is dense as a single sentence, but it earns its place because there is no output schema to carry that information.

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 six parameters, no output schema, and a simulation-heavy behavior, the description covers what the tool does, what it returns, what inputs it demands, and how scope selection works. An agent could call this correctly without consulting anything else.

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 genuine meaning: it explains that dates are included so busy and quiet days are preserved as they occurred, which clarifies why the optional date field matters to the simulation. It also restates the money-denominated profit and starting balance requirement, reinforcing units and currency consistency.

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?

The description opens with a specific verb and resource: replaying a list of closed trades against prop firm challenge rules, 1,000 times, and enumerating the per-account results. That distinguishes it cleanly from siblings like test_stats or compare_challenges, since it operates on raw trade lists rather than summary statistics.

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?

It gives clear selection guidance for the account scope ('name up to 10 challenge ids, or a firm, or leave both out to rank every account') and an explicit exclusion: real closed trades are required, not figures derived from a win rate. It stops short of naming the sibling tool an agent should use for win-rate inputs, so the alternative is implied rather than stated.

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

All PropPassCheck toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources