quantifyme
Server Details
Describe a trading strategy in plain English and deploy a live signal model in one call. No signup.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.6/5 across 11 of 11 tools scored.
Each tool targets a distinct function: browsing community, finding/generating strategies, one-shot deployment, retrieving results, charting, quoting, listing models, and streaming diagnostics. There is no meaningful overlap between tool purposes.
Most names follow a consistent 'verb_noun' pattern (e.g., browse_community, get_quote, list_models), but 'one_shot' deviates from this pattern, reducing consistency slightly.
With 11 tools, the server covers a complete workflow from discovery to deployment and monitoring without being bloated or sparse. The count is well-scoped for its domain.
Core operations are covered: browse, find, generate, deploy, monitor. However, there are notable gaps: no tool to stop or delete a live model, and no tool to update an existing strategy deployment.
Available Tools
11 toolsbrowse_communityBrowse Community Strategies (leaderboard)ARead-onlyIdempotentInspect
Browse the public community leaderboard of published strategies, ranked by a composite performance score (best first). No signup or key needed.
Copy-trade flow: call this to find a top strategy, then pass its `id` to
`one_shot` as `community_id` to deploy a live signal model running that
exact strategy in one call.
Args:
limit: How many top entries to return (default 20, max 200).
Returns:
dict with:
- scripts (list[dict]): ranked entries, best first. Each has:
id (int — pass to one_shot as community_id), username, title,
description, created_at, score, and metrics {total_ret,
sharpe_strat, win_rate, n_trades, mdd, profit_factor}. SHOW the
top few with their win_rate / total_ret so the user can pick one.
- count (int).| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds further context: 'No signup or key needed', and details the return data structure including specific metrics, all consistent with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args and Returns sections, and concise overall. The meta-instruction to 'SHOW the top few...' adds slight verbosity but serves a clear purpose for the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description adequately covers return values and provides a usage flow. It lacks error handling details but is complete for a read-only list tool with minimal parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description thoroughly explains the limit parameter: 'How many top entries to return (default 20, max 200)', adding meaning beyond the schema's minimal definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Browse the public community leaderboard of published strategies, ranked by a composite performance score' using a specific verb and resource, and distinguishes from siblings by mentioning the copy-trade flow and referencing one_shot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly outlines the copy-trade flow: 'call this to find a top strategy, then pass its id to one_shot as community_id', providing clear guidance on when to use this tool and how it connects to a sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_strategyFind a Matching StrategyARead-onlyIdempotentInspect
Find an existing PROVEN strategy that matches a plain-English idea, so you can offer the user a choice — deploy the existing one, or generate a fresh custom one. Mirrors the quantifyme.ai landing experience: "Found by @ (WR/PF) — Use it / Generate fresh".
CALL THIS FIRST when a user describes a strategy idea. Then present the match
(if any) and ASK which they want:
• Use it → one_shot(community_id=<match.community_id>) — deploys the
exact proven strategy (free, no generation).
• Generate fresh → one_shot(prompt="<their description>") — Claude writes a
brand-new custom strategy for them.
If there's no match, just offer to generate fresh.
Args:
description: the user's strategy idea in plain English (e.g. "buy EURUSD
15min when RSI < 30, sell when RSI > 70").
symbol: optional pair to constrain the match (EURUSD, USDJPY, GBPUSD,
USDCHF, USDCAD, AUDUSD, NZDUSD).
timeframe: optional granularity to constrain the match (1min/5min/15min/1h).
Returns:
dict with:
- match: the best existing strategy, or null. When present:
{community_id, title, username, wr, pf, ret, n_trades, symbol,
timeframe}. Pass community_id to one_shot to deploy it unchanged.
- description: echoed back — pass as one_shot(prompt=...) to generate fresh.
- suggestion: a ready-to-show sentence offering the user the choice.| Name | Required | Description | Default |
|---|---|---|---|
| symbol | No | ||
| timeframe | No | ||
| description | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnly, openWorld, and idempotent hints. The description adds context about proven strategies and mirroring a landing experience, along with return field details. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bullet points and clear sections, but slightly verbose in places; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a lookup tool: explains return dict fields, workflow with sibling tools, and integrates with one_shot/generate_strategy. Output schema is detailed in description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates fully: explains description as 'user's strategy idea in plain English' and gives examples/allowable values for symbol and timeframe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds an existing proven strategy matching a plain-English idea, with a specific verb and resource. It distinguishes itself from siblings like generate_strategy and one_shot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'CALL THIS FIRST when a user describes a strategy idea' and provides a detailed workflow: present match, ask user, then call one_shot with specific arguments. Also covers the no-match case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_strategyGenerate Strategy Code (no training)AInspect
Generate Python strategy code (no training/deploy). Use when the user wants raw code.
Args:
features: NL description of features (e.g. "RSI 14, Bollinger Bands").
signals: NL description of signal logic (e.g. "Buy when RSI < 30").
model: ML model name (default Random Forest).
risk: NL risk rules (e.g. "0.5% stop loss").
description: Optional one-line summary; treated as PRIMARY USER REQUEST.
symbol: Currency pair the code should target. One of: EURUSD, USDJPY,
GBPUSD, USDCHF, USDCAD, AUDUSD, NZDUSD. Default EURUSD.
timeframe: Candle granularity. One of: 1min, 5min, 15min, 1h. Default 15min.
claude_model: "sonnet" (default) or "haiku" (faster, higher daily cap).| Name | Required | Description | Default |
|---|---|---|---|
| risk | No | ||
| model | No | Random Forest | |
| symbol | No | ||
| signals | No | ||
| features | No | ||
| timeframe | No | ||
| description | No | ||
| claude_model | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, and the description adds that the tool generates code (consistent). It does not provide deeper behavioral details (e.g., side effects, authentication needs, or rate limits), but with annotations present, the bar is lower.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a clear purpose sentence followed by an 'Args:' block listing parameters. It is front-loaded with the purpose. However, for 8 parameters it is relatively lengthy; a slightly more concise formatting could improve without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to explain return values. It thoroughly documents input parameters, including defaults and constraints. However, it lacks guidance on parameter interdependencies (e.g., whether certain combinations are required) or error handling, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full burden. It adds extensive meaning for all 8 parameters, including natural language descriptions, defaults, and enum lists for symbol and timeframe, and clarifies that description is treated as the primary user request. This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Generate Python strategy code (no training/deploy)' with the verb 'generate' and resource 'strategy code'. It clearly distinguishes from sibling tools (browse_community, list_deployed, list_models, one_shot) which do not generate code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use when the user wants raw code', providing clear context for when to invoke this tool. It also implies not for training/deployment, though it does not explicitly exclude alternatives or mention specific when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_deploy_resultGet Deploy ResultARead-onlyIdempotentInspect
Wait for a one_shot deploy to finish and return its final result.
`one_shot` returns a job_token immediately and the LIVE CARD already streams
progress and renders the interactive backtest chart itself. Call this ONCE with
the token to get the final numbers as TEXT so you can summarize them — it does
NOT render another card (no need for get_model_chart). It BLOCKS until the deploy
finishes (or ~2.5 min); on timeout it returns ok:false + pending:true — call it
again with the same token.
IMPORTANT: if `source == "community"`, the deploy used a PRE-EXISTING strategy by
`@author` — tell the user that, share the `live_url` as the Live dashboard link,
and ask whether they'd like to GENERATE A CUSTOM strategy instead. Use the
`note` field as your guide.
Args:
job_token: the token returned by `one_shot`.
Returns:
dict with: ok, stem, model, live_url, symbol, timeframe, channels (list),
stats:{ret, wr, pf, n, mdd} (out-of-sample test-split metrics — SHOW THESE),
source ("community" | "generated"), author (community username if any),
author_url + strategy_url (render @author and "pre-existing strategy" as those
Markdown links), community_id, suggest_custom (bool), and note (a ready
instruction — follow it). On failure: {ok:false, error} (or {pending:true}).| Name | Required | Description | Default |
|---|---|---|---|
| job_token | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already indicate readOnly and idempotent, the description adds critical behavioral traits: it blocks until completion or ~2.5 min timeout, returns pending:true on timeout, and does not render a new card. These details go beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections, bold text, and lists. However, it is somewhat verbose; some sentences could be combined without losing clarity. Still, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is exceptionally complete, covering all aspects: purpose, usage, blocking behavior, timeout, return format with specific metrics, and community handling instructions. It leaves no ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no description for job_token (coverage 0%), but the description's 'Args' section explains it as 'the token returned by one_shot.' This fully compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Wait for a one_shot deploy to finish and return its final result.' It specifies the verb (wait and return) and resource (deploy result), and explicitly distinguishes from sibling tool get_model_chart by noting that it does NOT render another card.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines: call once with the token after one_shot, explains blocking behavior and timeout handling, and includes important instructions for community source. It also advises against using get_model_chart for this purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_model_chartShow Backtest Chart (equity + trades)ARead-onlyIdempotentInspect
Visualize a trained model's backtest — a cumulative-return chart + trade log + stats.
Use after `one_shot` / `list_models` with the model's `stem` to SHOW the user how it
traded (the "is it actually any good" view). In ChatGPT this renders an interactive
widget. In Claude, render an interactive **artifact** from this tool's structured
output: a line chart of the cumulative return plus a table of the trades.
Args:
stem: The model stem (e.g. "14_EURUSD_15min_Model_24") from `list_models` / `one_shot`.
Returns:
dict with: ok, stem, symbol, timeframe, stats {ret, wr, pf, n, mdd, sharpe},
and trades [{type, entry_time, exit_time, entry_price, exit_price, pnl,
pnl_pct, exit_reason, period}] (most recent ~200). exit_reason is one of
TP / SL / close_only / signal / end. ret/mdd/wr are fractions; pnl_pct is percent.| Name | Required | Description | Default |
|---|---|---|---|
| stem | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and openWorldHint. Description adds specific behavioral details about returned fields (stats, trades) and their formats (e.g., ret/mdd as fractions, pnl_pct as percent). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (use, args, returns). It front-loads the purpose. However, the rendering instructions for ChatGPT and Claude add verbosity; slightly more brevity would improve conciseness without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (chart, trade log, stats), the description covers all necessary details: output structure, trade attributes, stats fields, and platform-specific behavior. The existence of an output schema further reduces the burden, but description already provides comprehensive context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining the 'stem' parameter with an example ('14_EURUSD_15min_Model_24') and its source (list_models / one_shot), adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it visualizes a trained model's backtest with a cumulative-return chart, trade log, and stats. It specifies the verb 'visualize' and the resource 'model's backtest', distinguishing it from sibling tools like list_models or one_shot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use after one_shot or list_models with the model's stem, and describes the expected output. It also provides platform-specific rendering guidance (ChatGPT vs Claude). However, it does not explicitly mention when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_quoteGet Current Price (G7 FX quote)ARead-onlyIdempotentInspect
Get the latest price for a G7 FX pair — a quick "what's it at now" check.
Useful for context before deploying a strategy. The price is the close of
the most recent 1-minute bar from the platform's market feed (not a raw
live tick); FX markets close on weekends, so the `stale` flag marks a bar
that is more than 15 minutes old.
Args:
symbol: G7 pair — one of EURUSD, USDJPY, GBPUSD, USDCHF, USDCAD, AUDUSD,
NZDUSD. Default EURUSD.
Returns:
dict with: symbol, price (latest close), time (bar timestamp, UTC),
change + change_pct (vs the prior 1-min bar), stale (bool).| Name | Required | Description | Default |
|---|---|---|---|
| symbol | No | EURUSD |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant detail beyond annotations: explains price source (1-minute bar close, not live tick), stale flag meaning, and weekend market behavior. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with purpose, usage guidance, and data source explanation in three sentences. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all necessary aspects for a simple read-only tool with one parameter, including return value fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, description lists valid symbols and default, compensating for the schema's lack of description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Get the latest price for a G7 FX pair' with a specific verb and resource. The description distinguishes from sibling tools by focusing on a quick price check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions 'Useful for context before deploying a strategy.' Provides clarity on data source and stale flag, though no explicit 'when not to use' is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_strategy_codeGet Community Strategy CodeARead-onlyIdempotentInspect
Get the actual Python code behind a community leaderboard strategy.
Use after `browse_community`: pass an entry's `id` here to read its real
`feature_engineering()` + `strategy_config()` source so the user can
inspect or tweak it. To deploy it unchanged, pass the same id to
`one_shot` as `community_id`. Read-only, no signup needed.
Args:
community_id: The `id` of a community entry (from `browse_community`).
Returns:
dict with: id, title, username, description, symbol, timeframe,
metrics {total_ret, win_rate, profit_factor, n_trades, mdd, sharpe_strat},
and `code` (the full Python source). SHOW the code to the user, and offer
to deploy it via one_shot(community_id=...) or tweak it first.| Name | Required | Description | Default |
|---|---|---|---|
| community_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint, openWorldHint, idempotentHint. The description adds behavioral context: it is read-only, no signup needed, and returns detailed code and metrics. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with Args and Returns sections, but slightly verbose with instructional tone (e.g., 'SHOW the code to the user'). Still clear and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter and an output schema, the description covers all necessary context: purpose, usage pattern, parameter details, and return format. Complete for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description fully documents the single parameter: 'community_id: The id of a community entry (from browse_community).' This adds meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb+resource: 'Get the actual Python code behind a community leaderboard strategy.' It distinguishes itself from siblings like browse_community and one_shot by specifying the workflow: use after browse_community and before deployment via one_shot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('Use after browse_community'), what to pass (entry's id), and alternatives ('To deploy it unchanged, pass the same id to one_shot as community_id'). Also mentions 'Read-only, no signup needed.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_deployedList Deployed Live ModelsARead-onlyIdempotentInspect
List the user's currently deployed (live) models.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. Description adds specificity that results are scoped to the user's deployed models, which is useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise and front-loaded. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool with an output schema, description sufficiently covers purpose and scope. No additional context needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters present. Baseline score of 4 applies as description does not need to add param info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states action (list) and resource (user's currently deployed/live models). Distinguishes from sibling 'list_models' by specifying 'deployed (live)'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the term 'deployed (live)' but no explicit guidance on when to use vs alternatives like 'list_models' or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_modelsList Trained ModelsARead-onlyIdempotentInspect
List the user's trained models with pre-computed train/test stats.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds behavioral context beyond annotations by mentioning that the output includes pre-computed train/test stats. Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description complements them well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise, and front-loaded with the core purpose. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, robust annotations, and the existence of an output schema, the description is complete. It mentions the key extra detail (stats) that the agent needs to understand what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the baseline score is 4 per guidelines. The description adds nothing about parameters, which is fine since none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (List), resource (user's trained models), and additional detail (pre-computed train/test stats). The name and title are consistent, and it is distinct from sibling tools like list_deployed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage context by specifying the resource and output content, but does not explicitly state when to use this tool versus alternatives (e.g., list_deployed). No exclusion or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
one_shotDeploy Strategy (generate + backtest + go live)ADestructiveInspect
End-to-end deploy: generate strategy → train → deploy live.
One of `prompt` (free-form NL), `preset` (curated winning strategy), or
`community_id` (copy a published community strategy) is required. If more
than one is passed, precedence is community_id > preset > prompt.
Args:
prompt: Natural-language strategy description (e.g. "Buy when RSI < 30, sell > 70").
symbol: Currency pair to backtest on. One of: EURUSD, USDJPY, GBPUSD,
USDCHF, USDCAD, AUDUSD, NZDUSD. Default EURUSD.
timeframe: Candle granularity. One of: 1min, 5min, 15min, 1h. Default 15min.
claude_model: Which Claude variant to use for code generation.
"sonnet" (default — best quality, 1/day free) or "haiku" (faster, 3/day free).
Ignored when `preset` is set (no generation needed).
preset: Curated winning-strategy slug. Skips Claude generation entirely
— deploys a pre-saved strategy known to backtest well on the chosen
symbol. Available slugs: ema_cross_fast, momentum, scalper_stack,
sma_only, trend_ema, volatility, bb_squeeze, all_mix, pivot_kid_ema.
Not every slug exists for every symbol — call list_models afterwards
to confirm what deployed.
community_id: Copy-trade a published community strategy. Pass the `id`
of an entry from `browse_community`. Loads that exact strategy code,
skips Claude generation, then trains + deploys it. `symbol`/`timeframe`
still apply to the backtest+deploy.
webhook_url: Optional webhook to receive live signals.
telegram_chat_id: Optional Telegram chat ID for signal delivery.
Returns IMMEDIATELY (the deploy runs in the background so the live card can
stream progress) with:
- job_token (str): pass to get_deploy_result to fetch the final result.
- poll_url (str): the card polls this for live progress; you can ignore it.
- pending (bool): always true here — the deploy is still running.
- symbol, timeframe (str).
Call this EXACTLY ONCE per request. Pass the user's words as `prompt`; do not
pre-pick presets/community strategies — the server routes (vague → a proven
community strategy, specific rules → a fresh generation).
NEXT STEP (always): call get_deploy_result(job_token) ONCE — it blocks until the
deploy finishes and returns the out-of-sample stats + `stem` + `source`/`author`
as TEXT so you can summarize. The live card already shows the chart, so you do
NOT need get_model_chart. If source='community', tell the user it used a
pre-existing strategy by @author and offer to generate a custom one.| Name | Required | Description | Default |
|---|---|---|---|
| preset | No | ||
| prompt | No | ||
| symbol | No | ||
| timeframe | No | ||
| webhook_url | No | ||
| claude_model | No | ||
| community_id | No | ||
| telegram_chat_id | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Details that the tool is destructive (deploys live), returns immediately with a job_token, and runs the deploy in the background. Explains precedence rules (community_id > preset > prompt) and limitations (not every preset exists for every symbol). Adds context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is thorough and well-structured with sections and bullet points, but somewhat verbose. However, the complexity of the tool (three modes, multiple parameters) justifies the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, annotations, and presence of an output schema, the description is complete: it explains the return value structure, follows-up actions, and edge cases like precedence and missing preset symbols.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully explains all 8 parameters, including examples, defaults, available values for preset and timeframe, and conditional behavior (claude_model ignored when preset is set). This provides comprehensive guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the end-to-end process: generate strategy, train, deploy live. It distinguishes the three input modes (prompt, preset, community_id) and explains how they differ from sibling tools like generate_strategy and get_deploy_result.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call this once per request, not to pre-pick presets/community strategies, and always follow up with get_deploy_result. It also advises against using get_model_chart because the live card already shows the chart.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stream_testLive Streaming DiagnosticARead-onlyIdempotentInspect
Diagnostic: test whether LIVE data streaming works in this client.
Renders a widget with three panels — a JS timer (baseline), a WebSocket to
the live price feed, and an HTTP poll of /quote — each showing a live value
+ status, so you can see exactly which streaming mechanisms the client's
widget sandbox actually permits. Use when a live/ticking chart isn't moving.
Args:
symbol: G7 pair to stream (default EURUSD).| Name | Required | Description | Default |
|---|---|---|---|
| symbol | No | EURUSD |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description reveals that the tool renders a widget with three panels and tests client widget sandbox permissions. This adds meaningful behavioral context without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, front-loaded with purpose, followed by mechanism, usage hint, and parameter details. Every sentence adds value without repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple interface (1 optional param, output schema present, safety annotations), the description covers purpose, mechanism, usage context, and parameter meaning comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining the 'symbol' parameter as 'G7 pair to stream (default EURUSD)', clarifying both the currency pair nature and default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Diagnostic: test whether LIVE data streaming works in this client.' and explains the three panels (JS timer, WebSocket, HTTP poll) used. It distinguishes itself from siblings like get_quote by focusing on streaming diagnostics rather than single quote fetch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use case: 'Use when a live/ticking chart isn't moving.' This gives clear context although it doesn't explicitly mention alternatives or when NOT to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!