PredictAsiaX MCP Server

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. The parenthetical ('no email required — provide Telegram/Signal/Discord/Matrix/X DM handle') clarifies the contact mechanism, which is genuinely useful, but says nothing about the approval flow, idempotency, rate limits, or whether an authenticated identity is required.

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 front-loaded sentence with no filler; the core action leads and the clarifying parenthetical follows. Efficient, though the brevity is partly the source of the missing detail.

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 7-parameter creation tool with zero schema coverage, no annotations, and no output schema, the description is far too thin. It omits the meaning of the track enum values, the purpose of use_case/jurisdiction/scopes, and what the caller gets back after submitting.

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 0% across 7 parameters. The description covers only contact_channel/contact_handle and gestures at 'track,' leaving org_name, use_case (which has a 20–2000 char constraint), jurisdiction, and intended_scopes entirely undocumented. It does not compensate for the coverage gap.

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: 'Submit an access-request for a builder track.' This is clearly distinguishable from the sibling pax.access_request_status (which reads status rather than creates a request). It stops short of naming that sibling, but the action is unambiguous.

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 explicit when-to-use, when-not-to-use, or alternative routing. The agent can infer that this is the creation path for builder-track access, but nothing tells it when this is appropriate versus checking status or another onboarding tool.

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?

No annotations are provided, so the description carries the full burden. It implies a read-only check and scopes to pending requests, but omits authentication requirements, error behavior for invalid or non-pending IDs, and response details.

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 sentence with zero waste, front-loading the verb and resource. Efficient for a simple lookup tool.

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 status tool with no annotations and no output schema, the description covers what it does and the required parameter but omits return information and error handling. It is minimally adequate but not complete.

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 0% and the sole parameter request_id has no schema description. The description adds meaning by naming request_id and tying it to the access request, but does not specify format (e.g., UUID) or source.

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 ('Check status') and resource ('access request'), scoped to pending requests and identified by request_id. It implicitly distinguishes from sibling pax.access_request_create by operation, though it does not explicitly name that alternative.

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?

Provides implied usage: check status of a pending request by ID. No explicit when/when-not guidance or alternatives (e.g., how to create or cancel a request) are given.

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?

With no annotations, the description carries the full burden, and it only implies a read operation. It does not say whether the caller must own the subaccount, whether the call is scoped to a parent account, how 'reserved' is defined, or what happens when subaccount_id is omitted.

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 short and front-loaded, but it is a sentence fragment that omits essential scoping information rather than a tight sentence that earns its brevity. The size is appropriate; the content is under-specified for the space available.

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 and no annotations exist, so the description is the only source of behavioral information, and it leaves the two-parameter scope, the meaning of 'reserved', and the response shape unexplained. For a balance tool with an ambiguous optional parameter this is a clear 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?

Schema description coverage is 0% for both parameters, so the description must compensate and does not. It mentions 'subaccount' but never explains the relationship between the required user_id and the optional subaccount_id, nor what the default scope is when subaccount_id is absent.

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 (balance) and decomposes it into 'USDT free + reserved' for a subaccount, which is more precise than a generic 'get balance'. It does not, however, distinguish itself from plausible siblings such as pax.portfolio_read or pax.tier_status, so an agent cannot route between them from the text alone.

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 call this versus pax.portfolio_read, pax.tier_status, or pax.subaccount_list, and no prerequisites or exclusions are given. Usage must be inferred entirely from the tool name.

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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that only metadata is returned and secrets are never included, which is real value about the response content, but it says nothing about required auth/permissions, pagination, or ordering for a sensitive credential-adjacent endpoint.

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?

One sentence, front-loaded with the action and resource, with the important caveat about secrets placed immediately after where it can't be missed. No 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?

With no annotations, no output schema, and an undocumented parameter, the description is only partly sufficient. The secrets caveat is the most valuable piece of context and is present, but auth requirements and what fields the metadata actually contains are absent.

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 0% for the single app_id parameter, so the schema adds nothing. The phrase "for a specific app" maps the parameter to its meaning, but no format, source of the ID, or examples are given, leaving the description to do more than it does.

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 (List) and resource (API keys) scoped to "a specific app", and the parenthetical clarifies exactly what kind of data comes back. It does not name or distinguish itself from the nearest sibling, builder_apps_list, so the reader must infer the boundary from names alone.

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 call this versus builder_apps_list or any related builder tool, and no prerequisites or preconditions are mentioned. The reader gets a clear purpose but no routing 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?

No annotations are provided, so the description carries the full behavioral burden. 'List' implies a safe read, but nothing is said about pagination, result limits, ordering, or whether the builder profile is resolved from the caller's credentials. For a no-annotation tool this is thin.

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 front-loaded sentence with no filler; every word contributes to identifying the resource and its scope.

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 tool with no output schema or annotations, the description is minimally adequate: it identifies the collection but omits return shape, pagination, and how the 'current builder profile' is determined. An agent can call it, but not predict the response.

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 nothing for the description to clarify about inputs, though the implicit 'current builder profile' scoping is a mild plus.

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 ('List') and resource ('apps registered under the current builder profile'), with clear scope via 'current builder profile'. It does not explicitly distinguish itself from the nearby sibling pax.builder_apikeys_list or pax.builder_me, but the resource noun makes the distinction inferable.

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 says what the tool does but gives no when-to-use guidance, no mention of alternatives (e.g., builder_apikeys_list vs builder_me), and no prerequisites such as authentication context. Usage must be entirely inferred.

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?

With no annotations, the description carries the full behavioral burden. It does establish this as a read ('Return') and enumerates the returned fields, which is valuable given there is no output schema, but it says nothing about authentication/builder-scope requirements, rate limits, or what an empty/unverified profile returns.

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 front-loaded sentence with zero filler; the verb and resource lead, and the field list is delivered in a compact form. Nothing in it is redundant with structured data beyond the field names, which the absent output schema makes necessary.

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 with no output schema, listing the returned fields (tier, apps count, 30d volume + fee revenue, verified status) makes the description largely self-sufficient. The remaining gap is the absence of any note on auth scope or the relationship to the tier_status and builder_apps_list siblings.

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 to disambiguate and the baseline is 4. The description correctly signals the no-argument nature via 'current' but adds no further parameter meaning because 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?

Specific verb and resource ('Return the current builder profile') with an enumeration of the payload fields (tier, apps count, 30d volume + fee revenue, verified status). This is clear on its own, but it never distinguishes itself from overlapping siblings such as pax.tier_status, which appears to surface tier information as well.

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 word 'current' implies this reads the authenticated caller's own profile with no arguments, so the usage is at least implied. However, there is no explicit when-to-use statement and no mention of the tier_status or builder_apps_list alternatives that could serve overlapping needs.

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?

With no annotations, the description carries full behavioral burden. 'Atomic' is a genuine behavioral trait that adds real value (all-or-nothing execution). It does not disclose that the operation is destructive and irreversible, what permissions are required, or what happens if some orders are already filled or cancelled.

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 sentence with zero filler. Scope is front-loaded ('Bulk cancel all open orders') followed by the qualifiers and the atomicity guarantee.

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?

A destructive, annotation-free mutation with no output schema deserves more: no statement of irreversibility, no subaccount_id semantics, and no indication of what the caller gets back (e.g. count of cancelled orders). 'Atomic' covers one important concern but not the whole picture.

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 only 33%: market_id is documented in the schema itself ('Omit to cancel across all markets'), and the description restates the user/optional-market scoping. subaccount_id is undocumented in both the schema and the description, leaving a real gap for a 3-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?

States a specific verb and resource with scope: 'Bulk cancel all open orders for a user + (optional) market.' The word 'Bulk' implicitly distinguishes it from the singular sibling pax.cancel_order, but it never names that sibling or draws the contrast explicitly.

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?

Usage is implied by 'Bulk cancel all open orders' — you use it when you want to clear everything rather than one order. However, there is no explicit when-to-use, when-not-to-use, or reference to pax.cancel_order as the alternative for single-order cancellation.

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?

No annotations are provided, so the description carries the full burden. It conveys that this is a mutating cancellation, but says nothing about reversibility, idempotency, what happens if the order is already filled, or permission/auth requirements for a destructive operation.

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 short sentence with the action front-loaded and no filler. It is efficient, though its brevity edges toward under-specification rather than deliberate minimalism.

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 destructive, single-param operation with no annotations and no output schema, the definition is thin: no auth expectations, no behavior on invalid/already-filled orders, and no indication of what a successful cancellation returns. It leaves the agent with unresolved questions before invoking.

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 0% and there is one parameter, so the description must compensate for the undocumented order_id. It adds no format, ID-vs-symbol, or scoping detail beyond the bare param name, which is a meaningful gap for a mutation keyed on an identifier.

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 gives a specific verb (cancel) and resource (order), and the singular 'an ... order' implicitly separates it from the sibling pax.cancel_all_orders. It is clear what the tool does, though it stops short of explicitly naming the sibling it is not.

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 'open or partially-filled' implies the precondition for calling it, so usage is inferable rather than stated. There is no explicit when-not guidance and no pointer to pax.cancel_all_orders or other alternatives, leaving the agent to infer 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?

No annotations are provided, so the description carries the full burden. It does disclose the returned fields (counts and 24h volume) and that the listing is exhaustive ('all'), which implies no filtering or pagination, but it says nothing about freshness, caching, or rate limits.

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 front-loaded sentence with no filler. The scope ('all') and the returned content are both stated without 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?

With no output schema, the description usefully names the returned fields, which is what an agent most needs for this simple no-arg listing. Minor gaps remain around ordering and freshness, but nothing essential 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, so the baseline is 4 and there are no parameter semantics the description could or should elaborate on.

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 (List) and resource (market categories), plus the payload shape (counts and 24h volume). It is clear what the tool does, though it does not explicitly distinguish itself from siblings like markets_top_volume or market_search.

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 mention of prerequisites, and no routing to alternatives such as markets_top_volume or market_search. The browsing intent is only weakly implied by 'List all'.

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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose a genuinely useful state transition—the proposal 'Enters admin review queue'—telling the agent the submission is not immediately live. However, it says nothing about required permissions, whether the submission is editable or withdrawable while pending, or what happens on validation 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 short sentences, front-loaded with the action and followed by the resulting state. No filler, no restatement of the tool name.

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 mutation tool with 6 required parameters, no annotations, and no output schema, the description is too thin. It should at minimum explain the template dependency, the units/expectations for cutoff_ms and deadline_ms, and what the caller receives back after entering the review queue.

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 0% across 7 parameters, and the description names none of them. The schema itself constrains rules (minLength 20), title (5-200 chars), and sources (https URLs), but cutoff_ms and deadline_ms semantics—clearly epoch-millisecond timestamps—are left entirely unexplained, and the optional question parameter is undocumented.

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: 'Submit a new market proposal from a template.' An agent can distinguish this from read-only siblings like composer_template_get and composer_templates_list, which fetch rather than submit. It stops short of naming a sibling alternative, but the action itself is unambiguous.

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 the related sibling composer_template_get, which an agent would plausibly need first to obtain a template_id. 'From a template' implies a dependency but never states the workflow.

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?

No annotations are provided, so the description carries the full disclosure burden. It does add real value by naming the payload ('resolution rules + example config'), which is the only hint at the return shape since there is no output schema. However, it says nothing about auth requirements, behavior for an invalid template_id, or errors.

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?

One sentence, front-loaded with the verb and resource, with zero filler. It is arguably too terse for the missing parameter and usage detail, but as pure conciseness it is strong.

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 single-record read the description is minimally viable: it names the resource and the returned payload, which partly offsets the absent output schema. It remains incomplete on the required template_id and on when to prefer the list sibling.

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 0% for the single parameter, template_id, so the description must compensate and it does not — the parameter is never mentioned. An agent gets no format, source, or validity guidance for the id beyond its name.

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: 'Read a single market template'. The word 'single' implicitly distinguishes it from the sibling pax.composer_templates_list, but it never names that sibling or explicitly contrasts with it, so the differentiation is left to inference.

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 use this tool versus pax.composer_templates_list or pax.composer_proposal_submit, and no prerequisites (e.g. that a valid template_id is required). Usage is only weakly implied by 'single'.

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?

No annotations are provided, so the description carries the full behavioral burden. It does not state that this is a read-only enumeration, whether results are paginated, whether auth is required, or what the result set looks like — only that templates exist. The 'List' verb weakly implies read-only, but nothing more is disclosed.

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 front-loaded sentence with no filler; the resource and its purpose are stated immediately. It is appropriately sized, though the brevity is partly under-specification rather than disciplined concision.

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 low-complexity list tool with one optional parameter and no output schema, the description covers what the tool returns categorically but omits the parameter's meaning, pagination behavior, and any usage constraints. Minimum viable, with clear gaps.

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 0% and the sole parameter 'kind' is never mentioned in the description. The listed examples (crypto/sports/election) gesturally overlap with possible 'kind' values but are not presented as filter values, so the description does not compensate for the coverage gap.

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 ('List') and resource ('market templates') and clarifies what the templates are for — opening new markets — with concrete examples (crypto price binary, sports, election). The singular sibling pax.composer_template_get is not named, but the list/get distinction is inferable from the name.

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 clause 'available for opening new markets' implies the context of use (browsing templates before creating a market), but there is no explicit when-to-use statement, no prerequisites, and no routing to or away from the sibling composer_template_get.

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?

With no annotations, the description carries the full burden, and it does disclose the fee model itself: 8-25 bps scaling with price extremity plus an optional 0-100 bps additive partner fee. It does not state that this is a side-effect-free calculation, whether a user_id is required for tier-dependent rates, or whether the result depends on account tier.

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 front-loaded sentence that states the action and then the pricing mechanics; nothing is wasted. It could still use a second sentence for parameter/usage detail without becoming bloated.

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 should ideally indicate what the estimate returns (e.g. bps vs absolute fee for the given size/price), and it omits that. Combined with the near-total absence of parameter semantics, the definition is minimally viable for a 5-parameter pricing 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 0% across 5 parameters, so the description must compensate and largely does not. It explains only additive_fee_bps (optional partner fee, 0-100 bps), leaving price, size, market_id and user_id without any format, unit, or semantic explanation (e.g. string decimals, quote vs base units, whether user_id changes tiered rates).

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?

Specific verb+resource: 'Estimate the taker fee for a hypothetical order' plus the named fee mechanism (PAX Adaptive Fee Curve). It is clearly distinguishable from siblings like pax.fee_ledger_read (historical fees) and pax.mm_stipend_estimate (market-maker stipends), though it never names those siblings explicitly.

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 word 'hypothetical' implies pre-trade cost simulation as opposed to reading actual charged fees, which is a useful usage signal. However, there is no explicit when-to-use/when-not guidance, no statement of prerequisites, and no routing to the related fee tools the sibling list exposes.

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?

With no annotations, the description carries the full behavioral burden. It implies a read-only, auth-scoped operation ('current builder') and hints at two fee categories, but says nothing about pagination behavior (despite a cursor param), result shape, retention windows, or rate limits.

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 front-loaded sentence with the resource named first and the returned content types appended. Nothing is wasted; it is only slightly terse given the query parameters it must support.

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 time-ranged, cursor-paginated read with zero annotation coverage, no output schema, and 0% parameter documentation, the one-line description is not sufficient. It should at minimum describe the time-range and pagination semantics.

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 0% for three parameters, and the description adds no parameter meaning beyond the names. It never explains that from_ms/to_ms are epoch-millisecond bounds or how cursor is used for paging, so an agent gets no semantic help at all.

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 (Read) and resource (fee_ledger entries), scoped to 'the current builder', and even enumerates the content types returned (4-way split shares + additive builder fees). It is clearly distinguishable from siblings like fee_estimate or mm_stipend_history, though it never names an alternative explicitly.

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 mention of prerequisites, and no routing to alternatives such as fee_estimate (projection) vs this ledger (actuals). The scoping phrase 'attributed to the current builder' is the only hint, leaving invocation context largely 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?

With no annotations, the description carries the full burden, and it does disclose the specific probe dimensions (protocol version, D1 database reachability, upstream latency), which is genuine behavioral content. It does not state that the call is read-only/side-effect free, whether it can fail or time out, or how a degraded result is represented.

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 telegraphic sentence with zero padding; every token maps to a distinct thing the probe checks. It is a fragment rather than a sentence, but nothing is wasted and the most important element (server health) leads.

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 no annotations, so the description is the only source on what comes back — and it enumerates the return categories, which is the essential information for this tool. A note on failure/timeout behavior would make it complete, but the scope is small enough that the gap 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?

The tool takes zero parameters, which is the baseline-4 case. The description correctly implies no input is needed and spends its words on outputs instead.

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 (the MCP server) and enumerates exactly what the probe reports: protocol version, D1 reachability, and upstream latency. This clearly separates it from every sibling, all of which are trading/market/account operations. It lacks an explicit verb, but the resource list is unambiguous.

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 explicit statement of when to call this (e.g., 'use to verify connectivity before diagnosing failures'), but for a zero-argument diagnostic endpoint the intended usage is strongly implied by the name and the enumerated probes. No alternatives or exclusions are named, and none are really needed.

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?

With no annotations, the description carries the full behavioral burden. It usefully signals the tool is public (no auth implied), but omits defaults for the optional days/top_n window, pagination, and result ordering. For an unannotated tool this is a significant gap.

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 tight sentences with the core purpose front-loaded and the filter note second. No filler, though the brevity comes at the cost of detail rather than being purely efficient.

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 annotations, no output schema, and 0% parameter coverage, the description is too thin for a three-parameter tool. It never defines LQF, ranking basis, or default window size, leaving the agent to guess at call semantics.

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 0%, so the description must compensate for all three parameters. It covers market_id as a filter and gestures at days via 'rolling window', but top_n is never mentioned and no defaults, units, or bounds are conveyed. Partial compensation only.

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 and scope: a public leaderboard of top LQF stipend earners over a rolling window. This distinguishes it from siblings like mm_stipend_estimate and mm_stipend_history by framing it as a ranked public listing, though it never names those alternatives. An agent can identify the operation, but 'LQF' is unexplained jargon.

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 use this versus the nearby mm_stipend_estimate / mm_stipend_history tools, nor any prerequisites or exclusions. 'Optional market_id filter' hints at a filtering use case but gives no guidance on choosing it.

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?

With no annotations, the description carries the full behavioral burden, and it does disclose the returned field set (title, question, prices, volume, open interest, resolution rules, template), which is genuinely useful given no output schema. It says nothing about auth requirements, error behavior for a bad market_id, or data 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?

One front-loaded sentence with the action and scope first and the payload list after; no filler, no restatement of the tool name. Every token contributes information.

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?

The field enumeration stands in for the missing output schema, which is a real contribution. But with no annotations, no parameter description, and no mention of invalid-ID handling, the definition is only minimally sufficient for an agent to call this reliably.

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 0% and the description only implies that market_id identifies a single market. It never states the accepted identifier format (slug, UUID, numeric ID) or whether it must be an exact match, so the single parameter is effectively undocumented in both places.

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?

Specific verb ('Get') plus resource ('single market') with an enumerated payload, which cleanly separates it from the list-oriented siblings (pax.market_search, pax.markets_top_volume) and the slice endpoints (pax.market_orderbook, pax.market_price_history). An agent can pick this tool 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?

The phrase 'for a single market' implies the use case (fetch detail for one known market) but there is no explicit statement of when to prefer this over pax.market_search or pax.market_orderbook, and no prerequisites or exclusions. Usage is inferable rather than stated.

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?

With no annotations, the description carries the full burden. It does disclose that this is a read operation and that depth is capped at 20 levels per side, which is real behavioral context. However, it says nothing about auth/permission requirements, rate limits, or output shape, leaving meaningful gaps for a mutation-free but undocumented tool.

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 zero waste. The core purpose is front-loaded and the depth constraint follows immediately, so an agent gets the essentials in one pass.

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 read-only market data tool with no output schema, the description covers the essence but is thin: with 0% schema coverage it should document the parameters, and with no annotations it should state the read-only nature explicitly. Adequate but with clear gaps.

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 0% across all three parameters, so the description must compensate and largely doesn't. It never mentions market_id, never explains the side enum (yes/no/both), and only obliquely references depth via '20 levels each side.' The enum and identifier semantics are left entirely to 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 and resource: 'Read top-of-book bid/ask ladder for a market.' This is distinguishable from market_get (metadata) and market_price_history (historical prices) by resource. It doesn't explicitly name a sibling to disambiguate against, but the resource is concrete enough for an agent to select it.

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?

Usage is implied by the clear read purpose (inspecting current market depth), but there is no explicit when-to-use, when-not-to-use, or named alternative. An agent must infer that this is for live depth rather than historical or metadata lookups.

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?

With no annotations, the description carries the full burden, and it does disclose one meaningful trait: the series is LTTB-downsampled, so the returned points are not raw ticks. It omits auth requirements, rate limits, and the return shape (timestamps/values), leaving real gaps for a data-read tool.

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, front-loaded with the core noun phrase and the sampling caveat, with zero filler. Nothing could be cut without losing information.

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 two-parameter read tool with no output schema and no annotations, the description covers the sampling behavior but leaves the return format (what a data point contains) and any access prerequisites unexplained. Adequate but with clear gaps.

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 0%, so the description must compensate. It restates the range bounds already visible in the enum ('1h through 90d') but adds no meaning about what the range controls, and says nothing about market_id.

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 (time-series probability history for a market) with a qualifier (LTTB-sampled) that distinguishes it from siblings like pax.probability_movers or pax.portfolio_history. It does not explicitly name an alternative, but the verb+resource combination is unambiguous.

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 when-to-use guidance, no mention of when this is preferable to pax.probability_movers, pax.market_get, or pax.portfolio_history. The range bounds hint at applicability but give no selection criteria.

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?

With no annotations, the description carries the full burden, and it partially does: it discloses that results are paginated and include prices, volume, and status. It omits whether authentication is required, whether closed/settled markets are included by default, and any rate-limit or ordering behavior, so the safety and result-set profile remain unclear.

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, front-loaded with the action and resource, then the return shape. No filler, though it is quite terse for a five-parameter discovery tool.

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 annotations, the description must compensate more, and it only briefly sketches the return payload and pagination. Default status scoping, sort order, and auth expectations are unaddressed, leaving gaps an agent would need to resolve before calling it confidently.

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 60%, and the description only echoes the q and category concepts and mentions pagination generally. It adds nothing about the status enum values or cursor semantics, and its use of 'status' as a returned field can be confused with the status filter parameter.

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?

Names a specific verb (Search) and resource (PredictAsiaX markets) plus the two primary filter modes, keyword and category. An agent can distinguish it from pax.market_get (single market) and pax.category_list, but the description never names those siblings, so the differentiation is inferred 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.

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

The phrase 'by keyword or category' implies when this tool is relevant versus a direct lookup, but there is no explicit when-to-use/when-not, no note that it is the discovery entry point versus pax.markets_top_volume or pax.probability_movers, and no mention of default filtering behavior. Usage is only 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?

No annotations are provided, so the description carries the full disclosure burden. It never states that this is a read-only ranked listing, nor describes pagination, ranking basis, or what happens when category matches nothing. For a zero-annotation tool this is a significant gap.

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, front-loaded sentences with no filler; the resource is stated immediately. It is efficient though arguably under-specified rather than verbose.

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 three-parameter listing tool with no output schema and no annotations, the description is too thin. It omits ranking semantics, filtering behavior, return shape, and its relationship to sibling leaderboard tools, so an agent cannot call it confidently.

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 0%, so the description must compensate for all three parameters. It only hints at 'window' via the mismatched '24h' label and says nothing about top_n (count/limit) or category (filtering), leaving two parameters entirely undocumented.

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 phrase '24h volume leaderboard' names the resource (a ranked market list) but no explicit verb, so it reads as a bare noun. It also undersells the tool: the schema's window enum allows 1h and 7d, contradicting the hard-coded '24h' claim. It does not distinguish itself from the close sibling pax.liquidity_leaderboard.

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?

'Useful for surfacing hot markets' implies a use case but gives no explicit when-to-use versus alternatives. With siblings like liquidity_leaderboard, probability_movers, and market_search available, the description never routes the agent to the correct tool or states exclusions.

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?

With no annotations, the description carries the full burden. It usefully discloses the TTL bound (1-3600s) and the MM-status rebate condition, but says nothing about what happens on expiry, whether it replaces existing quotes, error/rejection behavior, or that it is a write operation with state 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 compact sentences, front-loaded with the action. Minor redundancy in restating the TTL constraint already present in the schema, but no 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 mutation tool with no annotations, no output schema, and 5 parameters at 0% schema coverage, the description is too thin. Response shape, quote lifecycle (replacement/expiry/cancellation), and parameter formats are all unaddressed.

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 0% across 5 parameters, so the description must compensate. It clarifies that the quote is two-sided (implying the bid/ask pairing) and restates the TTL range already enforced by the schema, but leaves price format (string decimals), size units, and market_id meaning unexplained.

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 ('Post a two-sided MM quote to a market'), which is clearly distinct from sibling place_order or rfq_create. It does not name a sibling explicitly, so it lands at 4 rather than 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 only usage signal is the eligibility prerequisite ('Requires designated MM status for rebate'). There is no when-to-use guidance relative to place_order or rfq_accept, and no indication of when this is appropriate versus just posting a regular order.

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?

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only operation and discloses that only 'active' quotes are returned (a filter), but says nothing about authentication requirements, pagination, result limits, or ordering. For a tool with zero annotation coverage this is a significant gap.

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 short sentence with no wasted words and the resource front-loaded. It is efficient, though bordering on under-specified rather than genuinely concise.

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 trivial one-parameter list tool with no output schema, the description is minimally viable: an agent can guess it returns active MM quotes for the given market. It is missing return-shape hints, pagination behavior, and auth expectations, but the tool's inherent simplicity limits the damage.

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 0% on the single market_id parameter. The phrase 'for a market' merely restates what the schema name already conveys and gives no format guidance (slug, numeric ID, address?) or constraints. The description fails to compensate for the coverage gap.

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 ('List') and resource ('active MM quotes') with a scope qualifier ('for a market'). This distinguishes it reasonably well from the sibling pax.mm_quote_post, which is the write counterpart, though the 'MM' abbreviation is left unexplained.

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 explicit when-to-use guidance, no prerequisites, and no mention of the obvious alternative pax.mm_quote_post. An agent must infer from the name alone that this is the read side of the MM quote pair.

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?

With no annotations, the description carries the full burden. It usefully discloses that the result is a projection ('forecast', 'projected payout at 00:15 UTC') based on partial data ('snapshots seen so far'), which sets expectations about it not being final. It says nothing about auth requirements, rate limits, or whether the value is guaranteed, so gaps remain for a mutation-adjacent financial tool.

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 tight sentences with the purpose front-loaded and the return/timing detail following. No filler. It could be slightly more economical, but structure and front-loading are good.

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 two-param read tool with no output schema, the description adequately covers the return value ('projected payout at 00:15 UTC') and the basis of the estimate. It does not document the parameters or any access constraints, so it is only minimum-viable for correct invocation.

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 0% for both required params, so the description must compensate. It partially does: 'for a market maker' maps to user_id and 'on one market' maps to market_id, giving semantic hints. But neither parameter's expected format or identifier type is clarified, leaving real gaps.

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 ('LQF stipend forecast for a market maker') plus scope ('one market this epoch'), which lets an agent distinguish it from the sibling mm_stipend_history (past payouts). The verb+resource is unambiguous, though it never explicitly names the sibling it replaces, so sibling differentiation is inferred 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.

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

The phrase 'real-time ... this epoch' and 'snapshots seen so far' imply usage for a live, in-progress projection versus the historical sibling, but no when-to-use/when-not or explicit alternative is offered. Usage is only inferable from the wording.

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?

With no annotations, the description carries the full burden. It discloses the read-only/past nature via 'Historical' and the default page size of 30, which are useful behavioral traits. However, it omits pagination, result ordering, and any authorization/permission context for a market-maker-specific endpoint.

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, front-loaded sentences that lead with what the tool returns and then cover the optional filter, with no wasted words. 'LQF' is unexplained jargon, a minor structure cost.

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 3-param, no-annotation, no-output-schema read tool, the description covers the core purpose and two of three params but leaves the required user_id, domain term LQF, and any pagination/ordering behavior unspecified. Adequate but with clear gaps.

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 0%, so the description must compensate; it covers market_id as an optional filter and the default limit of 30, which adds real meaning. But the required user_id parameter is never mentioned, leaving a critical input undiscussed.

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: retrieves historical LQF stipend payouts for a market maker, which is distinct from the read concept of estimate. It implicitly contrasts with the sibling mm_stipend_estimate (estimate vs. actual past payouts), but never names it, so the differentiation is left to inference.

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 explicit when-to-use guidance and no alternatives named. An agent can infer 'read past payouts' from 'Historical', but there is no condition telling it when this tool is preferred over mm_stipend_estimate or fee_ledger_read.

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?

With no annotations, the description carries the full burden. It does disclose the returned order statuses and that results are paginated, which is real behavioral content. It says nothing about ordering, page size limits, auth/permission requirements, or how the cursor behaves, so the transparency is partial.

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 resource front-loaded and the scoping details in parentheses. No filler, nothing 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?

No output schema, no annotations, and 0% parameter coverage leave the description as the only source of information, and it addresses just the result statuses and the existence of pagination. Time-range semantics, market/subaccount filtering, and ordering are all missing for a 6-parameter list 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 0% across 6 parameters, and the description only gestures at two of them indirectly ('for the user' → user_id, 'paginated' → cursor). The meaning of from_ms/to_ms, market_id, and subaccount_id is undocumented in both the schema and 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 (historical orders) with an explicit content scope: filled, cancelled, and expired. The word 'Historical' contrasts implicitly with the sibling pax.orders_open, but the description never names that sibling, so the differentiation is left to the agent's inference from tool names.

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 parenthetical status list and 'Historical' imply the situation in which to call this rather than pax.orders_open, but there is no explicit when-to-use statement, no exclusion, and no alternative named. Usage is inferable but not guided.

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?

No annotations are provided, so the description carries the full burden. It does usefully disclose the filter semantics — that 'open' specifically means status IN open or partially_filled — but says nothing about authentication requirements, pagination, result limits, or ordering. Partial disclosure for a tool with zero annotation coverage.

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 efficient sentence with the scope constraint front-loaded and no filler. It is appropriately sized, though the brevity borders on under-specification rather than true conciseness.

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 annotations, no output schema, and 0% parameter coverage, the description should do much more. It omits pagination/result-size behavior, return shape, and any explanation of the optional filtering parameters, leaving significant gaps for an agent calling a list endpoint.

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 0% with three parameters (user_id required, market_id, subaccount_id), and the description clarifies only that the results are 'for the user'. It does not explain whether market_id or subaccount_id narrow the result set or how they interact, leaving two parameters entirely undocumented.

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 ('List currently-open orders') and defines the scope via the status filter (open, partially_filled). It implicitly contrasts with the pax.orders_history sibling, but never names or distinguishes itself from it explicitly, so it stops short of 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?

Usage is implied by the phrase 'currently-open orders' — an agent can infer this is the tool for live/open orders versus pax.orders_history. However, there is no explicit when-to-use statement, no mention of the history alternative, and no conditions or exclusions.

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?

With no annotations, the description carries the full behavioral burden and does disclose two useful traits: the required Idempotency-Key transport header and server-side tier caps. However, it omits what happens on failure, whether the order rests or fills immediately, whether it is cancellable, and any auth/permission requirements.

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 tight sentences with the core purpose front-loaded and no filler. Each sentence carries distinct information: the action, the transport requirement, and the server-side enforcement.

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 6-required-param mutation tool with no annotations and no output schema, the definition covers the essentials of action, prerequisite, and limit enforcement but leaves notable gaps: the side enum's dual semantics, the role of client_order_id, and return/failure behavior are all unaddressed.

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 44% (9 params, 6 required), so the description should compensate for the gap but adds nothing about any parameter. It is silent on the ambiguous side enum (which mixes yes/no with buy/sell) and on the undocumented user_id, market_id, subaccount_id, and client_order_id.

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 ("Submit a new order"), which cleanly distinguishes it from the order-management siblings like cancel_order, cancel_all_orders, orders_open, and orders_history. There is no competing order-placement sibling, so no explicit differentiation is required, but it also doesn't clarify how it relates to mm_quote_post or rfq_create.

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 a prerequisite (Idempotency-Key header) but no when-to-use or when-not-to-use guidance. It does not explain the relationship to the other order/quote entry points (mm_quote_post, rfq_accept) or conditions under which this tool is the right choice.

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?

With no annotations, the description carries the full behavioral burden. It discloses one useful trait — daily sampling of realized plus unrealized PnL — but says nothing about permissions/auth requirements, max range, ordering, or pagination of the series.

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 key qualifiers (realized + unrealized, sampled daily) front-loaded and no padding. It is efficient, though its brevity stems partly from omission rather than deliberate conciseness.

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 4-parameter tool with no annotations and no output schema, the description leaves the agent without the information needed to call it confidently: no return shape for the curve, no valid time-range constraints, and no explanation of subaccount_id's effect.

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 0% across four parameters (from_ms, to_ms, user_id, subaccount_id). The description only weakly implies user scoping via 'for the user' and a time window via 'Historical'; it gives no units, timestamp format, subaccount behavior, or default range.

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 (Historical PnL curve) plus its composition (realized + unrealized) and scope (for the user), so an agent can distinguish it from portfolio_read or orders_history. It does not explicitly name the sibling it differs from, keeping it just short of 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?

There is no guidance on when to use this versus portfolio_read (current state), orders_history, or positions_list, and no stated preconditions or exclusions. Usage is only implied by the word 'Historical'.

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?

No annotations are provided, so the description carries the full burden. It does disclose scope (positions, mark-price-based PNL, unrealized PNL, USDT balances), implying a read-only, point-in-time snapshot, but says nothing about authentication/ownership requirements for user_id, data freshness, or whether balances cover all assets vs. only USDT.

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 front-loaded sentence with zero filler; the key content (what is read) comes first and nothing is redundant.

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 usefully enumerates the returned data (positions, PNL figures, balances), which compensates well for the missing return definition. It is less complete on usage routing and parameter scoping, but adequate for a simple two-parameter read 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 coverage is 50%: subaccount_id is documented in the schema ('Omit to read primary subaccount') while user_id is not. The description mentions neither parameter, so it fails to compensate for the coverage gap or clarify scoping behavior across subaccounts.

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 (Read) and resource (the user's portfolio) and enumerates the contents: positions, mark-price PNL, unrealized PnL, USDT balances. What it lacks is differentiation from overlapping siblings such as pax.positions_list, pax.balance_get, and pax.portfolio_history, which an agent could easily confuse with this 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?

There is no guidance on when to use this versus pax.positions_list, pax.balance_get, or pax.portfolio_history, nor any prerequisite or exclusion stated. Usage is only weakly inferable from the enumeration of returned fields.

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?

No annotations are provided, so the description carries the full burden. 'List' implies a read, and it usefully discloses the returned fields (size, entry price, current mark), but it says nothing about pagination, result limits, or whether it aggregates across subaccounts. Adequate but thin for an unannotated tool.

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 front-loaded sentence with zero filler, and the most important detail (what fields come back) is stated up front. Its brevity is a virtue here, though the same economy is what leaves parameters undocumented.

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, no annotations, and 0% schema coverage, the description must carry return format, filtering behavior, and parameter meaning. It covers only the returned field names and omits pagination, scoping behavior, and all parameter guidance.

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 0%, so the description should compensate, but it mentions none of the three parameters (user_id, market_id, subaccount_id). In particular the required user_id and the filtering semantics of market_id/subaccount_id are undocumented anywhere.

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 ('List open positions') plus scope ('across markets') and even names the returned fields. An agent can distinguish this from orders_open or portfolio_read without opening the schema, though it never names those siblings explicitly.

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 choose this over orders_open, portfolio_read, or balance_get, and no mention of prerequisites such as which user_id must be supplied. The agent is left to infer usage from the name alone.

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?

No annotations are provided, so the description carries the full behavioral burden. "Ranked by |delta|" is genuinely useful ordering information, but the description never states that this is a read-only query, whether resolved/illiquid markets are excluded, how ties are broken, whether results are truncated at top_n, or any rate/auth constraints.

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, front-loaded with the resource and immediately followed by the ranking rule — no filler or redundancy. It is efficient, though the extreme terseness leaves valuable detail on the table for a 5-parameter tool.

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 five parameters, 40% schema coverage, no annotations, and no output schema, the description is too thin. An agent must guess at the direction semantics, category values, top_n behavior, and the shape of returned mover records.

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 40% (from_ms and to_ms documented; top_n, category, and direction have no descriptions). The description mentions the window but adds no format detail, and it is silent on the direction enum (up/down/both), the top_n cap of 100, and what category filtering means. It does not compensate for the coverage gap.

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 ("Return markets") plus the defining scope ("whose YES probability moved the most in a window"), which clearly separates it from sibling reads like market_price_history or markets_top_volume. It does not, however, name any sibling or explicitly contrast its output with them, so it stops short of 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?

Usage is only implied: the phrase "in a window" tells the agent it needs a time range, and "moved the most" implies a comparative-ranking use case. There is no explicit when-to-use guidance, no exclusions, and no pointer to market_price_history for raw series or markets_top_volume for volume ranking.

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?

No annotations are provided, so the description carries the full behavioral burden. 'Return' implies a safe read, but it says nothing about permissions, rate limits, what happens for a market that is not yet resolved, or whether the evidence is paginated or truncated — real gaps for a tool with zero annotation coverage.

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, front-loaded with the verb and the payload, with no filler. It is efficient but arguably under-specified rather than concise by design.

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 annotations and no output schema, the description must carry the safety profile and return-shape context, and it does neither. An agent cannot tell what 'evidence + sources' concretely contains or how the call behaves for an unresolved market.

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 0%, so the schema adds nothing about the single parameter. The description only implicitly ties market_id to the market being examined; the parameter name is self-explanatory, but no format, source, or identification convention is given. It neither fully compensates nor leaves the agent lost.

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 ('Return') and resource ('evidence + sources used to resolve a market'), which is far more informative than a tautology. It does not, however, distinguish itself from adjacent read tools like pax.market_get or pax.market_search, so an agent must infer the boundary itself.

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?

Usage is only implied: the phrasing 'used to resolve a market' signals this is a post-resolution lookup rather than a general market read. There is no explicit when-to-use, no when-not-to-use, and no named alternative such as pax.market_get for general market data.

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?

There are no annotations, so the description carries the full burden. It usefully discloses that the fill is atomic and priced at the quote, which tells the agent this executes a real trade rather than a draft. However, it omits permission/auth requirements, irreversibility, and what happens if the quote has expired or been filled, which matters for a mutation tool with zero annotation coverage.

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, front-loaded sentence with the action first and the key behavioral detail (atomic fill at quoted price) trailing. No wasted words, though it is short enough that the missing context isn't an issue of verbosity.

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 trade-executing mutation with no annotations, no output schema, and 0% parameter coverage, the description is too thin. An agent cannot tell the return value, failure/expiry behavior, or the relationship between the two IDs from what is provided.

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 0% and the two required parameters (rfq_id, quote_id) are entirely undocumented. The description only implies they identify the RFQ and its quote, adding no format, sourcing, or distinction between the two identifiers.

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 (Accept) and resource (a specific RFQ quote), which clearly separates it from pax.rfq_create and the general order tools. It stops short of naming which sibling to use for the surrounding workflow, but the action itself is unambiguous.

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 when-to-use or when-not-to-use guidance. The reader is left to infer that this is the counterpart to pax.rfq_create (which opens the RFQ) and distinct from pax.place_order, but nothing in the description routes them.

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 are absent, so the description carries the full behavioral burden, and it does not disclose auth/permission requirements, what happens on success, whether the RFQ can be cancelled (pax.cancel_order?), or how expiration works despite a ttl_sec field. The bare mechanism hint ('asks MMs to bid') is the only behavioral signal provided.

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 core purpose front-loaded and zero filler. It is appropriately sized for what little it conveys, though the brevity reflects under-specification as much as efficiency.

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 six-parameter mutation tool with no annotations, no output schema, and 0% schema coverage, the description is far too thin. It omits parameter meaning, pricing constraints, TTL behavior, and success/failure semantics, leaving real gaps an agent must guess 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?

Schema description coverage is 0% across 6 parameters, so the description must compensate but essentially does not. It alludes to 'size' and 'MMs' but says nothing about side, market_id, max_price/min_price, or the ttl_sec range and default, leaving most parameters unexplained.

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 (create) and resource (RFQ), and even expands the acronym and explains the mechanism ('asks MMs to bid for a specific size'). This clearly distinguishes it from the sibling pax.rfq_accept, though it never names that sibling explicitly.

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 reference to the complementary pax.rfq_accept or to alternatives like pax.place_order. The 'asks MMs to bid' phrase hints at intent but stops short of telling the agent when this tool is the right choice.

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?

No annotations are provided, so the description carries the full burden. It implies read-only documentation but never states that (no side effects, no auth requirements, no static-vs-live content distinction), leaving the safety profile entirely to inference.

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 short sentence with the key scope front-loaded; no padding or repetition. It is efficient, though the trailing 'sandbox keys, minimal flows' fragment is slightly clipped rather than structured.

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, no output schema, and no annotations, the description is the only source of information about the return value, and it only loosely characterizes the content ('end-to-end examples'). It should state what form the examples take and how complete/current they are.

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, which is the baseline-4 case. There is nothing for the description to disambiguate, and no parameter documentation 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?

The description identifies the resource (end-to-end examples for building an AI agent against PAX) but the verb/return form is vague — it is unclear whether it returns documentation, sample code, or executable snippets. It gestures at content scope ('sandbox keys, minimal flows') without stating what the tool actually does when invoked.

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 when-to-use guidance, no prerequisites, and no mention of alternatives among the 40+ sibling tools. An agent cannot tell from this text when fetching examples is appropriate versus calling a real builder/access tool.

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?

With no annotations, the description carries the full behavioral burden. It discloses that this is a mutating/freezing operation and the failure condition that guards it, but says nothing about permissions required, whether the freeze is reversible, or what happens on success.

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 waste; the operation is stated first and the constraint second. 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?

For a mutation tool with no annotations and no output schema, the description covers purpose and the rejection precondition but omits reversibility, authorization requirements, and success behavior. Adequate but with clear gaps.

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 0% and the description mentions no parameters at all. Both user_id and subaccount_id are undocumented in both the schema and the description, leaving the agent to infer the format and scope of the IDs.

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 ('Close ... a subaccount') and immediately disambiguates the ambiguous term 'close' as 'freeze'. This is clearly distinct from sibling tools like subaccount_create, subaccount_list, and subaccount_transfer.

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 a precondition ('Rejects if positions/balance/open orders remain'), which tells the agent when the call will fail, but it names no alternative actions (e.g. cancel_all_orders or subaccount_transfer) to clear those blockers first. Guidance is implied rather than 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that a subaccount is created under the primary user account, but omits critical traits such as required authorization, whether the operation is reversible, rate limits, side effects, or what happens on failure. For a mutation tool, this is a significant gap.

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 wasted words. It is efficient and directly states the operation. Given the complexity of the tool, it may be overly terse, but from a pure conciseness perspective it avoids verbosity.

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 mutation tool with four required parameters, no annotations, and no output schema, the description is minimal. It conveys the basic purpose and scope, but omits parameter semantics, prerequisites, behavioral details, and any indication of return values. It is not sufficient for an agent to call the tool correctly without additional assumptions.

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 0%, and the description does not mention any of the four required parameters (user_id, label, kind, currency). While the schema defines enums for kind and currency, there is no semantic explanation of what these values mean or how the parameters relate to the primary user account. The description provides no compensation for the missing schema documentation.

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 a specific verb and resource: 'Create a new subaccount under the primary user account.' It clearly distinguishes from siblings like subaccount_list, subaccount_close, and subaccount_transfer by naming the create action and scope. However, it does not explicitly differentiate itself from those alternatives in the text.

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 provides no guidance on when to use this tool versus alternatives, no prerequisites (such as required permissions or whether the primary account must exist), and no exclusions. It only states what the tool does, leaving the agent to infer usage context.

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?

No annotations are provided, so the description carries the full behavioral burden, and it does not disclose authentication requirements, pagination/limit behavior, whether inactive or closed subaccounts are included, or ordering. It only hints at returned fields, which is thin for a list operation with no output 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?

A single front-loaded sentence with no filler. However, 'with kind, currency, and balance' is terse and ambiguous about whether those are returned fields or optional filters, which slightly undermines the efficiency.

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 annotations, no output schema, and a 0%-documented parameter, the description should do more work. It omits pagination, result ordering, auth scope, and the treatment of closed subaccounts, leaving an agent unable to call it confidently beyond the trivial case.

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 0% for the single required user_id, so the description must compensate. 'For a user' does establish that user_id selects whose subaccounts are returned, adding real meaning beyond the bare string type, but it says nothing about format (ID vs address) or whether it accepts the caller's own ID implicitly.

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 ('List') and resource ('subaccounts') scoped to a user, which clearly separates it from siblings like subaccount_create, subaccount_close, and subaccount_transfer. It also names the data surfaced (kind, currency, balance), though it never explicitly contrasts itself with those 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?

There is no statement of when to use this versus alternatives, no prerequisites, and no exclusions. The only signal is the implied 'read the subaccounts belonging to a user' framing, which is not enough guidance for a tool with three closely related subaccount 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?

No annotations exist, so the description carries the full behavioral burden for a money-movement operation, and it says very little. It does imply two real constraints: the asset is USDT (no currency parameter) and both accounts must share a primary user, which is genuine behavioral information. Beyond that, nothing about permissions, idempotency, limits, fees, failure modes, or whether the transfer is immediate and irreversible.

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 efficient sentence with the scope constraint front-loaded and zero filler. It is appropriately sized for what it attempts, though the brevity partly reflects under-specification rather than deliberate compression.

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 fund-moving tool with no annotations, no output schema, and 0% parameter documentation, the definition is materially incomplete. An agent cannot determine amount formatting, success/failure semantics, or what constraints (limits, permissions) apply before committing real value.

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 0% for four required parameters, so the description must compensate and it barely does. The same-primary-user constraint hints at a relationship between user_id, from_subaccount_id, and to_subaccount_id, but the critical 'amount' string is unexplained (units, precision, minimums), and the fact that currency is fixed to USDT is only inferable from prose.

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 ('Transfer') plus resource ('USDT between subaccounts') and adds a scoping constraint ('under the same primary user'). It is clearly distinguishable from siblings like pax.subaccount_create, pax.subaccount_close, and pax.subaccount_list, though it never names an alternative. The currency and account-scope qualifiers make the purpose unambiguous.

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 mention of prerequisites, and no exclusions or alternatives. The agent must infer that this is the right tool for moving funds between subaccounts from the name alone. Nothing warns about when to use a different transfer path.

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?

No annotations are provided, so the description bears the full burden. It discloses what the read returns (30d volume, days remaining, abuse flags), which is useful signal, but says nothing about auth requirements or freshness, and safety profile is only inferable from 'Read'.

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 front-loaded sentence that names the resource first and then the payload. No filler or redundant restatement of the name.

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 annotations, the description usefully enumerates the return contents, which is the key missing piece an agent would otherwise have to discover. For a zero-parameter read tool, this is nearly sufficient; only auth/freshness caveats are absent.

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. Baseline of 4 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 (Read) and resource (builder tier + auto-graduation progress), and enumerates the returned components (30d volume, days remaining, abuse flags). No sibling covers tier/graduation status, so the tool is unambiguous even though it never explicitly contrasts with a sibling.

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?

Usage is implied by the name and the read verb: call it to inspect your current tier and graduation progress. There is no statement of when to prefer this over a sibling or any prerequisites, but nothing misleading either.

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?

With no annotations, the description carries the full burden, and it does disclose one genuinely important trait: the signing secret is returned 'ONCE' and is presumably unrecoverable. However, it says nothing about auth/permission requirements, whether the endpoint becomes active immediately, or how duplicate URLs are handled.

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 tight sentences, front-loaded with the action and followed by the critical return-value warning. No filler, though the brevity leaves obvious gaps that other tools would have covered.

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?

A creation/mutation tool with no annotations, no output schema, and only 25% schema description coverage needs substantial description support. The one-time secret warning is helpful, but auth requirements, event semantics, and side effects are all 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 only 25% (only url is documented), so the description is obliged to compensate and does not. It never explains app_id, events, or label, nor the meaning of the whsec_ prefix relative to inputs.

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: 'Register a new webhook endpoint.' This is clearly distinguishable from the list-style siblings pax.webhook_endpoints_list and pax.webhook_deliveries, though the description never names or contrasts them explicitly.

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 no when-to-use or when-not-to-use guidance, no prerequisites (e.g. app ownership, auth scope), and never points to the sibling endpoints for listing or inspecting deliveries. Usage is only implied by the verb.

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?

With no annotations, the description carries the full behavioral burden, and it discloses only that the operation is a read returning status/HTTP code/retry count. It is silent on retention window, result limits, pagination behavior, and auth requirements, all of which matter for a delivery-log tool.

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 resource and the salient return fields front-loaded; nothing is wasted or repeated.

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, no annotations, and 0% param coverage mean the description should explain more. It omits pagination via cursor, the meaning of from_ms, and any limits on how many deliveries are returned, so an agent cannot call it confidently.

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 0%, so the description must compensate, but it only implies webhook_id via 'for an endpoint'. The cursor and from_ms parameters are never explained, leaving the time-range and pagination semantics undocumented for the agent.

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 (Read) and resource (webhook delivery attempts) scoped to a single endpoint, and names the returned fields (status, HTTP code, retry count). It is clearly distinct from webhook_create and webhook_endpoints_list, though it doesn't explicitly say so.

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 when-to-use context, no prerequisites, and no mention of alternative tools such as webhook_endpoints_list or webhook_create. The debugging/troubleshooting use case is only implied by the field list.

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?

No annotations are provided, so the description carries the full behavioral burden. 'List' implies a read, but it says nothing about pagination, ordering, whether inactive/deleted endpoints are included, or auth requirements for the owning app.

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 front-loaded sentence with zero waste. It is efficient, though its brevity comes at the cost of the behavioral and parameter detail noted elsewhere.

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 read tool with no output schema this is close to minimum viable, but with no annotations and 0% schema coverage the description should at least clarify what a returned endpoint contains and whether results are paginated.

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 0%, so the single required app_id parameter is undocumented in both the schema and the description. 'Under an app' only loosely hints that app_id is the owning application identifier; no format, source, or validity rules are given.

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 (List) and resource (webhook endpoints) and scopes it to an app, which is enough to distinguish it from sibling pax.webhook_create. It is less clearly differentiated from pax.webhook_deliveries, since it never says whether it returns endpoint configuration versus delivery records.

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 pax.webhook_deliveries or pax.webhook_create, and no prerequisites or context (e.g. after registering an endpoint, before debugging deliveries). The agent must infer usage from the name alone.

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