Panal

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

Annotations already declare read-only, idempotent and non-destructive, so credit goes to what is added: the Immediate vs Selection mode semantics, the on-chain hash verification of each advert, the wallet eligibility check with reasons, and the no-filter behaviour that surfaces leftover board items. It stops short of describing result shape or ordering, which matters since no output schema exists.

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 core purpose leads, followed by mode semantics, verification, wallet check, and finally the filter. Sentences are dense but each carries information; the long category enumeration is the only block that reads as a list dump rather than prose.

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 no output schema, the description covers modes, verification guarantees, wallet-conditioned output, and no-filter side effects. The main residual gap is not stating shape, ordering or volume of the returned list, which an agent needs to plan around.

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 one parameter at 100% schema coverage the baseline is 3, and the description earns above it by enumerating all sixteen valid category names, which the schema's generic "A category name or number" does not provide. It only omits clarification that the schema also accepts a numeric index.

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 first sentence states a specific verb and resource with scope: "List the jobs open right now on the Panal board with rules (PanalTablon)", immediately narrowing to jobs paid for without an agent chosen. It distinguishes this listing from the taking flow by naming panal_claim_task for leftover jobs, though it never contrasts itself with panal_board_job, the closest listing 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?

It explains the consequence of omitting the filter ("it also lists what is left from the previous board"), which implicitly guides whether to filter. But there is no explicit statement of when to pick this over panal_board_job or panal_search_agents, nor any exclusion for when this listing is the wrong entry point.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, and the description does not contradict them. Beyond that it adds real behavior: the private brief is only returned to a client or assigned agent, the brief is hash-verified, and 'that signs a read credential, no transaction' clarifies there is no on-chain write or gas cost — useful detail an agent would otherwise have to discover by error.

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?

Information density is high and the reader learns the returned payload first, but the entire definition is a single run-on sentence with a long parenthetical, and the opener 'Everything about one job' is vaguer than the specifics that follow. Nothing is truly wasted, yet the formatting makes it harder to scan than a short enumerated list would.

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

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

With no output schema, the description carries the burden of describing the return payload, and it does so field-by-field, plus permission and no-transaction semantics. The only gap is the unspecified relationship to the 'task' concept used by sibling tools, which matters for an agent choosing between them.

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

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

Schema coverage is 100%, so both parameters are already documented, including the 'client or agent only' restriction on include_brief. The description adds only the hash-verification nuance for the brief, which is marginal added meaning over the schema and earns the baseline rather than more.

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 ('one job on the board') and enumerates exactly what is returned: state, mode, category, amount, deadlines, offers with agent level/price/deadline and person flag, assigned agent and delivery state, and next available actions. It never explicitly contrasts itself with the sibling 'panal_get_task', so an agent must infer whether a 'job' and a 'task' are the same object.

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: it tells you the tool reads one job and that 'include_brief' requires the wallet to be the client or the assigned agent, which is a conditional gate rather than a when-to-use rule. It gives no guidance on when to pick this over panal_get_task or panal_board, leaving sibling selection 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?

Annotations already declare readOnly, idempotent, non-destructive, openWorld, so the safety profile is covered. The description adds genuine value by enumerating exactly what data comes back (pricing tiers, skills, status, on-chain name, owner-suggested example jobs) in the absence of an output schema. It does not say what happens for an unknown address, which is the remaining 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 front-loaded sentence with the resource first and the returned fields listed after the colon. Dense but every clause carries information; no filler or restated title.

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

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

For a one-parameter read tool with no output schema, describing the returned profile fields is the key completeness requirement, and it is met. Only error/empty-result behavior for a non-existent address is left unstated.

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

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

Schema coverage is 100% and the single 'address' parameter is already documented as 'The agent 0x… address.' The description's 'by address' adds no format, validation, or error semantics beyond the schema, 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+resource: 'Full profile of a Panal agent, by address,' and enumerates the fields returned (price, sizes, skills, status, on-chain name, example jobs). The 'by address' phrasing implicitly separates it from the broader sibling panal_search_agents, though it never names 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?

Usage is only implied: an agent infers this is the single-agent lookup for when it already holds an address, versus panal_search_agents for discovery. No explicit when-to-use, when-not-to-use, or prerequisite statement is 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorld=true, so the safety profile is covered. The description usefully discloses what the read returns (escrow amount, deadline, assigned agent, delivery flag), but adds nothing about failure behavior for missing tasks or freshness of the escrow state.

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 compact sentence with the most important payload fields listed up front and no filler. It loses a point only because the sentence fragment omits the operative verb (get/return), forcing the agent to infer the action.

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-only lookup with rich annotations and no output schema, the description covers the essentials by summarizing the returned data. It is only missing sibling disambiguation, which matters here because five related panal_* tools exist.

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

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

Schema coverage is 100% and the single task_id parameter is already documented as a numeric id, so the description need not compensate. It adds no extra meaning about id format, source, or validation, which is acceptable at this coverage level.

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 the resource (a job in the Panal escrow) and enumerates the fields it returns: amount, deadline, agent, and delivered status. It is a noun phrase rather than a verb phrase, and it never distinguishes itself from the sibling panal_board_job, which by name could plausibly return overlapping job data.

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 call this versus panal_board, panal_board_job, or panal_get_agent, and no stated preconditions (e.g., what happens with an unknown or non-escrowed task id). 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered elsewhere. The description adds that the output is aggregate marketplace figures rather than per-entity data, which is genuinely useful, but says nothing about freshness, caching, or the shape of the returned numbers. With annotations carrying the behavioral burden, this is adequate but 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 compact sentence, front-loaded with the subject and immediately listing the three metrics. No filler or repetition, though the phrasing 'how many ... how many ... how many' is slightly repetitive and could be tightened.

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

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

For a zero-parameter, read-only stats tool with no output schema, the description covers what is counted but not how the figures are scoped or when they were last refreshed. An agent knows broadly what it will get, but not enough to know whether these numbers are live or global.

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 and the baseline is 4. No parameter guidance is missing because no inputs exist.

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 enumerates the exact figures returned: agent count, active-agent count, and cumulative job count. That distinguishes it from the entity-oriented siblings (panal_get_agent, panal_search_agents), though it never explicitly contrasts itself with panal_board.

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 when a caller should reach for this versus panal_board or panal_search_agents, and no stated prerequisites. Usage is only implied by the fact that it reports aggregate counts.

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

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

Beyond the annotations, it discloses that no payment occurs here, the server holds no keys, the job only proceeds if the person opens and signs the link, and which validity checks run first (agent active and responsive, tier exists, brief fits). It also discloses the price-return behavior and the exact handoff expectation, which the annotations (readOnly=false, openWorld=true, idempotent=false) alone would not convey.

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

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

Three sentences, each doing distinct work: what it produces, what safety and side-effect posture it has, and what the agent must do with the result. The most important constraint (nothing is paid here, you hold no keys) is front-loaded in the first sentence.

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 four parameters, no output schema, and mutation-adjacent behavior, the description covers the essentials: the return is a link plus a price, and the caller is told what to display and how to deliver the link. It could be slightly more explicit about the shape of the returned link object or what happens if the checks fail, but nothing critical is missing 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 100%, so tier defaults, the 6/24/72/168 enum, the 0x address source and the brief all come from the schema itself. The description only reinforces the price/deadline context ('the person can change it on the page') rather than explaining arguments the schema leaves unclear, 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?

The description states a specific verb (prepare) plus the two concrete outputs (a job prepared for a Panal agent or person, and a link), and immediately clarifies that this is a draft, not a paid hire. That framing clearly separates it from sibling tools like panal_get_agent or panal_search_agents, which only resolve agents.

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 a clear condition for use (the person will review and pay with their own wallet) and explicit follow-up steps: show the price and recipient, then hand over the link exactly as returned. It also says the checks mirror a real hire and the price is reported. It stops short of naming a contrasting alternative tool, so it is clear context rather than 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?

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds real value beyond that: results are read live from the chain (no stale cache) and delisted agents are excluded by default. It does not describe result ordering, pagination, or result-cap behavior, which matters for a keyword search that can return everything.

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 what is searched and immediately followed by the empty-query behavior and the data-source caveat. No filler 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?

For a two-parameter read-only search with no output schema, the definition covers purpose, matching fields, empty-query semantics, and data freshness. The remaining gap is what a returned agent record contains and whether results are truncated, which is a modest omission rather than a blocking one.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: the query is matched against name, description, and skills, and an empty query means "return everything." The include_inactive behavior is only carried by the schema, but that is acceptable given full coverage.

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?

"Search AI agents on the Panal marketplace (Monad mainnet) by free text over their name, description and skills" gives a specific verb, resource, and searched fields, which is well beyond a restated title. It stops short of distinguishing itself from siblings such as panal_get_agent or panal_board, so an agent must infer that this is the listing/search path while panal_get_agent is the single-record path. The title's mention of "people" is also unexplained in the description.

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?

"With no query it returns every active agent" is a useful usage rule that tells the agent how to enumerate. However, there is no explicit guidance on when to prefer this over panal_get_agent or panal_marketplace_stats, and no stated exclusions. Usage is implied rather than prescribed.

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