SCRIPTMASTERLABS — MNEMOS Options Radar

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, so the safety profile is covered. The description adds two facts annotations cannot convey: the call is paid (0.002 USD) and the payment protocol is x402, which is essential context for an agent deciding whether it can afford to invoke it. It stops short of describing venue coverage or result freshness.

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

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

Two fragments, cost first, action second — front-loaded and waste-free. It borders on under-specification rather than verbosity, but every word carries signal.

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

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

For an open-world, paid scan with no output schema, the definition leaves meaningful gaps: what venues are compared, what the scan returns (opportunities, spreads, depth?), and how fresh the data is. The payment flow is adequately covered by the schema, but the core value proposition of the scan is only named, not explained.

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

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

Only one parameter and schema description coverage is 100%, so the payment_signature semantics (omit to receive payment requirements) are fully documented in the schema. The description adds nothing about the parameter beyond repeating that the call is paid, so baseline 3 applies.

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

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

States a specific action and resource: a cross-venue arbitrage scan, plus its paid x402 pricing. An agent can tell it apart from the sibling tools (scorecard, bars, gas, options) since none of them cover arbitrage, though the description never names those alternatives or the venues scanned.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives. The only routing signal is the name itself; the agent must infer that this is the tool for cross-venue arb opportunities rather than, say, mnemos_options_scan.

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

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

The description restates all four annotation values verbatim, which adds no information beyond the structured fields, though it does gloss readOnlyHint with 'reads a published scorecard, mutates nothing' and adds the useful scope caveat 'Not user P&L'. It discloses nothing about what the scorecard actually returns, whether results are time-stamped or cached, or what 'prospective' implies — with annotations present the bar is lower, but this earns only a middling score.

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

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

Extremely short and front-loaded, with the most useful scoping fact ('Not user P&L') appearing early. It is telegraphic sentence fragments rather than structured prose, and the verbatim annotation enumeration is low-value padding, but there is no rambling to cut.

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

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

With no parameters and no output schema, the description carries the burden of explaining what a caller gets back — and it never says. 'Scorecard', 'methodology' and 'prospective signal observations' are left undefined, so an agent knows the tool is a free read-only public lookup but not what it would actually receive or how to use the result alongside mnemos_arb_scan or mnemos_bars.

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

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

The tool takes zero parameters and the schema is empty, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter-level meaning is missing.

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

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

The description indicates the tool surfaces a published scorecard containing public methodology and 'prospective signal observations', which is more informative than the bare name. But it never uses an explicit verb ('returns', 'retrieves') and never distinguishes this from siblings like mnemos_decisions or mnemos_status, so an agent must guess where this fits in the toolset.

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

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

The only routing-style guidance is the negative 'Not user P&L', which rules out one misuse but says nothing about when to prefer this over mnemos_astra_scorecard's siblings. No prerequisites, no trigger conditions, no named alternative.

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

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

Annotations already cover the safe/idempotent/read-only profile, and the description adds genuinely new behavior: a paid x402 call at 0.001 USD and a documented failure mode when no real data source is connected. It still omits pagination or response shape, keeping it below 5.

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

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

A single compact sentence with the pricing and failure behavior front-loaded and no filler. It is slightly telegraphic, but nothing is wasted.

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

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

With no output schema and an undocumented 'limit' parameter, the description should say something about the bar format (granularity, time range, count) to let an agent call it correctly. It covers cost and failure but not the shape or scope of what comes back.

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

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

Schema description coverage is only 33% and the description adds nothing about parameters, notably leaving 'limit' undefined in both places. Only payment_signature is documented, and that documentation lives in the schema, not the description.

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

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

States a specific resource (real broker price bars) scoped to one symbol, which is clearly distinct from sibling tools like mnemos_options_scan or mnemos_arb_scan. It does not name a sibling explicitly, so it stops short of 5, but the purpose is immediately understandable.

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

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

The description implies when the call is appropriate by flagging the paid x402 model and that it errors when no real source is wired, which is useful context. However, it never states when to prefer this over a cached or scanning alternative among the siblings, leaving routing to inference.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely new information the annotations cannot convey: this is a paid x402 call costing 0.001 USD, which is important for an agent's cost budgeting. However it says nothing about what an "ensemble decision" contains, its freshness window, or what happens on payment failure beyond what the schema hints.

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

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

Two short fragments, cost and payment rail front-loaded before the functional description, with zero filler. It is arguably overly terse rather than padded, but the structure is sound and skimmable.

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

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

For a paid, open-world tool with no output schema, the description omits what the agent actually receives: what fields an ensemble decision has, over what instruments or horizon, and how stale "latest" is. Without an output schema, the description carried the full burden of explaining return values and did not.

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

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

Schema coverage is 100% and the single parameter's description already explains the omit-to-receive-payment-requirements flow. The description adds no parameter detail beyond that, which is acceptable at full coverage but earns no extra credit.

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

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

"Latest ensemble decision output" names a resource and an implicit retrieval action, so an agent can tell it returns data rather than mutating anything. But "ensemble decision" is undefined jargon and nothing distinguishes this from siblings like mnemos_options_scan or mnemos_astra_scorecard, which could plausibly also return computed outputs.

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

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

There is no statement of when to prefer this over the other seven mnemos tools, and no exclusion criteria. The only implicit guidance is the word "Latest," which hints at a freshness tradeoff but never contrasts it with anything (e.g., historical decisions).

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

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

Annotations already declare readOnly, idempotent, open-world and non-destructive, so safety is covered. The description adds the useful non-obvious fact that the call is paid at 0.001 USD, but says nothing about which chains are supported, how stale the recommendation may be, or what happens on payment failure.

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

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

Two compact fragments with the payment cost front-loaded and zero filler. Terseness here borders on under-specification rather than padding.

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

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

No output schema, one undocumented parameter, and an x402 payment flow that is only hinted at. For a paid tool the description should at minimum note that omitting payment_signature returns payment requirements rather than a result.

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

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

Schema coverage is 50% and it is the payment_signature half that is documented. The chain parameter has no description anywhere, so an agent cannot tell which chain identifiers are accepted or whether chain is optional in practice (required list is empty).

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

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

States a clear resource and action: a gas recommendation for a given chain. The paid/x402 framing distinguishes it from the free utility siblings like mnemos_status or mnemos_bars, though it never explicitly contrasts with them.

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

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

No guidance on when to call this versus alternatives, no prerequisites, and no mention that a payment signature may be needed first. The only contextual cue is the price tag.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, and the description adds genuinely non-redundant context: it is a paid x402 call at 0.003 USD and is restricted to manual-desk use, both of which materially affect invocation. What is missing is staleness/TTL of the cache and any rate-limit detail, which matters for data that is by definition cached.

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

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

Three short clauses with the cost front-loaded and no filler. It is efficient, though the terse fragments ("Manual-desk only; not advice") trade a little clarity for brevity.

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

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

With no output schema, the description must convey the shape of the return value, and it does not — an agent paying 0.003 USD cannot tell whether it gets anomaly scores, option chains, or a radar summary. Combined with vague purpose language and unspecified cache freshness, this is a significant gap for a paid, output-less tool.

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

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

There is a single parameter and the schema description covers it at 100%, including the key omit-to-receive-payment-requirements behavior, so the schema carries the load. The description adds no additional parameter meaning, which lands at the baseline.

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

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

"Cached options radar and anomaly intelligence" identifies the resource domain (options data) and marks it as cached, implicitly differentiating it from the sibling mnemos_options_scan. However, "radar" and "anomaly intelligence" are vague jargon with no concrete verb or statement of what is actually returned, so an agent cannot fully tell what the tool produces.

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

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

"Manual-desk only; not advice" gives a caveat/audience restriction but no guidance on when to invoke this versus mnemos_options_scan or mnemos_arb_scan. There is no stated precondition, exclusion, or alternative-routing rule beyond the implied cached-vs-live distinction.

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

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

Adds real behavioral context beyond the annotations: a per-call charge of 0.01 USD, x402 payment mechanics, and the fact that repeated calls incur a new charge and can return different data. The 'annotation basis' sentence largely restates what readOnlyHint=false and idempotentHint=false already declare, but the cost and charge-per-call detail is genuinely new.

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

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

Payment and purpose are front-loaded, which is good, but the third sentence is meta-commentary justifying annotation values that the agent already sees in the structured fields. That sentence spends words on restating structured data rather than on new guidance.

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

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

For a zero-required-param, single-argument tool with full annotation coverage and no output schema, the description covers cost, payment flow, and freshness adequately. The main gap is that it doesn't sketch the payment handshake end to end (call without signature, then retry with one), which the schema only hints at.

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

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

Only one parameter and the schema documents it at 100% coverage, including the 'omit to receive payment requirements' behavior. The description reinforces the paid flow but adds no syntax or format detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource ('options-radar scan') plus the freshness qualifier 'on-demand fresh', which implicitly contrasts with the cached sibling. It stops short of naming mnemos_options_cached explicitly, so an agent must infer the distinction from the word 'fresh'.

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

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

'On-demand fresh' plus the paid/cost framing implies when to reach for this over a cached read, but the description never states the condition or names the alternative. An agent has to infer that mnemos_options_cached is the cheaper choice when freshness is not required.

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

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

The second sentence restates the annotations nearly verbatim (readOnlyHint, idempotentHint, destructiveHint, openWorldHint), which earns no credit since it duplicates structured data. What does add value is 'Free' (a cost signal) and 'reflects live external market state', which explains why values may change between calls despite idempotency.

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

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

The useful payload (status fields, cost) is front-loaded, but roughly half the text is a redundant annotation echo that an agent already has in structured form. Trimming that would leave a tighter, stronger definition.

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

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 must sketch the return content, and it does so by naming the four categories of status returned. An agent knows what to expect and what it costs; only the exact shape of the response remains unstated.

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

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

The tool takes zero parameters, so the baseline of 4 applies. The description correctly implies no inputs are needed by presenting the call as a plain status read.

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

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

States a concrete resource (live engine status) and enumerates its contents: mode, watchlist, scan freshness, scorecard summary. That is specific enough to distinguish it from the data-returning siblings (mnemos_arb_scan, mnemos_bars, mnemos_options_scan), though it never explicitly says how it relates to them.

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

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

The only usage signal is the leading 'Free.' There is no statement of when to call this instead of a sibling, no precondition (e.g. call before a scan to confirm freshness), and no exclusion.

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