Momus Agent Marketplace

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

With no annotations, the description carries the full burden and discloses real behavioral traits: a hosted payment URL is returned, payment is operator-gated, preparation may be async (retry_after_ms), the request is idempotent by key, and payment buys only this result with no future credit. It omits error/failure behavior, but the async retry and payment semantics are unusually well surfaced.

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?

Four tightly packed sentences with the core action front-loaded ('Prepare one exact task immediately, then return a hosted payment URL') followed by payment, retry, and idempotency constraints. Dense but every sentence carries a distinct, useful fact; 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 payment/checkout tool with no annotations, no output schema, and 0% schema coverage, the description covers the lifecycle (prepare, retry, pay, no credit) well but leaves the offer selection, terms acceptance, and input payload unexplained. The async retry_after_ms is referenced without any field context, creating a real 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% across 5 required parameters, so the description must compensate. It only implies idempotency-key semantics ('never alter its input or key') and says nothing about offer_id, accept_terms, terms_version, or the shape of the nested input object, leaving most parameters 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?

The description gives a specific verb+outcome ('Prepare one exact task... then return a hosted payment URL'), which tells an agent this initiates a checkout rather than executing a job. It is distinguishable from run_offer/get_job/list_offers by being a payment/preparation step, though it never names the 'offer' resource the schema centers on.

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

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

It gives concrete operational guidance: operator authorization is required to pay, and the same request must be repeated after retry_after_ms while preparation is running, with input/key left unaltered. It stops short of naming when to use this versus run_offer, so there is no explicit alternative routing.

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

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

No annotations are provided, so the description carries the full behavioral burden. "Read" implies a non-mutating lookup, but the description never says what happens when the job is not owned or does not exist, whether the read is cached or rate-limited, or what the response contains — significant 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 short sentence with no filler and the operation front-loaded. It is arguably under-specified rather than padded, but as pure conciseness it is 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 an undocumented required parameter, the description leaves the agent without the auth scoping, error behavior, or return shape it needs to invoke this correctly. For a simple one-parameter read tool it is minimal but not sufficient.

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

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

There is one required parameter (id) with 0% schema description coverage, so the description must compensate. It says nothing about the identifier's format, whether it is a job ID, an offer-scoped ID, or a UUID, leaving the agent to guess from the sibling names.

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 pairs the verb "Read" with the resource "job" and adds an ownership scope ("owned"), which is more than a tautology. However, "delivery evidence" is undefined jargon, and nothing distinguishes this from the sibling tools (create_checkout, list_offers, run_offer) in terms of when a job record is the right target.

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 the siblings, no prerequisites, and no exclusions. The phrase "owned job" hints at a permission precondition but never states what qualifies as owned or what the caller should do otherwise.

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, but it only implies a read via 'List'. It says nothing about pagination, result ordering, whether it reflects real-time availability, or any auth requirements, which matters for an availability-checking 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 short sentence is appropriately sized, but it is under-specified rather than concise, and the key term 'offers' from the tool name never appears, weakening the front-loaded signal.

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

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

With no annotations, no output schema, and no parameters, the description is the only source of information and it is too thin: it never clarifies what an 'offer' is relative to the 'contracts, limits and availability' it lists, nor what the caller receives back.

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

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

The schema has zero parameters, so there are no parameter semantics to document; the baseline of 4 applies. The description adds no parameter information, but 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?

The verb is clear ('List'), but the resource is muddled: the tool is named list_offers yet the description talks about 'contracts, limits and availability' with no mention of offers, leaving the actual object being listed ambiguous. It also does nothing to distinguish itself from siblings like run_offer or get_job.

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 indication of when to call this versus run_offer, get_job, or create_checkout, and no prerequisites or context are given. The agent must infer usage entirely from the name.

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

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 mentions internal previews and historical allowances, but does not disclose side effects, idempotency behavior, permissions, whether an allowance is consumed, or what happens after invocation.

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 two tightly written sentences with zero waste. It front-loads the usage condition and follows with the alternative, making it easy to parse quickly.

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 tool with three required parameters, a nested input object, no annotations, and no output schema, the description is too thin. It adequately routes between run_offer and create_checkout, but does not provide enough behavioral or parameter detail for confident 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 description coverage is 0%, and the description adds no meaning for offer_id, input, or idempotency_key. With three required parameters including a nested input object, the definition leaves parameter usage 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 description states a specific resource ('bounded offer') and operation intent ('Use an existing internal preview or historical allowance'), and explicitly distinguishes itself from create_checkout for new purchases. It is clear enough to select the tool, though the exact effect of 'use' is not fully specified.

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

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

It explicitly names the alternative tool and the condition that selects it: use run_offer for existing previews or historical allowances, and use create_checkout for new purchases. This is direct when/when-not guidance.

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