Skip to main content
Glama

size_sweep

Read-onlyIdempotent

How big a search would be, without creating anything. THIS IS THE NUMBER YOU SAY OUT LOUD, and it is almost never the number the person named: the draw count is PER WINDOW and Oracle keeps many windows per asset. Oracle counts it by walking exactly what the plan would walk, so nothing else can be trusted to work it out. Free, and repeatable -- call it after every change while the size is being settled, and only create the sweep once the person has agreed to a total. If it comes back capped, their plan scaled the search down and cap_applied says by how much.

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": "size_sweep"
  }
}

Input Schema

NameRequiredDescriptionDefault
assetsNoAsset symbols, e.g. ["BTC", "ETH"].
regimesNoMarket conditions to keep: current, bear, neutral, bull. current means data within the last 30 days, which is recency and not direction. Omitted, every condition.
windowsNoSpecific window files to include whatever else is chosen.
categoriesNoDraw only from these signal classes, e.g. ["momentum"]. The classes are averaging, flow, momentum, oscillator, pattern and volatility. Omitted, the whole library.
candle_sizesNoCandle sizes, e.g. ["1h"]. Omitted, every size Oracle holds for those assets, which multiplies the windows.
exit_filtersNoDraw exit filters only from these.
entry_filtersNoDraw entry filters only from these. Omitted, every filter.
exit_triggersNoDraw an exit trigger only from these. Omitted, no exit signal is drawn at all and runs exit on the risk settings.
param_samplesNoHow many values each signal parameter contributes. The space is their product, so this is the dial that decides whether the search explores parameters at all; at 1 every candidate runs at a single setting.
signal_groupsNoKeep kinds of signal apart. A candidate draws ALL of its signals from ONE group, so two signals in different groups never appear on the same strategy. Runs are split across the groups.
entry_triggersNoDraw the entry trigger only from these signals, named as the knowledge graph registers them. Omitted, every trigger.
execution_baseNoRisk settings every run shares, from the execution config schema. Omitted, platform canon.
include_gappedNoInclude windows missing bars. Off by default, because a metric over a half-covered window is not comparable to one over a whole window.
max_total_runsNoA ceiling on the executed runs, applied by Oracle.
candidate_shapeNoHow many parts a drawn strategy gets, any of n_entry_triggers, min_entry_filters, max_entry_filters, min_exit_triggers, max_exit_triggers, min_exit_filters, max_exit_filters. Omitted, the platform default shape.
execution_sweepsNoExecution parameters to search too, each {param: {min, max, n}}. Every one of these multiplies the run count.
draws_per_datasetNoHow many candidate strategies to draw PER WINDOW. The runs that execute are this multiplied by the number of windows.
pre_filter_thresholdNoSkip a drawn candidate the SIEVE model predicts will not trade at all, above this confidence. A will-it-trade gate and nothing about whether it will make money. Omitted, no skipping.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

The description adds substantial behavioral context beyond the annotations: it is 'free, and repeatable,' it counts by walking the same plan, and it reports capping via 'cap_applied.' These details explain cost, reliability, and limit-handling behavior, which an agent needs in order to interpret and act on results correctly.

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 description is front-loaded with the core purpose and each sentence serves a purpose (purpose, scale clarification, reliability, usage, capping). However, some sentences like 'THIS IS THE NUMBER YOU SAY OUT LOUD' and 'nothing else can be trusted to work it out' are informal and slightly redundant, keeping it from being maximally tight.

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?

For a complex tool with 18 parameters, nested objects, no output schema, and read-only annotations, the description covers what the tool does, why it is trustworthy, when to call it, and what a capped result means. It is complete enough that an agent can use it correctly without needing to infer missing behavior.

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?

With 18 parameters and 100% schema description coverage, the schema already provides full parameter documentation. The description reinforces a key semantic ('draw count is PER WINDOW') and mentions the 'cap_applied' return field, but it does not add meaning beyond the schema for most parameters. Baseline 3 is appropriate.

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 states a specific purpose: estimating how large a sweep search would be without creating anything. It distinguishes itself from creation siblings by emphasizing 'without creating anything' and 'only create the sweep once the person has agreed to a total.' An agent can immediately tell this is a dry-run sizing tool.

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?

Explicit guidance is given: 'call it after every change while the size is being settled' and 'only create the sweep once the person has agreed to a total.' This clearly defines when to use the tool and when to defer to create_sweep, leaving no ambiguity about its place in the workflow.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.