Skip to main content
Glama
Sign In

PropPassCheck

by com.proppasscheck
OverviewDiscussionsAdmin

Test a strategy from its headline numbers

test_stats
Read-only

For a trader with no trade list: estimates the chance of passing, the chance of a first payout and the likely fees per payout from a win rate, reward-to-risk, risk per trade and trades per day. It treats every win and every loss as the same size and every day as alike, so it is rougher than a test of real trades and usually a little optimistic.

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": {
      "win_rate": "<win_rate>",
      "reward_to_risk": "<reward_to_risk>",
      "risk_per_trade": "<risk_per_trade>",
      "trades_per_day": "<trades_per_day>"
    },
    "name": "test_stats"
  }
}

Input Schema

NameRequiredDescriptionDefault
firmNoOr: part of a firm name, to test that firm's accounts. Leave both out to rank every account.
win_rateYesPercentage of trades that win, for example 45.
challenge_idsNoUp to 10 PropPassCheck account ids.
reward_to_riskYesAverage win divided by average loss, for example 2 for a 1:2 strategy.
risk_per_tradeYesPercentage of the account lost on a losing trade, for example 1.
trades_per_dayYesAverage trades per trading day, for example 1.5.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already establish this is a read-only, closed-world, non-destructive calculation. The description adds genuine value beyond them by disclosing the modeling assumptions (uniform win/loss size, identical days) and the resulting bias ('usually a little optimistic'), which tells the agent how much to trust the numbers.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler, and the audience/scope constraint is front-loaded before the caveats. Every clause carries information the agent cannot get from the schema or annotations.

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 a six-parameter read-only estimator with no output schema, the description covers inputs, estimated outputs, and accuracy caveats. It is slightly thin on what the response looks like when firm and challenge_ids are omitted and the tool ranks every account, but the schema hint covers that adequately.

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% and each parameter already carries a range and example, so the schema does the heavy lifting. The description only names the four required inputs without adding format or interpretation guidance, and it does not touch the optional firm/challenge_ids selectors at all. Baseline 3 applies.

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 action (estimates) and three concrete outputs (chance of passing, chance of first payout, likely fees per payout) plus the four inputs that drive them. The opening qualifier 'For a trader with no trade list' immediately separates it from the sibling test_trades, which works from real trades.

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?

The condition 'For a trader with no trade list' is an explicit when-to-use rule and implicitly defines the when-not (if you have a trade list, use the real-trades test). It never names that alternative tool outright, so an agent must infer the sibling, but the context is clear.

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