Skip to main content
Glama

aureon_list_market_presets

List available market event simulation presets to choose scenarios for testing financial strategies or preparing market event simulations.

Instructions

Available market event simulation presets

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.16

TDQS

C2.7/5.0
Behavior2/5

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

With no annotations at all, the description carries the full burden of behavioral disclosure. It implies a read-only enumeration, but never states that the call is side-effect free, whether the preset list is static or account-specific, or whether any auth is required. For a zero-annotation tool this is a real gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Five words with no filler, which is appropriately tight for a trivial list endpoint. However, the brevity crosses into under-specification: it is a label rather than a sentence, so it is concise but not informative.

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?

There is no output schema, so the description should at minimum hint at what a preset looks like or how the returned identifiers feed into aureon_apply_market_event. Neither is present, and with no annotations the safety and auth profile is also absent. For such a simple tool the bar is low, but the definition still leaves the agent without a usable next step.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes no parameters, so there is nothing for the description to disambiguate; the baseline of 4 for a 0-parameter schema applies. No parameter information is missing because none exists.

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

Purpose3/5

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

The phrase 'Available market event simulation presets' identifies the resource (presets) and its domain (market event simulation), so an agent can guess this enumerates them. But it is a bare noun fragment with no verb and no differentiation from siblings such as aureon_apply_market_event, which consumes exactly these presets. Purpose is inferable rather than stated.

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?

There is no when-to-use guidance and no mention of the obvious companion tool aureon_apply_market_event, which is presumably why an agent would fetch these presets in the first place. The agent is left to infer the workflow entirely from the name.

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