Skip to main content
Glama
LeoLourson

MacroStress

by LeoLourson
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

run

Starts Bayesian VAR scenario path draws and calculates portfolio or supplied positions; reports job status, loss results, target forecasts, and lists workspace jobs.

Instructions

Runs on the paths of a scenario. Actions: start, status, result, list.

start draws the scenario's paths and calculates a portfolio's positions — or the positions given in the call — on them, as a job on the runs resource; status reports that job and what the run has written, result the per-position results, the conditional forecast of the targets (forecast.json: P5/P50/P95 of every target driver by month, in its own unit; every driver when targets is omitted) and the report of a portfolio run, list every run of the workspace. base_currency is the base of positions; a portfolio brings its own.

Input Schema

NameRequiredDescriptionDefault
idNo
seedNo
drawsNo
actionYes
targetsNo
scenarioNo
portfolioNo
positionsNo
base_currencyNoRUB

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.2.0
    • addedInput schema / properties / targets
      Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}
  2. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that 'start' runs as an asynchronous job on the 'runs' resource and that 'result' returns forecast percentiles — real behavioral context. But it omits side effects of 'start', permission needs, idempotency, and what 'status'/'result' require (e.g., an id), leaving key behavior implicit.

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 one-line summary is front-loaded and the per-action breakdown is dense with information and formatted with backticked identifiers. Length is justified by the multi-action surface, though the final sentence on base_currency is slightly cryptic.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value detail is not required, and the action lifecycle is well covered. But for a 9-parameter, multi-action tool with no annotations, the unexplained 'id', 'seed', and 'draws' parameters and absent side-effect disclosure leave an agent guessing on some invocations.

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 0%, so the description must compensate. It clarifies base_currency ('base of positions; a portfolio brings its own'), targets (defaults to every driver when omitted, forecast with P5/P50/P95), and positions/scenario/portfolio roles. However, 'id', 'seed', and 'draws' are never explained as parameters, leaving 3 of 9 undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb+resource ('Runs on the paths of a scenario') and enumerates four distinct actions, each with a concrete outcome (start draws paths and computes positions; result returns per-position results and P5/P50/P95 forecasts). It is far more specific than the generic name 'run', though it never explicitly differentiates itself from siblings like jobs or scenario.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explaining the four actions implies the lifecycle (start → status → result, list to enumerate), which gives latent usage guidance. However, there is no explicit statement of when to prefer this tool over the 'jobs', 'scenario', or 'portfolio' siblings, and no exclusions or prerequisites.

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

Deploy Server

Other Tools