PredMaker Alpha

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

Despite no annotations, the description discloses critical behaviors: 'Read-only / idempotent; no orders are placed' establishes safety, and 'Response JSON includes candidates[] plus an unlock block' explains output shape and the existence of a paid endpoint. This fully covers behavioral expectations.

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 compact, front-loading the purpose, with each sentence earning its place. The usage rule is presented in parentheses, and exclusions are concise. No fluff or 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?

Given the tool's complexity (cross-venue arb, fee buffer, output schema), the description is complete: it covers purpose, usage rules, exclusions, limit range, read-only safety, response structure including the paid unlock endpoint, and when full sizing is needed. 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?

With 0% schema description coverage, the description compensates by stating '`limit` is 1–10', giving a range constraint. However, it does not explicitly state that limit controls the number of candidates returned, though this is inferable from context. It adds value beyond the bare schema but is not fully explicit.

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 ('Return') and resource ('live Kalshi vs Polymarket US cross-venue box / mispricing teasers'), clearly identifying the tool's purpose. It also distinguishes itself from siblings by explicitly excluding single-venue forecasts, sports picks, and SEC filing alpha, which map to other tools.

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 explicit when-to-use instructions ('Call when you need fee-buffered arb candidates') with a concrete numeric rule (P_Kalshi_YES + P_Poly_NO < 0.97), and explicit when-not-to-use with alternative tools ('use the other tools for those'). This leaves no ambiguity about selection.

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 states 'Read-only / idempotent,' notes that DTR > 7 days are rejected upstream, and identifies returned fields. It could add error/edge-case behavior, but the key behavioral traits are 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?

The description is front-loaded with the core purpose, then gives usage conditions, exclusions, safety behavior, parameter range, and output fields. Every sentence earns its place with no repetition or filler.

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

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

For a single-parameter read tool with an output schema, the description covers purpose, when to use, when not to use, idempotency, limit bounds, and row contents. Nothing needed for correct selection or invocation is missing.

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

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

Schema description coverage is 0%, so the description must compensate. It does by documenting the valid range for `limit` (1–20), which the schema omits. It could more explicitly say limit means maximum number of returned rows, but the meaning is clear from context.

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

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

The description opens with a specific verb and resource: 'Return ≤7-day DTR US venue candidates with positive velocity score.' It clearly distinguishes itself from sibling tools by excluding SEC 8-K M&A teasers and long-dated Fed/macro lockups.

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?

Explicit when-to-use guidance is given: 'Call for short-dated equity / temperature / weekly index binaries from the Spark signals bus.' It also gives explicit when-not-to-call exclusions for long-dated lockups and SEC 8-K teasers, which maps directly to likely sibling alternatives.

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 provided, the description carries the full burden of behavioral disclosure. It explicitly states the tool is 'documentation only (read-only / idempotent)' and 'does not charge or place trades,' which is important safety context for an agent considering whether to invoke it. It does not discuss rate limits or data freshness, but for a read-only instruction tool, the disclosed behavior is sufficient.

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 concise and well-structured: purpose first, then when-to-use, then side-effect disclaimer, then parameter values, then pairing with a sibling. Every sentence contributes new information with no repetition or filler.

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

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

The tool is simple (one optional parameter) and an output schema exists, so the description does not need to explain return values. It covers the parameter's allowed values, the tool's read-only behavior, what content will be returned, and the related sibling to use next. Nothing essential is missing for an agent to invoke it correctly.

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

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

The input schema has no descriptions and 0% coverage, but the description compensates by defining the only parameter: '`product` is `signals` or `edgar-m-and-a`.' This gives the agent the allowed values and implied selection semantics beyond the bare schema title and default. It doesn't explicitly state the parameter is optional, but the schema already provides the default.

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

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

The description uses a specific verb and resource: 'Return subscription / paid-unlock instructions for PredMaker x402 products.' It clearly differentiates the tool from its siblings by naming the exact output and explicitly pairing with get_x402_payment_challenge, so an agent can determine what this tool uniquely provides.

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 says 'Call when you need the canonical price, treasury, freemium quota, and HTTP steps to unlock full payloads,' giving an explicit trigger condition. It also states what the tool does not do ('Does not charge or place trades') and names the sibling to pair with for a live challenge body, effectively routing the agent to the correct alternative.

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

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

With no annotations, the description carries the burden and it delivers: 'Read-only / idempotent; does not place trades' directly discloses safety and side-effect profile. It also reveals that full parameters are gated behind x402 and requires an unlock step. It stops short of discussing rate limits or data freshness, but the key behavioral traits are covered.

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

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

Three sentences deliver purpose, usage windows, exclusions, read-only status, parameter range, and the payment flow. The content is dense but organized, with the core purpose front-loaded. Minor punctuation/slash complexity costs a point, but it remains 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?

The description covers when, why, and how to invoke, plus the required x402 flow. The output schema presumably documents return fields, so not explaining return values is acceptable. The only slight gap is the ambiguity of 'the unlock URL in the response' – unclear whether it belongs to this tool or the payment challenge – but the overall flow is understandable.

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 provides a critical constraint not in the schema: '`limit` is 1–20.' For a single integer parameter with a default, this range is the main semantic gap, and the description fills it well.

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

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

The description opens with a precise statement: 'Return HMAC-committed SEC Form 8-K Item 2.01 M&A alpha teasers.' It names a specific verb, resource type, and qualifying detail. This clearly distinguishes it from the sibling tools (arbitrage spreads, velocity signals, x402 challenge).

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 states when to call ('Call after a material acquisition disclosure when you need teaser_id / proof_hash / entity metadata') and when not to call ('Do not call for Kalshi/Polymarket price arb or short-DTR velocity — those are separate tools'). It also provides a brief workflow for the x402 payment 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 carries the full burden. It discloses 'Read-only / idempotent; does not settle on-chain,' which prevents the agent from expecting a mutation. It also documents allowed product values and their pricing/endpoints. Rate limits and error behavior are not covered, but the key safety profile is present.

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 dense but efficient. Each sentence adds a distinct piece of information: what it fetches, when to call it, allowed values, safety profile, and next step. There is no fluff or repetition.

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?

An output schema exists, so return-value details are covered elsewhere. The description explains why to call the tool, what the result is used for (building an X-PAYMENT header), and the follow-up action. A minor gap is authentication/prerequisites, but it is not essential for fetching a challenge.

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 only parameter, product, has zero schema description coverage. The description fully compensates by listing allowed values ('signals', 'edgar-m-and-a'), their exact USDC amounts, and the corresponding API paths. This is precisely the semantic detail an agent needs to invoke the tool correctly.

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

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

The description uses a specific verb 'Fetch' and names a concrete resource: 'Base L2 x402 EIP-3009 payment challenge'. It clearly scopes the tool to the paid unlock path and distinguishes it from siblings by describing its role in the flow and naming get_monetized_unlock_instructions as the follow-up.

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 states the trigger condition: 'Call when a teaser tool returned an unlock block and you need the EIP-712 domain / amount / payTo to build an X-PAYMENT header.' It also tells the agent what to do after signing. It does not enumerate exclusions for all sibling tools, but the trigger context is clear enough.

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