Skip to main content
Glama

aureon_apply_market_event

Shock a portfolio mark by applying a fractional price change to an asset symbol; optionally auto-restore if portfolio objectives breach.

Instructions

Apply a controlled market event to portfolio marks; optionally auto-restore

Input Schema

NameRequiredDescriptionDefault
nameNoEvent label
symbolYesAsset symbol to shock
autoRestoreNoOpt in to run restore if objectives breach. Omit or false = drift only. Automatic still 409s if the vault cannot execute.
descriptionNoEvent description
priceChangeRatioYesFractional price change (e.g. -0.15 = -15%)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.16

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden, yet it only supplies 'controlled' and 'optionally auto-restore'. It omits whether permissions are required, whether the shock is reversible, and what side effects occur on portfolio marks. The richest behavioral detail (409 on non-executable vault) lives in the schema, not the description.

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?

A single front-loaded sentence with the mutation intent stated first and the optional behavior trailing. Efficient, though borderline terse for a mutation tool in a complex domain.

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

Completeness2/5

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

For a no-annotation mutation tool with no output schema in a portfolio-risk domain, the definition is thin: it omits auth/authorization needs, reversibility, and side effects. The schema compensates on parameter detail but not on operational context.

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%, so every parameter is already documented in the schema (including the autoRestore 409 caveat). The description adds no syntax, format, or constraint information beyond that, so the baseline 3 applies.

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?

Specific verb+resource+target: 'Apply a controlled market event to portfolio marks'. An agent can tell it mutates portfolio marks. It does not, however, differentiate itself from near siblings like aureon_list_market_presets or aureon_apply_financial_intent.

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

Usage Guidelines2/5

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

The description gives no when-to-use, when-not-to-use, prerequisites, or named alternatives. The 'optionally auto-restore' phrase hints at a behavior toggle but provides no selection guidance.

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