FILTRIX.net

save_run

Save a backtest (same arguments as run_backtest) as a named run in the caller's FILTRIX account; it appears in the app's Context tab and can be simulated, shared or reopened. Runs as a background job: waits up to wait_seconds (max 50) and returns the finished job (result.run_id, pairs_saved, rows_saved, summary), or {job_id, status} to poll with get_job. Counts against the plan's saved-run limit. Needs a verified email and write access.

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": {
      "filters": "<filters>"
    },
    "name": "save_run"
  }
}

Input Schema

Name	Required	Description	Default
`name`	No	Name shown in the app's Context runs (max 100 characters).
`filters`	Yes	Conditions that must all hold (AND-joined, max 20). Column names come from search_filters.
`outcome`	No	Outcome to measure: day_close_position (default), day_return, reg_pct, hi_to_cl_pct or lo_to_cl_pct. Units and definitions: get_meta.	day_close_position
`pos_max`	No	day_close_position only: a close above this (0..1) counts as long (default 0.8).
`pos_min`	No	day_close_position only: a close below this (0..1) counts as short (default 0.5).
`end_date`	No	Last event date to include, YYYY-MM-DD (default: latest).
`threshold`	No	Cut-off in the outcome's unit (0.05 = 5% for day_return, 5 = 5% for reg_pct, 0..1 for day_close_position); prob_le_threshold is the share of events at or below it.
`row_filter`	No	Which events to keep in the run: all; positive (long side: above pos_max for day_close_position, above 0 otherwise); negative (short side); neutral (in between); nonzero (positive or negative).	all
`start_date`	No	First event date to include, YYYY-MM-DD (default: start of history).
`wait_seconds`	No	Seconds to wait for the job to finish (0..50) before returning its job_id to poll with get_job.
`flat_threshold`	No	Half-width of the 'flat' zone for the long/short/flat split, as a fraction (0.002 = 0.2%). Ignored for day_close_position.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations only declare write/non-idempotent/open-world, so the description carries real weight and delivers: asynchronous job semantics, a hard cap of 50 seconds on wait_seconds, the two possible return shapes with their key fields (result.run_id, pairs_saved, rows_saved, summary / job_id+status), a plan quota, and the auth requirements (verified email, write access). That is exactly the behavioral context an agent needs before firing a mutation.

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?

Four sentences, front-loaded with purpose then the async behavior, then limits and prerequisites — no filler. It is dense (job semantics, return shapes, quota, auth all in one block) but every clause carries information an agent would otherwise have to discover by trial.

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 an 11-parameter write tool with an output schema, the description covers the remaining gaps: execution model, timeout ceiling, polling path via get_job, quota impact, and access requirements. Since an output schema exists it did not need to enumerate return fields, yet it names the key ones anyway, leaving nothing material unspecified.

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 description coverage is 100% and every parameter — filters, outcome, pos_min/pos_max, row_filter, threshold, flat_threshold, dates, wait_seconds — is fully documented in the schema itself. The description adds only the cross-reference that the arguments mirror run_backtest and that wait_seconds maxes at 50, which is useful but marginal. Baseline 3 applies when the schema does the heavy lifting.

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 ('Save a backtest ... as a named run') and pins down the scope by cross-referencing the sibling run_backtest ('same arguments as run_backtest'). It also states where the result surfaces (the app's Context tab) and what can be done with it (simulated, shared, reopened), which is enough to separate it from run_backtest, list_runs and save_paper_strategy.

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 tells the agent how the call behaves in time (background job, waits up to wait_seconds, otherwise returns {job_id, status}) and names the follow-up tool (get_job) for polling, plus the prerequisites (verified email, write access, plan limit). What is missing is an explicit statement of when to prefer this over run_backtest — the agent must infer that saving is the differentiator — and there is no mention of delete_run/archive for cleanup.

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

All FILTRIX.net tools Inspect

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

Need Help?