paygentic

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

With no annotations, the description carries the full burden and does disclose real traits: 'Public' implies no auth required, 'Free' twice states cost (repeated poorly), and 'marked to the live price' reveals data freshness semantics for positions. It omits error behavior and whether results are paginated, but the key behavioral facts for a read tool are 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?

Front-loaded with the resource and its return fields, which is good, but 'Free' is repeated twice in a three-sentence blurb, which is pure waste. The remaining content is tight and 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?

No output schema exists, so the description must describe returns, and it does enumerate the fields returned (cash, positions, closed trades, equity). For a single-parameter read tool this is close to sufficient, with only error/empty-state behavior 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?

Only one parameter at 100% schema coverage, so the schema already defines 'id' as the agentId from arena_create_agent. The description's 'Input: id' adds no meaning beyond the schema, so baseline 3 applies.

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

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

Names a specific resource ('Public profile of a paper-trading agent') and enumerates what it exposes: cash, open positions, closed trades, equity. This distinguishes it from mutation siblings like arena_open_position or the aggregate arena_leaderboard, though it never explicitly contrasts with them.

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

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

No when-to-use guidance at all. 'Input: id. Free.' restates the required parameter and cost but gives no condition for choosing this tool over arena_leaderboard or arena_create_agent. Usage must be inferred from the resource 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?

With no annotations, the description carries the full burden, and it does disclose genuinely useful non-obvious traits: the operation is simulated ('no real funds') and costs $0.001 per call via x402 in USDC on Base, implying a payment step. It does not state whether closing is irreversible, what happens to a nonexistent/already-closed position, or any auth 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?

Two short sentences with the core action front-loaded, followed by the simulation and pricing caveats. No filler, though the pricing detail could be argued to be secondary for the agent's primary decision.

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 complexity is low (2 required string params, no output schema, flat structure), the description covers what an agent needs at a functional level: what it does, that it is simulated, and that it costs money. The main gap is parameter semantics, which is scored separately rather than counted here.

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 description adds no meaning for either parameter. agentId and position_id are both required but completely undocumented, so the agent gets no id format, source, or relationship guidance from either structured or unstructured text.

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 ('Close a paper position') for a specific actor ('for an arena agent'), which cleanly mirrors the sibling arena_open_position. The distinction from siblings is implicit in the verb rather than explicitly called out, 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: an agent can infer it closes an existing position, but there is no statement of preconditions (a position must exist and belong to the agent) and no explicit routing versus arena_open_position. Nothing misleading, but no real 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.

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

With no annotations present, the description carries the full burden and does well: it discloses that this is a paper-trading account with simulated cash, that no real funds are involved, that it is free, and critically that the returned agentId authorizes trading on the agent. It omits operational details such as idempotency or whether repeated calls create duplicate agents, keeping it short of a 5.

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

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

Front-loaded and mostly tight, but the word 'Free.' is repeated at both the middle and end of the sentence, which is wasted space. The 'Body: {name}' fragment is also redundant given the schema already exposes it.

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-param creation tool with no output schema, the description covers what an agent most needs: what gets created, what it costs, and the significance of the returned agentId for authorizing later trades. It stops short of describing failure modes or whether the agent persists, which is minor given the simplicity of the tool.

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

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

Schema description coverage is 100% and there is only one parameter (name), which the schema already documents as a 1-40 char display name. The description only echoes this as 'Body: {name}' and adds no constraint detail, so the baseline 3 is appropriate.

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 (create a paper-trading agent in the paygentic arena) and immediately scopes it with $10,000 simulated cash, real Hyperliquid prices, no real funds. This clearly distinguishes it from sibling arena tools like arena_leaderboard or arena_open_position, which presumably act on an existing agent.

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

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

The description implies this is the onboarding step ('Returns an agentId; keep it, it authorizes trading on this agent'), which hints that other arena tools depend on it. However, it never explicitly says when to use this versus alternatives or states prerequisites/exclusions for the create flow.

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 disclose real traits beyond the schema: the data is public, free, and sorted by live equity. However, it omits sort direction, whether results are paginated beyond limit, freshness/latency of "live" equity, and any auth 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?

Short and front-loaded: the resource and ranking are stated first, the parameter note last. The only waste is the duplicated trailing "Free.", which repeats the earlier "Free" and adds nothing.

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 zero-required-param read tool this is close to adequate: it says what the list contains and how to bound it. Missing return-shape context (which fields identify an agent, equity units/timestamps) and ordering direction leave real gaps, especially with no output schema to fall back on.

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

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

Schema description coverage is 100% and the single limit parameter is fully documented there, including range and default. The description merely restates "limit (1-100, default 20)" without adding format, behavior, or edge-case meaning. Baseline 3 applies.

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

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

States a specific verb-and-resource: a public leaderboard of paper-trading agents ranked by live equity. That is immediately understandable and names the ordering criterion. It does not distinguish itself from siblings like arena_agent_profile, though the resource is distinct enough to be inferred.

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, when-not-to-use, or alternative routing is offered. The closest thing to guidance is "Free" and "Public", which describe cost/access, not selection criteria. An agent gets no help deciding between this and arena_agent_profile.

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 trades are paper/simulated with no real funds and that the call is metered ($0.001 via x402 in USDC on Base) — real behavioral value. It omits other key traits: what happens on insufficient margin, leverage limits, reversibility, and error behavior.

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

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

Three short sentences, front-loaded with the core action, then the simulation caveat, then the cost. No redundancy and every sentence adds information an agent needs before calling.

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 5-required-parameter mutation-style tool with no annotations, no output schema, and 20% parameter coverage, the description is thin: it omits parameter expectations, failure modes, and how the position relates to arena_close_position. The payment/simulation note is helpful but insufficient for the tool's complexity.

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 20% (only coin is documented in the schema), and the description adds no meaning for agentId, side, size_usd, or leverage. It does not compensate for the coverage gap, and the odd leverage bounds (essentially unbounded integer) go unaddressed.

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 ("Open a paper position") and scopes it to an arena agent, which cleanly distinguishes it from the sibling arena_close_position by action. It does not, however, explicitly call out sibling relationships (e.g. perp_risk_check or arena_close_position) the way a 5 would.

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 never says when to use this tool versus alternatives such as perp_risk_check or arena_close_position, nor any preconditions (agent must exist, arena enrollment). It only notes that the position is simulated.

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 does substantial work: it discloses per-call pricing ($0.005), the payment rail (x402, USDC on Base), the input ceiling (4000 chars), the label count bounds, and the single-label output cardinality. It omits error/failure behavior, latency, and whether retries re-charge, which keeps it short of a 5.

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

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

Three telegraphic sentences, zero filler, purpose front-loaded before the parameter recap and pricing note. Every clause carries information an agent needs.

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 correctly compensates by stating the result is exactly one label, and it adds the cost/payment context a caller needs before invoking. Only failure modes and invalid-label handling are 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 100%, so both parameters (text, labels) are already fully documented in the schema. The description's 'max 4000 chars' and '2-20 strings' merely restate those constraints rather than adding syntax, format, or example meaning, so the baseline 3 applies.

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

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

States a specific verb (classify), the resource (text), the mechanism (LLM), and a precise output constraint ('exactly one of your own labels'). The sibling set is entirely unrelated domains, so no differentiation is needed and an agent can immediately tell what this does.

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 or when-not-to-use guidance and no alternatives named. 'your own labels' implies the caller supplies the taxonomy, but nothing tells the agent in what situations this tool is appropriate versus the sibling validation tools.

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 does reasonably well: it discloses the pay-per-call model ($0.005 per call, x402, USDC on Base), the output content, and the neutrality/disclaimer. It omits behavior like data freshness, latency, or failure modes, but the cost and scope disclosures are substantive beyond the name.

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?

Front-loaded with the purpose and tight at three sentences, each carrying information (what it returns, what it is not, cost). The parameter list and market example add slight redundancy but 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?

With no output schema, the description compensates by enumerating the return values (liquidation price, vol distance, slippage, funding, liquidity, flags) and the pricing of the call. Only minor operational details (data freshness, precision of the vol metric) are absent, so it is largely complete for a stateless calculation 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 75% and the schema already documents coin examples, the side enum, integer leverage and the size_usd range. The description only restates the parameter names (and repeats the long|short enum), adding little semantic meaning beyond the structured fields, so the baseline 3 applies.

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

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

States a specific verb and resource ('Pre-trade risk check for a Hyperliquid perp') and even scopes the supported markets (crypto and HIP-3 stock/index perps like xyz:NVDA). No sibling tool covers this, and the description makes the function distinguishable without opening the 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?

'Pre-trade risk check' clearly implies the use context (run it before sizing/opening a position), and it clarifies it is a neutral calculation rather than advice. It does not explicitly name alternatives or exclusions (e.g., relative to arena_open_position), so it stops short of full when/when-not 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 exist, so the description carries the full burden. It usefully discloses non-obvious behavior: the $0.002 per-call cost and the x402/USDC-on-Base payment mechanism. However, it omits other relevant traits such as error behavior on non-HTML/PDF responses, JS-rendered content handling, size limits, 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?

Three short sentences, front-loaded with the core action and output, followed by the value proposition and pricing. Every sentence carries information an agent needs, with 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 single-parameter fetch tool with no output schema, the description covers purpose, output format, cost, and payment mechanism. The main missing piece is behavior on failure or unsupported content types, which is minor at this complexity level.

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

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

Schema description coverage is 100% and there is a single required 'url' parameter, so the baseline is 3. 'Input: url' merely restates the schema and adds no format, validation, or edge-case detail beyond 'http or https' already in 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 (fetch) plus resource (any http(s) URL) and the output transformation (clean markdown), which cleanly separates it from siblings like validate_domain, validate_email, and classify_text. An agent can identify exactly what it does without opening the 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 description gives a rationale for using it ('saves agents tokens versus raw HTML'), which implies the usage context, but never states when to use it versus alternatives or any prerequisites/limitations. No sibling competes directly for URL fetching, so the omission is less costly, but no explicit guidance is provided.

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 disclose meaningful context beyond the schema — the paid call model ($0.001 per call via x402, USDC on Base) — but says nothing about latency, timeouts, caching, or what a failed/non-resolving domain 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?

Two short sentences, front-loaded with the capability and followed by the cost. The only waste is 'Input: d', which merely restates the schema field.

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 exists, but the description tells the agent what data comes back (resolution status plus A, MX and NS records), and pricing is covered. A one-parameter read-only lookup is adequately specified, though failure-mode behavior is not addressed.

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

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

Schema description coverage is 100% (the single 'd' parameter is documented as 'Domain name, e.g. example.com'), so the schema does the heavy lifting. The description's 'Input: d' adds no meaning beyond it — baseline 3.

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 (DNS check) and resource (a domain), and enumerates the exact lookups performed (resolution, A, MX, NS). That would let an agent distinguish it from siblings like validate_email, though it never names an alternative 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?

There is no when-to-use or when-not-to-use guidance, no prerequisites, and no mention of alternatives such as validate_email. Usage is only implied by the tool name and description.

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 two genuinely useful traits: the validation methodology (syntax + MX) and the per-call price of $0.001 via x402/USDC on Base, which matters for an agent that has to pay. However, it says nothing about failure behavior, what happens on malformed input, rate limits, or whether syntax failures short-circuit the MX lookup. Partial coverage, not complete.

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

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

Two compact sentences with the purpose front-loaded, followed by the input and cost. Every clause carries information relevant to invoking the tool. Slightly dense with the payment parenthetical, but nothing is wasted.

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

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

For a single-parameter validator this is nearly adequate, but there is no output schema and the description never indicates what a result looks like (boolean vs. structured details) or how validation failure is represented. The low complexity limits the damage, but the agent is left inferring the response shape.

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

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

Schema description coverage is 100% and there is one documented parameter ('e', described as 'Email address'). The description merely echoes the parameter name as 'Input: e', adding no syntax, format, or constraint detail beyond the schema. Baseline 3 is appropriate.

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 (email validation) and even specifies the method: syntax check plus MX lookup for the domain. That is well beyond a tautology. It stops short of a 5 only because it never distinguishes itself from the sibling validate_domain, which an agent could easily confuse with this one.

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 statement of prerequisites, and no routing against validate_domain or the other siblings. The only extra context is pricing, which is not usage guidance. An agent learns what the tool does but not when it should pick this over an alternative.

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