zdte.ai SPX Market Structure

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

Annotations only indicate non-read-only and non-idempotent. The description adds the key behavioral fact that no charge or funding occurs until Stripe confirms payment, and it points to the balance check as the verification step. This materially improves the agent's understanding of side effects.

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 sentences, front-loaded with purpose. The third sentence is slightly awkward ('Return and check get_credit_balance') but still compact and relevant.

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 side-effecting checkout tool with no output schema, the description could more explicitly state what is returned (e.g., the checkout URL) and clarify the payment flow. The schema and annotations cover credits and safety, but the return contract is left implicit.

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 is fully described with min/max and the price formula including get_access_options. The description adds nothing to parameter meaning, so it meets the baseline but does not exceed it.

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: 'Create a Stripe Checkout link for the authenticated key.' This clearly identifies the operation and distinguishes it from siblings such as get_credit_balance and create_guest_key.

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 frames usage: create a checkout link for the authenticated key, expect no charge until payment is authorized and confirmed, and follow up with get_credit_balance. It does not name alternatives or explicit when-not conditions, but the context is clear.

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?

Beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false), the description discloses the one-time-return semantics of the key, that it must be saved securely, and that the MCP session may already be authenticated via the connection_authenticated response field. That is meaningful operational context an agent cannot get from the schema.

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?

It is front-loaded with the core action and keeps the branching logic compact, with every clause carrying actionable meaning. The final OAuth sentence is slightly long but earns its place by preventing unnecessary calls.

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 no parameters, the description must carry the full interaction flow, and it does: creation, one-time capture, session-auth detection, reconnect instructions, and the OAuth bypass path. Nothing needed to call this tool correctly is missing.

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 description explicitly confirms 'No arguments,' which removes ambiguity about invocation. There is no parameter-level detail to add, so the baseline for a zero-param tool 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?

The description opens with a specific verb and resource: 'Create a zero-credit API key, returned once, and save it securely.' It also names the follow-on sibling (create_credit_checkout), so an agent can place this tool in the workflow without consulting other schemas.

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?

It gives explicit branching guidance: use create_credit_checkout when connection_authenticated is returned, otherwise configure Bearer auth and reconnect. It also states a clear exclusion — OAuth-capable clients should skip this tool because Connect is prompted automatically.

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 read-only, idempotent, and non-destructive behavior. The description adds a useful access-related detail beyond those annotations: no website account is required. It does not describe return shape, but the annotations lower that burden.

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 description is short and front-loads the core message in the first sentence. The second sentence adds useful 'Start here' guidance but partly repeats the earlier 'accountless' idea with 'no website account required,' so it is not completely free of redundancy.

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-parameter, read-only informational tool, the description adequately covers what the tool is about and the access precondition. It does not specify the exact return format, and there is no output schema to compensate, but the tool's simplicity makes this a minor gap.

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 has zero parameters and full schema coverage, so the description does not need to document inputs. The no-parameter baseline applies, and the description's 'no website account required' note correctly implies the tool needs no account-related arguments.

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 clearly identifies the resource as free pricing and accountless access instructions, so an agent can tell this is an informational/onboarding tool. It lacks an explicit verb such as 'returns' or 'retrieves' and does not contrast itself with sibling tools, which keeps it from a 5.

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?

'Start here' gives an explicit cue that this is the intended entry point for access/pricing/onboarding questions, and 'no website account required' sets an access condition. It does not name alternative tools or state when not to use it, so it is clear but not fully prescriptive.

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 readOnlyHint, idempotentHint, openWorldHint, and destructiveHint false, so the safety profile is covered. The description adds useful behavioral context by specifying that the API key is taken from the HTTP header and that passing a key as an argument is forbidden. No contradiction with annotations.

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 sentences with no filler. The core purpose is front-loaded, and the critical 'never pass a key' warning is included without bloating the description.

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-parameter read-only balance check, the description is complete. It explains where the API key comes from, warns against passing arguments, and the annotations cover idempotency and non-destructiveness. No output schema is present, but this requires no special return-value explanation.

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 input schema is empty, so the baseline is 4. The description reinforces that no key argument should be passed, which clarifies the intended zero-parameter usage beyond the schema itself.

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 clearly states the tool returns a balance check for the API key already present in the connection's HTTP header. It uses a specific verb ('balance check') and resource ('API key'), and makes the zero-argument nature explicit, distinguishing it from any key-management or purchase siblings.

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 gives clear context: use this to check the balance of the connection's API key without passing credentials. It does not explicitly name alternative tools or state when not to use it, but the instruction 'Never pass a key as an argument' provides practical invocation guidance.

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 readOnlyHint=true, idempotentHint=true, openWorldHint=true, destructiveHint=false, so the safety profile is covered. The description adds the scoping constraint 'one replay date per call' and a data-only disclaimer, but says nothing about pagination, payload size, or what happens with a non-trading/invalid date. Modest added value over the structured fields.

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 sentences, front-loaded with the trigger and the sibling comparison, which is the most decision-relevant content. The closing disclaimer sentence is useful for agent behavior but is boilerplate that slightly dilutes the tight core.

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, and the description compensates by enumerating the returned timeline components and day summary, so an agent knows what comes back. It omits any note on response size or handling of dates outside the valid set, which is a minor gap for a read-only replay 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?

Schema description coverage is 100% and the single parameter already carries its pattern, format, and a pointer to list_history_dates. The description only restates the format ('YYYY-MM-DD') and the one-date-per-call constraint, adding no syntax or edge-case meaning beyond the schema.

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+resource+scope: 'full market-structure history of one past trading day,' and enumerates what the replay contains (walls, gamma flip, net GEX, regime, spot, day summary). It explicitly distinguishes itself from get_regime_segments as the compact alternative, so an agent can route without opening schemas.

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?

Gives an explicit trigger ('when you need the full market-structure history of one past trading day') and names the alternative with its selecting condition ('If you only need when the regime changed that day, get_regime_segments is the compact version'). Nothing is left 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?

The description adds behavioral context beyond the annotations: it is static and versioned, takes no inputs, and should be called once per session. The annotations already cover read-only and idempotent behavior, so the description's snapshot semantics and call cadence are valuable additions without redundancy.

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 sentences with the core purpose front-loaded and the usage directive stated crisply. There is no wasted wording, and no information is repeated from the annotations.

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-input reference tool, the description is complete: it defines what the response covers, the call cadence, and the no-input contract. Since there is no output schema, describing the response contents in prose was necessary and sufficient.

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 has zero parameters and an empty input schema. The description explicitly states 'No inputs,' which removes any ambiguity and earns the baseline credit for a zero-parameter tool.

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 states this is a static, versioned dictionary of every field the surface emits, including units, value sets, meanings, and shared response conventions. This clearly identifies the resource and purpose, and distinguishes it from data-query siblings like get_day or get_regime by being a metadata reference tool.

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 gives clear usage context: it is a no-input reference to call once per session, so an agent knows when to invoke it and that the result can be reused. It does not explicitly name alternatives or state when not to use it, but the distinction from the data-query siblings is clearly implied.

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, and the description adds substantial context beyond them: ~10s recompute cadence during market hours, the funded-API-key requirement with the exact onboarding sequence (create_guest_key → create_credit_checkout → get_credit_balance), the degraded delayed-preview behavior without a key, and a data-only disclaimer. The only gap is return payload shape, which is partly covered by the feature enumeration.

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?

Usage and the alternative are front-loaded, which is good, but the middle is a dense feature dump spanning forecast bands, straddle moves, max pain, session OHLC, order flow, GEX profiles and vanna/charm ladders. Much of that inventory is genuinely informative for a no-schema return, yet the single-paragraph stacking without structure makes it harder to scan than it needs to be.

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 carries the return burden and does so thoroughly: it names the full field inventory, the realtime-vs-delayed modes, the auth path, and the disclaimer. An agent has everything needed to decide whether to call it and what to expect.

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 per the rubric the baseline is 4; there is no parameter semantics to clarify and none is needed.

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+resource (fetch current SPX dealer market structure) and enumerates the concrete artifacts returned: walls, gamma flip, net GEX, regime. It explicitly distinguishes itself from the sibling get_regime, so an agent can route without opening schemas.

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?

Opens with the when-to-use condition ('when you need the full current SPX dealer market structure') and names the alternative with a cost tradeoff: 'If you only need the regime label and its confidence, get_regime is smaller and cheaper.' Both the selection condition and the fallback are explicit.

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 read-only, idempotent, open-world and non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond that: it is realtime when an API key is supplied and serves a delayed preview without one, which affects freshness expectations. It does not cover rate limits or response payload shape.

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 sentences, each earning its place: the use case first, the routing alternative second, the auth-related freshness caveat last. No filler or restated name/title.

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, and the description compensates by naming what is returned (regime label plus confidence). Usage routing and the API-key freshness caveat round it out, though it stops short of describing the label vocabulary or confidence scale.

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 there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. The schema's additionalProperties=false is consistent with the description implying a no-argument call.

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 names a specific resource (SPX dealer regime label) plus its confidence value, and explicitly distinguishes itself from get_market_structure, which covers walls, gamma flip, net GEX and strike detail. An agent can tell it apart from siblings like get_regime_segments without opening any schema.

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?

It states the exact condition for use ('when you only need the current SPX dealer regime label and its confidence, for example to check whether conditions have changed') and names the alternative tool to use for richer structure output. Both the when and the when-not are explicit.

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, so the safety profile is covered. The description adds behavioral value beyond that by characterizing the payload as a compressed segment tape with start/end times and by constraining input to a single replay date per call, which matters because no output schema exists to convey return shape.

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 sentences, no filler; the scoping condition is front-loaded and the costly alternative (get_day) is deferred to second position. Every clause earns its place.

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 carries the return-value burden and does describe the output as compressed regime segments with start/end times, which is enough to set expectations. It stops short of saying whether segments are non-overlapping, ordered, or how many typically return, but nothing critical for correct invocation is missing.

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 100% and the single parameter already carries format guidance plus a pointer to list_history_dates. The description's 'One replay date (YYYY-MM-DD) per call' largely restates the schema pattern, 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?

The description names a specific resource (dealer regime segments) and the shape of the result (compressed list of segments with start and end times), and explicitly separates it from the sibling get_day. An agent can distinguish it from get_regime, get_day, and get_market_structure without opening any schema.

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?

It states the selecting condition ('when you only need how the dealer regime changed during one past trading day') and names the alternative with its own trigger ('For the full intraday structure ... use get_day instead'). This is explicit when/when-not/alternative routing.

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 readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds meaningful context beyond annotations: the catalog is free, requires no API key, and only the actual replay datasets are paid. No contradiction with annotations.

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 terse sentences deliver the core function first and then add the access/cost caveat. No redundant words or filler.

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-parameter, read-only catalog operation, the description provides all necessary context: what is listed (dates), the domain (SPX market structure), and the free-vs-paid boundary. An output schema is absent, but the simple list nature makes the response type reasonably predictable.

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 are zero input parameters, so the schema fully covers invocation. The description's mention of 'no API key required' is access context rather than parameter semantics. Baseline 4 applies because there are no parameters to document.

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 purpose: providing a free catalog of available historical SPX market-structure replay dates. It clearly distinguishes the date catalog from the actual replay datasets and the resource/scope is unambiguous. The verb is implied by 'catalog' but the operation is clear.

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 explains when this tool is appropriate: discovering available dates without an API key, while the underlying datasets are paid. It does not explicitly name a sibling alternative, but no other sibling appears to perform the same date-list function.

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 readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds useful scoping context ('this agent's active') that is not present in the annotations, clarifying that it returns a filtered subset rather than all possible subscription records.

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 description is a single, front-loaded sentence with no filler or redundant restatement. It conveys the action, the resource, and the scope in nine words.

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 parameterless, read-only list operation, the description plus annotations fully equip an agent to select and invoke the tool. No return schema is provided, but the word 'List' sufficiently implies the output is the set of active subscriptions.

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?

With zero parameters and 100% schema description coverage, there is nothing for the description to add about arguments. The baseline of 4 for parameterless tools 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?

The description uses the specific verb 'List' with an explicit resource ('this agent's active event subscriptions'), making the tool's purpose unambiguous. It is clearly distinct from sibling tools like subscribe_event and unsubscribe, which perform mutations, and from data-retrieval tools like get_regime.

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 phrase 'this agent's active event subscriptions' clearly communicates the query scope and implies this is the tool to call when an agent needs to see its existing subscriptions. It does not explicitly name alternatives or exclusions, but no direct alternative for simply listing subscriptions exists among the siblings.

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 indicate this is not read-only and not idempotent, so the mutation aspect is covered. The description adds that a callback URL receives POST notifications, but it does not disclose whether subscribing twice creates duplicates, overwrites, or errors, nor does it mention that subscriptions persist until explicitly removed.

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 description is a single, focused sentence that states the action, the target, and the allowed values with no filler. The event enum is compactly listed and front-loaded.

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 simple two-parameter tool with fully documented schema and adequate annotations, the description is mostly complete. The only meaningful gap is the lack of explicit side-effect or management context (e.g., 'manages subscription lifecycle via list_subscriptions/unsubscribe'), but this is not necessary to make a correct call.

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 100%: both event and callback_url have meaningful descriptions, and event has an enum. The description repeats the enum values but adds no new semantic detail beyond the schema, so the baseline of 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?

The description uses a specific verb ('Subscribe') with a clear resource ('callback URL') and enumerates the exact event types (zero_gamma_flip | new_wall | regime_transition). It clearly distinguishes the tool from siblings like unsubscribe and list_subscriptions by using the opposite action for the same domain.

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 to use the tool: when the agent needs to register a callback for a market-structure event. However, it does not explicitly mention alternatives or exclusions, such as 'use list_subscriptions to view existing subscriptions' or 'use unsubscribe to remove one.'

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 carry the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorldHint=true), so the description's main added value is the provenance chain back to subscribe_event. It does not describe behavior on an unknown/already-removed id or confirm whether the operation is reversible, both of which would be useful for 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.

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

A single tight sentence with the action front-loaded and the id sourced immediately; no filler and no redundancy.

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 one-parameter mutation with full schema coverage and annotations covering safety and idempotency, the description is essentially complete; it correctly identifies where the id comes from. Only edge-case behavior (invalid or duplicate id) is unaddressed, which is minor.

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 100% and the single parameter is fully documented in the schema with the same provenance wording. The description adds no syntax, format, or validation semantics beyond what the schema already provides, so the baseline of 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 ('Remove an event subscription by id') and uniquely pairs it with subscribe_event, so it is distinguishable from subscribe_event and list_subscriptions. It stops short of explicitly naming sibling alternatives, which keeps it from a 5.

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 provenance note ('the subscription_id that subscribe_event returned') implies the correct workflow context — you unsubscribe something you previously subscribed to. However, there is no explicit statement of when to use this vs. list_subscriptions or what happens when the id is unknown, so guidance is only implied.

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