PabandiOS

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

With no annotations, the description must carry behavioral disclosure. It does reasonably well by enumerating the payload (capabilities, skills, trust score, contact info), which implies a non-destructive read, but it says nothing about whether the agent must be registered, whether missing IDs error or return empty, or any rate/permission 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 sentences, front-loaded with the core action and immediately followed by the return contents. No filler, and the parenthetical equivalence is genuinely clarifying rather than padding.

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, the description covers what is returned and why, which is most of what an agent needs. The remaining gap is the absence of annotations plus no mention of error behavior for an unknown agentId.

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 agentId parameter is documented as 'Agent/passport ID', so the schema carries the load. The description adds no further meaning about the ID's format or how it relates to passports versus addresses, 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?

States a specific verb and resource ('Get an agent's A2A agent card') and anchors it to a well-known artifact (.well-known/agent.json), so an agent knows exactly what will be fetched. It does not distinguish itself from nearby siblings like pabandi_discover_agents or pabandi_agent_registry, which keeps it from 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?

The description says what it returns 'for agent-to-agent discovery' but never states when to call this instead of pabandi_discover_agents, pabandi_agent_registry, or pabandi_verify_passport. No prerequisites or exclusions are given, leaving routing entirely 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?

No annotations exist, so the description bears the full burden; it does disclose the return payload (handles, trust scores, capabilities), which is genuinely useful since there is no output schema. It says nothing about read-only safety, pagination behavior, rate limits, or whether the list is filtered by caller identity.

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 purpose front-loaded and the return shape second. There is mild redundancy between "agent registry" and "listing all discoverable agents," but nothing wasteful.

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, naming the returned fields is the key contribution and it is present. Remaining gaps (pagination semantics, whether results are tenant-scoped) are minor but real.

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 `limit` parameter is fully documented with a default, so the schema does the heavy lifting. The description adds no meaning beyond the schema, which is the expected baseline here.

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?

A specific verb+resource ("Get the agent registry") with a clear scope ("all discoverable agents on Pabandi") and a sketch of returned fields. However, it offers no differentiation from close siblings like pabandi_discover_agents and pabandi_agent_card, which an agent would need to choose between.

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 pabandi_discover_agents, pabandi_agent_card, or pabandi_trust_resolve. The only usage hint is implicit: that it is a bulk listing rather than a single lookup.

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 discloses key behavioral traits: this is a write operation that creates a booking, holds a deposit in escrow, releases on check-in, refunds on cancellation, and is gated by settlement/PTP criteria. It still omits idempotency, permission/error behavior, and what happens on partial failures.

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 purpose is front-loaded, but the description contains marketing language and internal implementation jargon such as 'hospitality money rail' and 'exclusive to quality hosts' that do not help an agent invoke the tool. It is usable but not tight.

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 complex money-moving mutation with no annotations and no output schema, the description covers the deposit lifecycle and gating well. It still lacks return-value expectations beyond 'actual platform response', error handling, and idempotency 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 coverage is 100%, so the baseline is 3. The description adds some meaning around depositAmount by framing the guest deposit as a held trust anchor, but it does not clarify the other parameters, and it does not resolve the schema's own 'optional' annotations on required fields.

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 action and resource: creating a confirmed stay reservation for a property, including deposit escrow. It does not explicitly distinguish itself from siblings like pabandi_predict_booking or pabandi_start_escrow, so sibling differentiation is weak.

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 real usage condition: the business must have an attested open-finance settlement rail or PTP Band A/B. However, it does not state when to use this tool versus alternatives such as pabandi_start_escrow or pabandi_predict_booking, leaving the routing decision mostly implicit.

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 and delivers almost nothing. "Cancel" implies a destructive, state-changing operation, but the description never states whether cancellation is reversible, whether a refund or escrow release is triggered (relevant given the pabandi_escrow_* siblings), what permissions are required, or what happens on 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?

Three words, front-loaded, with zero filler. However, the terseness crosses into under-specification rather than disciplined conciseness, so the brevity does not fully earn 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?

The tool is a single-parameter mutation in a domain dense with finance and escrow siblings, yet it ships with no annotations, no output schema, and a three-word description. An agent cannot tell from this definition what side effects, refunds, or failure modes to expect when cancelling.

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% for the single bookingId parameter, so the schema already documents the input and the baseline of 3 applies. The description adds no meaning beyond the schema, such as the expected ID format or whether the ID must belong to a booking the caller owns.

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?

"Cancel a booking" names a specific verb and resource, so the intent is unambiguous. But it is essentially a restatement of the tool name with no scope information (what a cancellation entails, whether it applies to confirmed vs pending bookings) and no differentiation from the many booking-related siblings such as pabandi_create_booking or pabandi_book_stay.

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 tool versus alternatives, no prerequisites, and no exclusions. The agent must infer entirely from the tool name that this is the inverse of pabandi_create_booking and that it is not the same as pabandi_book_stay or pabandi_session_close.

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 yet says nothing beyond the one-liner. It doesn't confirm this is a read-only operation, whether it requires a booked/registered business, how availability is expressed, or whether results are scoped by timezone or service.

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. It is efficient, though its brevity borders on under-specification rather than pure 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 simple two-parameter read tool this is roughly adequate, but with no output schema the description gives no hint of what an availability result looks like (slots, boolean, price), leaving an agent to call it blind.

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 the schema already documents both parameters including the YYYY-MM-DD format. The description names the same two dimensions (business, date) but adds no semantics such as timezone handling or whether the date is singular, 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?

States a specific verb and resource ('Check availability for a business') plus the scoping parameter (a specific date). It is clear what the tool does, but nothing distinguishes it from siblings like pabandi_recommend_slots or pabandi_predict_booking, which an agent could plausibly confuse it with.

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 the several availability-adjacent siblings (pabandi_recommend_slots, pabandi_predict_booking, pabandi_book_stay). Usage is only implied by the phrase 'check availability'; no prerequisites or exclusions are 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?

No annotations, so the description must carry the burden; it does disclose the returned fields (trustScore, tier, verifiedIdentity, minimum-score clearance) and the default threshold, which is useful. However it never states that this is a non-mutating read, says nothing about missing/invalid passport behavior, and covers no auth or rate-limit 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?

Three short sentences, front-loaded with the action and answer, with no redundant filler. Slightly compressed to the point that the return-field list reads like a schema echo.

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, naming the returned fields is valuable, but the description omits error/edge behavior (unknown passportId, what an insufficient score returns) that an agent needs to interpret the result correctly for a trust-gating decision.

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 in the schema; the description only restates the default of 500 for minScore. No additional semantics (e.g., score bounds or what a floor means for the returned boolean) are added.

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 ('Check a counterparty's Trust Passport') and adds the intent ('before bidding'). It does not differentiate from close siblings like pabandi_verify_passport or pabandi_trust_resolve, 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?

Gives an implied usage context ('before bidding', 'evaluate who to transact with') but no explicit when-to-use versus when-not, and no mention of the sibling verification tools. Adequate but leaves routing 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 at all, the description must carry the full burden, and it does disclose meaningful behaviors: masking is guaranteed ('never raw'), a PTP attestation is produced, and a real HTTP call is made returning the actual platform response. It omits key concerns for a 'register' operation — whether a persistent record is created, duplicate-provider handling, auth requirements, and idempotency.

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 action and provider list are front-loaded and every sentence carries information about masking, attestation, or the real-endpoint behavior. Slightly padded by framing language ('trust badge on a listing', 'open-finance connectivity primitive').

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 tool with no annotations and no output schema, the description should ideally state whether the returned attestation has a structure or what a failed registration looks like. It says a real platform response is returned but leaves the persistent side effects and error surface unspecified.

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 enum-like provider values and the accountRef meaning are already documented in the schema. The description reinforces that the reference must be masked and opaque, which adds a little, but not enough to exceed the baseline for fully documented parameters.

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?

Opens with a specific verb+resource ('Register a verifiable, masked settlement connection') and enumerates the supported providers, which is far more than a restatement of the name. It does not, however, name any sibling tool (e.g. pabandi_list_finance or pabandi_finance_quote) to draw the boundary 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 'trust badge on a listing' framing implies why a business would call it, and 'prove it has a real payout path' hints at the use case. But there are no explicit when-not conditions, prerequisites, or routing to alternatives among the many finance-related 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 are provided, so the description carries the full burden of behavioral disclosure. Aside from naming supported payment protocols, it does not describe side effects, permission requirements, conflict behavior, idempotency, 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?

The description is two short sentences and is front-loaded with the core action. It is efficient, though the second sentence largely duplicates the protocol enum in the schema.

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?

This is a mutating booking tool with no annotations and no output schema, yet the description omits return behavior, side effects, validation or conflict handling, and sibling differentiation. It is not complete enough for an agent to invoke it confidently without further inference.

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 the schema already documents all five parameters, including the protocol enum. The description repeats the protocol names but adds no parameter semantics beyond what is already in the schema, making the baseline 3 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?

The description clearly states a specific verb and resource: 'Create a booking.' It adds that the booking is for an agent/client, but it does not distinguish this tool from the sibling pabandi_book_stay, which also appears to create bookings.

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 tool versus pabandi_book_stay, pabandi_check_availability, or pabandi_cancel_booking. The mention of supported protocols is a capability statement, not usage guidance or prerequisites.

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 must carry the burden, and it does disclose that funds are actually locked (a mutation with financial consequence) and that the tool charges a 0.5% fee — useful cost information rarely found elsewhere. It omits what release/verification requires, who can trigger release, and whether the escrow can be cancelled or refunded, which are important behavioral gaps for a funds-locking 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?

Four short sentences, each carrying distinct information (purpose, locking behavior, return fields, price), front-loaded with the action. No filler, though the return-value sentence is slightly redundant boilerplate given it is not the primary concern.

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 no-annotation, no-output-schema mutation tool, the description usefully compensates by naming the returned fields (escrowId, status, amount locked) and the fee. It still leaves the lifecycle — how the escrow is later verified, released, or refunded, and which sibling handles that — entirely to the agent's guesswork.

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 all four parameters (amount, description, payerId, payeeId) are already documented in the schema. The description adds only the currency context ('amount locked') and the fee calculus, not new per-parameter 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 and resource ('Create an escrow') plus a scope qualifier ('for an agent-to-agent deal'), so the intent is unambiguous. It does not, however, distinguish itself from the many escrow siblings (pabandi_request_escrow, pabandi_start_escrow, pabandi_escrow_lock), 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?

The phrase 'for an agent-to-agent deal' hints at the context but gives no explicit when-to-use rule, no prerequisites (funded payer, registered identities), and no guidance on when to pick this over request_escrow or start_escrow. The agent must infer routing from sibling names 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 provided, the description carries the full burden, and it does disclose the key operational fact that no auth is required, which tells the agent this is a safe, unauthenticated bootstrap read. It also enumerates the payload contents, partially substituting for the absent output schema. It stops short of stating idempotency, rate limits, or what the risk bands signify.

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 purpose followed by return contents and then the auth constraint. No filler, though 'PTP' going undefined is an omission rather than an inefficiency.

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-param, no-annotation tool with no output schema, the description does well to list the returned fields and the auth posture. The remaining gap is disambiguation from sibling discovery tools, which is the one thing an agent cannot recover from the schema.

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 and the schema is an empty object, so there is nothing for the description to disambiguate. Baseline 4 applies; the description correctly implies no inputs are 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+resource pair ('Get PTP discovery (public)') is identifiable, and the description enumerates what comes back (verify endpoint, public key, issue endpoint, risk bands, entity types). However, 'PTP' is an unexplained acronym and the definition gives no basis for choosing it over the near-identically named siblings pabandi_discover_platform and pabandi_platform_discovery, leaving the agent to guess which discovery surface it needs.

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 the two other discovery tools, nor any prerequisite or sequencing advice (e.g. call before pabandi_verify_passport to obtain the public key). The '(public)' marker hints at an unauthenticated bootstrap use case but the agent must infer 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?

No annotations are supplied, so the description carries the full burden. It does disclose the return shape (relevance-sorted, trust scores, capability badges), which is genuinely useful, but says nothing about permissions, rate limits, pagination, or what happens when no agents match.

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 capability statement front-loaded and the return shape second — nothing is padded. The brevity is only a problem insofar as it leaves the gaps above unfilled.

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-required-parameter discovery tool with a fully annotated schema and no output schema, the description covers purpose and return shape adequately. It falls short on sibling differentiation and on the phantom 'location' dimension, which is exactly the kind of thing a discovery tool's description should get right.

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 four parameters are already documented. The description does not add filter syntax or matching semantics beyond the schema, and worse, it advertises filtering 'by location' while no location parameter exists — a misleading claim that could send an agent looking for a filter it cannot pass.

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 ('Discover agents') plus the filter dimensions and return shape, so the operation itself is unambiguous. It does not, however, distinguish itself from the sibling pabandi_discover, which an agent would reasonably read as doing something very similar.

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 exclusions, and no mention of the adjacent tools (pabandi_discover, pabandi_agent_registry, pabandi_agent_card) that plausibly compete for the same intent. The agent must guess which discovery entry point to call.

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 implies a read-only aggregate lookup and hints that status is fetched live, which is mildly useful behavioral context. It says nothing about authentication, rate limits, response shape, or whether it is a one-shot bootstrap call versus something to re-poll.

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, and the enumerated payload is the most useful part. The list is slightly dense but every item adds informational value.

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 does the necessary work of naming what comes back, which is the key requirement here. It falls short by not clarifying its relationship to the overlapping discovery siblings, which is the main ambiguity an agent faces when choosing this 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The description correctly implies a no-argument, whole-platform snapshot call.

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 clear verb ('Discover') and enumerates the payload (tools, spec URLs, MCP/PTP endpoints, SDK info, tiers, status), so the resource is identifiable. However, with siblings named pabandi_discover, pabandi_platform_discovery and pabandi_platform_access, the description makes no attempt to distinguish this from those near-identical discovery tools, leaving the agent unable to tell which one to pick.

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 stated preconditions, and no mention of alternatives among the three sibling discovery/access tools. The agent must infer usage purely from the enumerated payload.

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 supplied, so the description carries the full burden. It usefully discloses the external sources being scraped and the categories of data returned, which hints at network latency and third-party dependency, but it says nothing about failure modes for unregistered or unparseable domains, whether partial results are returned, or rate/cost 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?

Two sentences: the first front-loads what is fetched and from where, the second front-loads when to reach for it. Nothing is redundant or padded.

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 and no annotations, this covers sources, output categories, and usage timing. The remaining gap is behavioral: how it behaves on miss, and whether results are cached or slow, which matters for an external-scraping 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?

There is a single required parameter with 100% schema description coverage plus a worked example ('acme-corp.com'), so the schema already does the work. The description adds no extra meaning about accepted domain formats, subdomains, or whether a URL with scheme is tolerated.

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 (scrapes/enriches) plus the resources it touches (website, GLEIF, OpenCorporates) and the concrete outputs (contact info, tech stack, legal verification). A reader knows exactly what this returns, though it never distinguishes itself from nearby siblings such as pabandi_get_business or pabandi_check_counterparty.

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 states a clear trigger condition: 'Use this before onboarding a new business to verify their legitimacy.' That is real when-to-use guidance. It stops short of exclusions or naming alternative tools when only a lighter-weight lookup is 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?

No annotations are provided, so the description carries the full burden; it does establish that this is a non-mutating 'check' and it discloses the four return fields, which is valuable given there is no output schema. However, it says nothing about permission/auth requirements, behavior when the escrow does not exist, or what the possible status values are.

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 action is front-loaded and the return-field list follows. Since no output schema exists, that second sentence earns its place rather than repeating structured data.

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 and no annotations, the description covers the action and the return shape, which is enough to call it correctly. It is only slightly short of complete because status semantics and failure modes are 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 description coverage is 100% for the single parameter, so the schema already documents escrowId ('Escrow ID to check'). The description adds no format, source, or lookup guidance beyond that, 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 ('Check escrow balance and status') and enumerates the returned fields, which pins down what the tool does. It does not name sibling operations like pabandi_escrow_lock or pabandi_escrow_release to explicitly frame this as the read-only counterpart, so it stops short of full sibling differentiation.

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 the other escrow tools (lock, release, waterfall, create_child, start_escrow) and no stated preconditions such as requiring an existing escrowId or a particular escrow state. 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?

Since no annotations are provided, the description carries the full burden. It adds value by explaining the mechanism ('Allocates a portion of master funds') and specifying the return values ('Returns childEscrowId and amount allocated').

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 definition is highly concise and structurally perfect. The first sentence defines the 'What' and 'Why', and the second sentence defines the 'How' and 'What to Expect'.

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 absence of an output schema, the description is complete because it clearly defines the behavioral outcome and the specific data types returned (childEscrowId and amount allocated), which is sufficient for an agent to execute the operation.

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%, providing a strong baseline. The description provides valuable human-readable semantics for the required parameters (e.g., defining `providerPassportId` as the 'Subcontractor passport/agent 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?

The description clearly states the action (Create a child sub-escrow), the resource (child sub-escrow), and the specific business context (parent-child subcontracting). This distinguishes it well from other general escrow tools like `pabandi_start_escrow`.

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?

While it defines the use case (allocating funds to a subcontractor), it does not explicitly define when this tool *should not* be used, offering only implied usage rather than prescriptive boundaries.

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 the tool creates and funds a new escrow and returns escrowId, status, and amount locked, but it does not mention permissions, reversibility, failure behavior, or how idempotency is enforced.

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 short, front-loaded with the core action, and includes return values and usage context without unnecessary repetition. Every sentence contributes useful 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 description covers the core mutation and return values, which is helpful because no output schema exists. However, for a financial mutation tool with no annotations, it omits important context such as permissions, irreversibility, idempotency behavior, and how it relates to sibling escrow tools.

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 schema already documents all four parameters, including amount, description, idempotencyKey, and deliverableHash. The description does not add meaning beyond the schema, so 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?

The description states a specific financial action: locking funds in escrow by creating and funding a new escrow. It is clear what the tool does, but it does not distinguish itself from sibling tools such as pabandi_start_escrow or pabandi_escrow_release.

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 usage context: the primitive agents use to put money on hold before work begins. However, it does not explicitly name when to use this versus pabandi_start_escrow or when not to use 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 burden for a financial mutation. It says funds are 'released' but does not disclose irreversibility, permission or authorization requirements, what happens if deliverableHash does not match the locked hash, or whether release can be undone. Only the return values are mentioned.

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 action and outcome, with no filler. The 'Requires escrowId' sentence is mildly redundant against the schema but is a defensible emphasis of the single mandatory argument.

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?

It covers the action and a partial return description (status and amount released) with no output schema to lean on, but for a fund-moving operation it omits preconditions, failure modes, and irreversibility. Adequate to call, not adequate to call safely.

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 all three parameters are already documented, and the description's 'Requires escrowId' merely restates the required field. It adds no meaning for idempotencyKey or deliverableHash beyond what the schema says, 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 gives a specific verb and resource: 'Release locked escrow funds to the recipient,' which an agent can distinguish from siblings like pabandi_escrow_lock or pabandi_escrow_waterfall. It does not explicitly name the contrasting siblings, so it falls 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?

The phrase 'locked escrow funds' hints that a prior lock step is a precondition, but there is no explicit when-to-use, when-not-to-use, or named alternative among the many escrow siblings. The agent must infer the workflow context entirely.

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 does disclose the key side effect: it mutates state by marking the master escrow completed. However it omits idempotency (is repeated triggering safe?), required permissions, and what happens if children are not yet released — significant gaps for an unannotated mutation 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 compact sentences with the core action front-loaded and no filler. The trailing 'Returns settlement status' is thin but at least signals a return value in the absence of an output schema.

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 tool this is mostly adequate, but with no annotations and no output schema, the description leaves the agent guessing about safety, idempotency, and the shape of 'settlement status'. A sentence on the safe-retry profile would close the 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?

Only one parameter with 100% schema description coverage, so the schema already covers it fully. The description adds the notion that this is the parent/master whose children are aggregated, which is mild added meaning over 'Master escrow ID to check'.

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 concrete verb+resource: check and trigger waterfall settlement for parent-child escrows. This clearly separates it from sibling escrow tools like pabandi_escrow_release or pabandi_escrow_balance, 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 condition 'When all child escrows are released' implies the trigger point, but it is framed as behavior rather than an instruction to the agent. No explicit when-to-use/when-not-to-use guidance or named alternative 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?

With no annotations, the description carries the full burden and does well: it explains the session-based auth model (authorised once against a Trust-Score-derived limit, no per-call wallet signature), the refusal behavior without a session, and an output-side behavior (actionRequired 'deposit_required' plus a deposit object with checkoutUrl). It stops short of describing the receipt/ledger response or what happens on partial failure, so not 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 with the purpose and the hard prerequisite, and each sentence carries actionable information. Minor waste in the editorial aside 'which is the entire point' and a slightly long final sentence, but overall tight for the amount of behavioral context it packs in.

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 5 parameters, no annotations, and no output schema, the description covers the critical gaps: session prerequisite, action types, and the booking deposit return path. It could say more about the receipt returned and how spend affects the session limit over time, but an agent can call it correctly from this text.

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 schema already documents amount-in-USDC, payload.businessId for bookings, sessionId provenance, and idempotencyKey retry semantics. The description largely restates the sessionId requirement and adds little parameter-level detail beyond what the schema provides, so 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 ('Spend against an open PabandiSession') and enumerates the three action types (book, pay invoice, fund escrow), which map directly to the actionType enum. It clearly distinguishes itself from pabandi_open_session and from the per-action siblings like pabandi_book_stay and pabandi_start_escrow.

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?

Explicitly states the prerequisite (REQUIRES a sessionId), names the alternative (call pabandi_open_session first and use its sessionId), and describes the failure mode if you skip it ('this tool will refuse without one rather than fall back to a per-call signature'). It also gives conditional guidance for the booking deposit 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 burden and does disclose that this is a real HTTP call against the canonical endpoint returning actual platform output rather than a mock. However it omits auth requirements, rate limits, quote validity/expiry, and whether quoting has any side effects — meaningful gaps for a payout-adjacent 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?

Purpose, return values and flow context are front-loaded in the first two sentences. The final sentence about the 'real HTTP call to the canonical Pabandi endpoint' is somewhat boilerplate but does carry latency/fidelity 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 output schema, the description usefully lists returned fields (fees, execution window, rail), so an agent knows what comes back. It is still thin for a financial tool with no annotations: nothing on quote lifetime, failure modes, or permissions.

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 parameter is documented, so baseline is 3. The description adds genuine meaning by stating the tool *returns* the rail to use, clarifying that rail selection is an output rather than an input an agent should search for 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 and resource ('Quote an offramp/payout') and enumerates the rails involved (RAAST, Stripe, Solana), which clearly separates it from ledger/escrow siblings. It stops short of naming which sibling to use instead, so differentiation is implicit 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?

'Feeds the hospitality payout flow' gives a usage context, implying this is a pre-payout estimation step. There is no explicit when-to-use/when-not guidance and no mention of alternatives such as pabandi_start_escrow or pabandi_list_finance, which the agent must infer.

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 discloses return fields (status, verdict, confidence, reasoning) and enumerates status values, but it does not state whether the operation is read-only, what permissions are required, or what happens if the case is not found.

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 sentences, front-loaded with the core operation, and has no redundant or filler content. Every sentence contributes to what the tool does or what it returns.

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 two-parameter lookup tool with no output schema, the description is mostly complete because it explains the returned fields and status values. It still omits usage context and behavioral details such as permissions or error handling, but the core lookup is well covered.

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 both jobId and caseId are documented in the schema, including that caseId is an alternative to jobId. The description adds no parameter-level meaning beyond the schema, so the baseline score 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?

The description states a clear verb and resource: checking the status and verdict of an adjudication case. It is specific enough for an agent to understand the operation, but it does not differentiate this tool from related siblings such as pabandi_submit_dispute_evidence or pabandi_trust_resolve.

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 guidance on when to use this tool versus alternatives, nor any stated prerequisites or exclusions. The implied usage is only that an agent should call it when it needs adjudication status, which is not enough to route reliably among many sibling 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 full burden and does disclose important traits: the result is a sanitized public projection, owner PII is gated, and the call is a real HTTP request against the canonical endpoint. It does not state auth requirements, rate limits, or error behavior, which is a gap but not severe for a read lookup.

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 purpose and scope, then the return fields, then the PII routing note. Every sentence earns its place and there is 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 read tool with no output schema, the description compensates by listing the concrete fields returned and clarifying the live-call behavior. Missing are error cases and whether authentication is required for the public view, so it is close but not fully 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 coverage is 100% and already documents the single 'id' parameter as a cuid or googlePlaceId. The description adds no syntax, format, or lookup-precedence detail 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 ('Resolve a business profile by id') and immediately scopes it as the public view. It also names the distinct PII path (pabandi:verify_owner), which separates it from sibling tools such as pabandi_discover or pabandi_search_services.

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?

Clearly signals when to use this tool (lookup by id for the public profile) and when to use an alternative (full PII via pabandi:verify_owner). It does not address when to prefer this over the discovery/search siblings, so it falls short of explicit 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 and does well: it discloses that access is public (no auth implied) and enumerates the returned fields (feePab, ownerUserId, agentId, riskBand, capabilities, chargedAt). It omits not-found/error behavior, keeping it from 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 with purpose and key, followed by the return payload and a compact example. Every sentence earns its place 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?

No output schema exists, so listing return fields is exactly the right compensation, and a single-parameter lookup needs little more. Only the failure case (unknown key) is 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 coverage is 0% for the single parameter, so the description must compensate — and it does, giving a concrete example of the idempotencyKey value format ("iss-3001"), which tells the agent what shape of key to supply.

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 ('look up') and resource ('passport issuance charge') plus the lookup key, which distinguishes it from write-side siblings like pabandi_issue_passport and pabandi_verify_passport. It doesn't name 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?

'public audit' implies a read-only reconciliation context, but there is no explicit statement of when to use this versus pabandi_issue_passport or when a key would be absent. The use case is implied rather than directed.

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 implies a read-only lookup but says nothing about whether the businessId must exist, what happens on an unknown ID, pagination of results, or required auth — all meaningful for an agent booking flow.

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, but it is under-specified rather than concise — the phrase 'for agent booking' occupies space without adding actionable 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 one-parameter read tool without an output schema, the description leaves the return shape (service list fields, availability, pricing) and error behavior unexplained. Adequate to start a call but thin for planning how to use the result in a booking workflow.

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% with a single required businessId, so the schema already documents the parameter fully. The description adds no meaning beyond it (e.g., no note on ID format or source), making baseline 3 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 verb ('Get') and resource ('services offered by a business'), which is understandable, but the trailing 'for agent booking' is vague and doesn't distinguish it from the sibling pabandi_search_services, which appears to cover similar ground.

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 the closely related sibling pabandi_search_services. The agent must guess whether this or search_services is the right entry point for a given booking 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 full burden: it does disclose that this is an onchain write, that Pabandi pays gas (useful cost/account model), and what is returned (agentId + tx hash). It leaves out idempotency (what happens if already registered), required auth/permissions, and irreversibility of the onchain write.

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 short sentences, front-loaded with the action and standard, then benefits, return values and cost. The 'verifiable across the ecosystem' clause is mildly promotional but still conveys portability, so waste is minimal.

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 the description does compensate by naming the returned agentId and tx hash. However, for a one-parameter mutation with zero annotations, the description omits error/duplicate-registration behavior and permission requirements, leaving the agent under-informed about failure modes.

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?

Single parameter with 100% schema description coverage, so the schema already explains passportId. The description adds no format, source (obtained from issue_passport?) or validity detail 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 (register an agent's identity onchain) and names the underlying standard (ERC-8004), which an agent can use to distinguish it from generic identity siblings. It does not, however, explicitly contrast with pabandi_issue_passport or pabandi_identity_reputation_sync, so the agent must infer the boundary.

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 requirement of a passportId and the 'portable identity verified across the ecosystem' framing imply this is a post-passport step, but the description never states when to call it versus issue_passport, verify_passport or identity_reputation_sync. No explicit exclusions, prerequisites or re-registration caveats 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; it does disclose the key behavioral traits that this is an onchain write and that it is gasless (Pabandi pays gas), which is genuinely useful. It omits idempotency (does re-syncing overwrite prior feedback?), reversibility, and latency/confirmation behavior for a chain write.

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 action and target, then the payload, then the cost model. No filler and no repetition 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 an unannotated onchain mutation with no output schema, the description covers what is written and who pays gas, but leaves open the result of the call, whether prior reputation is appended or replaced, and any precondition on the passport. 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?

There is a single parameter with 100% schema description coverage, so the schema already defines passportId. The description only indirectly implies passport scoping ('an agent's trust score') and adds no format or sourcing detail beyond the schema, matching the 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?

Specific verb+resource: syncs an agent's trust score to the onchain ERC-8004 reputation registry, and clarifies what is posted (task feedback and success rate). It is distinguishable from siblings like pabandi_trust_resolve or pabandi_verify_trust_attestation by the write-to-registry framing, though no sibling is named 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?

'Posts feedback about completed tasks and success rate' implies the trigger is task completion, but there is no explicit when-to-use, no exclusions, and no mention of prerequisites such as an existing passport or prior identity registration.

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?

Since no annotations are provided, the description must carry the behavioral burden. It provides high-value operational traits: authentication requirement, trust band validation, specific metered cost, and the function of the idempotencyKey. This avoids ambiguity for an AI agent.

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 highly efficient, front-loading the core action and immediately following up with critical operational requirements (auth, cost). Every word provides distinct information without unnecessary fluff.

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 is exceptionally complete for a high-stakes financial operation. It covers input requirements, authentication methods, technical guarantees (idempotency), and business constraints (metering/pricing), leaving virtually no ambiguity for an executing agent.

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?

Even with 100% schema coverage, the description adds vital semantic meaning. It clarifies the purpose of the optional 'idempotencyKey' (preventing double-charging) and provides a complete, runnable JSON example that illustrates the expected payload structure 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?

The description clearly defines the action ('Issue') and the resource ('Agent Capability Passport'). By framing it as a 'scoped' passport validated against a 'trust band', it clearly defines its unique operational domain within the larger suite of PABandi 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?

It establishes critical usage constraints, including the requirement for Bearer token authentication and defining a clear metered cost ('PAB_FEE_PER_PASSPORT'). While it doesn't explicitly name alternative tools, the presence of cost and trust band validation helps an agent decide if this function is appropriate for its task.

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 discloses that this makes a real HTTP call to the canonical Pabandi endpoint and returns the actual platform response, but it omits auth requirements, error behavior, rate limits, and pagination 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?

The definition is three sentences and front-loads the core behavior. The HTTP-call sentence is somewhat implementation-focused but still earns its place by signaling that the response is live rather than mocked or cached.

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 list tool with no annotations and no output schema, the description covers purpose, use case, and the verified/pending scope. It still leaves notable gaps around permissions, error handling, and the structure of the returned platform 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?

Schema description coverage is 100%, so the single businessId parameter is already documented structurally. The description adds context about whose connections are returned but does not add format or validation details beyond 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?

The description states a specific verb and resource: returning a business's connected open-finance connections, including verified and pending ones. It is clear what the tool does, but it does not explicitly differentiate itself from sibling tools such as pabandi_connect_finance or pabandi_finance_quote.

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 use case: third parties use it to confirm a business has a real payout path before booking or partnering. It does not state when not to use it or name alternative tools, so it falls short of full 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, the description carries the full burden. It usefully discloses that this makes a real HTTP call to the canonical endpoint and returns the actual platform response, and 'List' implies a read. However, it omits permissions, rate limits, error behavior, and pagination, so coverage 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?

Purpose is front-loaded in the first sentence and each following sentence adds a distinct facet (return linkage, surface identity, network behavior). Slightly verbose but no sentence is clearly wasteful.

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 should clarify return structure, yet 'returns the actual platform response' is vague about fields, shape, and pagination. It does explain that properties tie to a business and finance settlement rail, which partially compensates, but overall completeness is only adequate.

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 schema already documents both required parameters; baseline 3 applies. The description restates 'by city or category' but adds nothing about the ambiguous category values ('PROPERTY_RENTAL / LIVE_SELLER / ...'), leaving that ambiguity unresolved in both schema and 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 verb and resource: 'List open short-term rentals / stays (Airbnb-style) by city or category.' The framing 'This is the hospitality inventory surface' gives some functional context, but no sibling tool is named, so the differentiation from pabandi_book_stay or pabandi_search_services is left implicit.

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 guidance. Despite many siblings (book_stay, search_services, predict_booking), the description never states conditions that select this tool over them; the 'inventory surface' line is context, not a decision rule.

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 project is open, escrow-protected, and returns projectId and hireUrl. However it omits who funds the escrow, when funds are locked, fee implications, and whether the post can be cancelled or edited.

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 short sentences, front-loaded with the action and outcome, with return values flagged early. The final sentence is somewhat redundant with the second but does add actor context.

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 mutation with no annotations and no output schema, the description partially compensates by naming the return fields. It still leaves the escrow lifecycle and permission requirements unexplained, which matters for a tool that moves money.

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 all 7 parameters are already documented. The description adds nothing about parameter effects (e.g. that deadlineHours or requiredSkills shape visibility or escrow terms), 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 ('Post a machine-to-machine project to the marketplace') and clarifies the outcome ('Creates an open project with escrow protection'). It is clearly distinct from the escrow and booking siblings, though it never names an alternative tool 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?

'Used by agents to post work they need done' implies the usage context but gives no when-not conditions, prerequisites, or pointers to related tools such as pabandi_start_escrow or pabandi_escrow_lock. The agent must infer whether escrow is set up automatically or requires a separate call.

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 states that this is a check returning 'ok + note,' but it does not describe permission requirements, whether the check has side effects, error behavior, or what the note contains.

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 short clauses with no waste. The action and return summary are front-loaded and immediately scannable.

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 one-parameter tool with complete schema coverage, the description provides the minimum needed to understand the call. However, the return value 'ok + note' is vague and there is no output schema to clarify it.

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 the sole parameter is already fully documented in the schema. The description only restates that the argument is an MCP tool name and adds no syntax or format details beyond the schema's example.

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 operation (check access) on a specific resource (a Pabandi platform tool identified by MCP tool name). It clearly distinguishes this meta access-check from the sibling tools, which perform actual platform actions.

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 does not say when an agent should call this check versus simply invoking the target tool, nor does it mention prerequisites, alternatives, or when not to use it. The intended usage is only implied by the phrase 'Check whether the caller can access.'

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 at all, the description does useful work by disclosing that this makes a real network call to a canonical endpoint and returns the live platform response rather than a cached/stubbed one. It says nothing about authentication requirements, failure modes, or rate limits, so the full behavioral burden for an unannotated tool is not met.

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, front-loaded with the returned payload content and then the purpose, which is the right order. The final sentence about making a real HTTP call is slightly defensive but earns its place as the only behavioral disclosure present.

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 the description compensates reasonably by enumerating the returned fields. However, for a discovery/entry-point tool whose value depends on being reliably found, the absence of any differentiation or cross-reference to the three sibling discovery tools leaves a meaningful 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No misleading parameter claims are made.

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 a concrete resource ('Pabandi Platform discovery doc') and enumerates exactly what the payload contains (tool list, spec URL, PTP endpoint, public key, SDK info). It does not, however, differentiate itself from the near-identical siblings pabandi_discover, pabandi_discover_platform, and pabandi_platform_access, which an agent could easily confuse it with.

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?

'This is the entry point any third-party app, LLM, or agent uses to learn what Pabandi can do and how to call it' gives a clear usage context. But with three similarly named discovery/access siblings in the list, the description never says when to pick this one over them or whether they are aliases, so selection is still partly guesswork.

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: it makes a real HTTP call to the canonical endpoint and returns the live platform response, implying latency and network dependency. It does not state that the call is side-effect-free/read-only, nor any auth or rate-limit constraints, which matters for a prediction endpoint invoked before a write.

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 sentences, front-loaded with the prediction target and scope, then methodology, then return values, then transport behavior. The method sentence (Beta-binomial shrinkage) is borderline but still earns its place by explaining what the confidence figure rests on.

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, and the description compensates by enumerating the returned fields (predictedNoShow, predictedCompletion, confidence, top factors). Combined with the transport note, an agent has enough to call and interpret it; only the read-only/security posture is left implicit.

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 all three parameters are already documented, making 3 the baseline. The description adds some meaning by naming the features derived from reservationTime (lead-time, day-of-week) and the customer/business history blend, but it does not clarify formats or constraints beyond 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 ('Forward-predict the no-show and completion probability') and scopes it to a PROSPECTIVE booking, explicitly noting it runs before creation, which separates it from pabandi_book_stay. However, it never mentions pabandi_predict_demand, the sibling most likely to be confused with 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 only implied: 'before it is created' and 'the predictive intelligence the trust rail uses' suggest a pre-booking risk check. There is no explicit when-to-use / when-not-to-use rule and no stated alternative for predicting demand or scoring an existing booking.

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?

Since no annotations are provided, the description bears the full burden of transparency. It explicitly mentions the data source (completed reservation history), the 'Owner-gated' requirement, and that it is a live HTTP call to the canonical endpoint, providing critical operational context.

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 highly efficient, using three concise sentences to cover the WHAT, WHY, and HOW (gating/endpoint behavior) in a logical flow, adding zero unnecessary fluff.

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 that the tool provides a specific business outcome (24 hourly buckets) and operational constraints (Owner-gated, live API call), the definition is functionally complete for an AI agent to attempt a call 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?

With 100% schema coverage, the schema already fully documents the required 'businessId' parameter. The description adds no further semantic value regarding the input format or meaning beyond what is structured.

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 explicitly states the function (return 24 hourly demand buckets), the source data (completed reservation history), and the ultimate goal (pricing/staffing optimization). It is a highly specific forecasting 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?

It clearly defines the tool's use case—optimizing pricing/staffing—which implies when it should be used. The 'Owner-gated' status is a crucial usage context, although it does not explicitly list alternative tools for demand prediction.

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 load and does reasonably well: it discloses the access control ('Owner-gated'), the ranking/load-balancing behavior that shapes results, the result cardinality (top 3), and that a real HTTP call to the canonical endpoint is made. It stops short of stating that the call is read-only and non-mutating, which is the main 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?

Front-loads the purpose and scoring logic before the access and transport notes. The final sentence is somewhat boilerplate ('real HTTP call ... actual platform response') and partly restates itself, but it does convey genuine behavioral 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?

With no output schema, the description usefully spells out the return shape (top 3 slots with predicted completion and demand), so an agent knows what comes back. For a three-required-parameter tool it is nearly complete, missing only error/empty-result behavior and confirmation that the operation does not mutate state.

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 schema already documents all three parameters, making 3 the baseline. The description adds only 'for a guest,' which loosely maps customerId to a guest user, and nothing about daysAhead's format or what happens when the guest 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?

Names a specific verb+resource ('Recommend the best upcoming slots for a guest at a business') and adds the scoring method (predictedCompletion) and load-balancing, which separates it from siblings like pabandi_predict_demand. It never names an alternative tool explicitly, so sibling differentiation is implied 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?

'Owner-gated' signals a prerequisite, and 'for a guest at a business' implies the post-discovery booking flow, but nothing states when to prefer this over pabandi_predict_booking or pabandi_predict_demand, nor that pabandi_book_stay is the natural follow-up. Usage is inferable rather than instructed.

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 more burden, and it usefully discloses that MaxAmount, Expiry, and AllowedContracts caveats are verified before locking. It also states the return values, escrowId and remaining delegation budget, but it omits permissions, failure behavior, and reversibility details relevant to a fund-locking mutation.

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 three tightly written sentences with the main action and prerequisites front-loaded. Every sentence adds relevant information without 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?

Given a mutation tool with no annotations and no output schema, the description does well to mention caveat verification and return values. Still, it leaves out sibling selection guidance and mutation safety details such as permissions or what happens when caveat verification fails.

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 the baseline is 3. The description adds a little context, such as delegationId coming from a prior grant and amount being required, but it does not materially extend the semantics already provided by 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?

The description clearly states the specific action: lock funds in escrow using an ERC-7710 delegated budget. It distinguishes this from a generic escrow by naming the delegation mechanism, though it does not explicitly differentiate from siblings such as pabandi_escrow_lock or pabandi_start_escrow.

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 prerequisite context by stating the tool requires a delegationId from a prior grant and an amount. However, it does not say when to use this tool versus escrow-related siblings like pabandi_escrow_lock, pabandi_start_escrow, or pabandi_escrow_create_child.

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 more burden, and it does disclose the returned fields and the trust-to-priority relationship. However, it does not explicitly state that the operation is read-only, what permissions are required, or how errors 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 compact sentences with the core purpose front-loaded. The second sentence adds useful interpretation of the trust relationship, though it slightly repeats the earlier session-limits mention.

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, the description adequately explains the return shape and the trust-based meaning. It could still note prerequisites or read-only status, but the essential context is present.

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% for the single passportId parameter, so the schema already describes it as a Trust Passport/agent ID. The description adds no additional syntax, format, or constraint information beyond the schema's own 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?

States a specific verb and resource: getting an agent's scheduling priority based on trust score. It also previews the return contents (tier, session limits, actions, match priority weight). It does not explicitly differentiate itself from sibling trust/passport tools, 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?

The description implies the tool is tied to trust score, but it never says when to call this versus siblings such as pabandi_trust_resolve or pabandi_verify_passport. There are no exclusions, prerequisites, or alternative-selection 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 exist, so the description carries the full burden. It usefully discloses dedupe behavior, that results are never empty, and that a live HTTP call is made (implying latency/network dependence), but omits permissions/auth, rate limits, result caps, pagination, and failure 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?

The first sentence is well front-loaded and does real work. The closing two sentences are largely promotional/meta assurance ('real, deduped results — never empty', 'makes a real HTTP call to the canonical Pabandi endpoint') and dilute an otherwise tight definition.

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 should say at least roughly what a listing contains and what limits apply. It mentions the Passport trust score as a result attribute, which helps, but result shape, paging, and non-match behavior remain 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 description coverage is 100%, so the schema already explains all four parameters and the baseline is 3. The description only reinforces that search spans name/category/city/location and that lat/long are geolocation inputs; it adds no format, matching, or combination semantics (e.g., whether search AND category are conjunctive).

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 ('Search verified businesses and services') and enumerates the matching dimensions (name, category, city, location). It does not distinguish itself from overlapping siblings such as pabandi_discover or pabandi_discover_platform, which an agent could easily confuse with a business 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?

Usage is implied by the search framing, but there is no explicit statement of when to use this versus pabandi_get_business (single lookup) or the two pabandi_discover tools. With ~19 siblings, the absence of any routing guidance leaves real ambiguity.

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 behavioral burden. It usefully discloses that settlement is optional and that a settlement summary is returned, but it omits whether closing is irreversible, what happens to associated bookings or escrow, and what error conditions exist for an already-closed session.

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 filler, and the core action is front-loaded ahead of the optional behavior. Nothing is wasted, though it is arguably too terse given the mutation involved.

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 mutating tool with no annotations and no output schema, the description covers the action and the return value at a high level. It still leaves gaps on irreversibility, failure modes, and downstream effects, which matter more here than for a read-only 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 coverage is 100%, so both parameters are already documented. The description reinforces the `settle` flag's meaning ("optionally settle remaining funds") but adds no format or constraint detail beyond the schema's own text; 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 names a specific verb and resource ("Close an open session") plus the optional settlement side effect, so the purpose is clear without opening the schema. It does not explicitly distinguish itself from siblings like pabandi_session_list or pabandi_cancel_booking, but the name-plus-description 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?

"Close an open session" implies the session must be open, but the description states no preconditions, no guidance on when to use this versus pabandi_cancel_booking or pabandi_session_receipts, and no exclusions. An agent must infer usage entirely.

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 return shape ("sessions with balances and status") and implies a read-only list operation. However, it says nothing about authorization requirements, whether results are paginated or limited, ordering, or what happens when the owner has no sessions.

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, zero redundancy: the scoping constraint comes first and the return contents second. Nothing here is padding.

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 a fully documented schema and no output schema, this is close to sufficient: function, scope, and return contents are all covered. The remaining soft spot is result-set size behavior (whether "all" is truly all or default-limited).

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 ownerType enum documents the two accepted values, so the schema already does the heavy lifting. The description's "(user or agent)" merely restates the enum rather than adding semantics such as ID format, case sensitivity, or behavior for an unknown owner 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?

The description states a specific verb and resource ("List all sessions") plus the scope ("opened by an owner (user or agent)"), which an agent can distinguish from siblings like pabandi_session_close or pabandi_session_receipts. It is clear, though it does not explicitly name a contrasting 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 owner-scoping requirement rather than stated: the agent infers it must supply an owner to retrieve that owner's sessions. There is no explicit guidance on when to pick this over pabandi_get_ledger, pabandi_session_receipts, or pabandi_escrow_balance, all of which surface related financial state.

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 omits key traits: read-only safety is only implied, and there is no mention of pagination even though the schema caps results at a default of 50. The phrase 'Returns the full spend history' is actively misleading against that 50-receipt default, and there is no output schema to compensate.

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 scope; nothing is padded. The second sentence ('Returns the full spend history') is largely redundant with the first and is where the inaccuracy creeps in.

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 two-parameter read tool this is close to sufficient, since the schema documents both inputs. But with no annotations and no output schema, the description should have clarified pagination/truncation behavior rather than asserting a 'full' history.

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%, with both sessionId and limit documented including the default of 50, so the baseline is 3. The description adds no meaning beyond the schema and in fact conflicts with the limit semantics by promising the 'full' history.

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 all receipts (spend records) for a session') and even glosses the domain term 'receipts' as spend records. It does not explicitly differentiate itself from adjacent ledger/finance siblings such as pabandi_get_ledger or pabandi_list_finance, which an agent would likely hesitate between.

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 tool is scoped 'for a session', so an agent can infer it is the per-session spend view. There is no statement of when to prefer it over pabandi_get_ledger or pabandi_list_finance, and no prerequisites or exclusions 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 at all, the description carries the full burden and does add real value: it discloses the permission gate, that these are real on-chain writes on Solana and BSC contracts, and that the call makes a real HTTP request returning the platform response. However, it says nothing about irreversibility, what happens on failure, idempotency, gas/fee implications, or who signs — critical gaps for a money-moving mutation.

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 operation is front-loaded well in sentence one, but the remaining text repeats the same gating claim three times ('GATED to exclusive platform access', '[exclusive] Exclusive...', 'This is the premium moat — the real rail, gated') and includes marketing copy that carries no operational information. Roughly half the description 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?

A five-required-parameter chain-mutating tool with no annotations and no output schema needs the description to cover returns and side effects; instead it only says it 'returns the actual platform response', which is effectively unspecified. The gating and lifecycle are covered, but an agent cannot predict whether it gets back a contract address, a tx hash, or an error on insufficient trust band.

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 the schema already documents all five required parameters (chain enum SOL|BSC, smallest-unit amount, addresses, reservation id). The description's flow language ('business deposits, guest/host holds collateral') loosely maps businessAddress/payoutAddress to roles, but adds no format, unit, or validation detail beyond the schema. 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 opening sentence gives a specific verb and resource ('Initialize a milestone-based or native SOL/BSC escrow for a booking') plus the lifecycle (deposit, collateral hold, release). It also distinguishes the real-chain rail from the 'simulated escrow path' used by verified-only stays, so an agent can tell it apart from the finance/booking siblings. It stops short of naming the specific sibling that handles the simulated path.

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?

States an explicit prerequisite gate (verified PTP trust band A/B or an exclusive platform grant) and an explicit exclusion ('Verified-only stays use the simulated escrow path'), which is exactly the when/when-not signal an agent needs. It doesn't name which sibling tool implements the simulated alternative, so routing is left partly 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses required inputs and that the tool returns the case id and status, but it omits permissions, irreversibility, side effects, adjudication lifecycle details, and error behavior for opening a case.

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 three sentences with no wasted text. It is front-loaded with the action and outcome, then lists required and optional inputs, then states the return values.

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 that there are no annotations and no output schema, the description is minimally complete: it names the inputs and says the tool returns a case id and status. However, for a case-opening mutation it lacks important context about side effects, permissions, and how this tool relates to pabandi_get_adjudication_status.

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 the schema already documents all four parameters. The description adds that oracleData is optional and reconfirms sellerProof as an IPFS/content hash, but it does not explain the EvidenceBundle structure or buyerClaim format beyond what the schema provides, making the baseline 3 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?

The description states a specific verb and resource: submit an EvidenceBundle to open an Internet Court adjudication case. It is clear what the tool does, but it does not explicitly differentiate itself from the sibling status-checking tool pabandi_get_adjudication_status.

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 'to open an Internet Court adjudication case' implies the usage context, but there is no explicit when-to-use guidance, prerequisites, or named alternatives. An agent can infer that this is the dispute-opening action, but must infer that from the description rather than being routed to 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?

No annotations are provided, so the description carries the behavioral burden. It implies a read operation by saying 'Resolve' and 'Returns,' and it lists key return fields, but it does not explicitly state side-effect safety, permissions, rate limits, or 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?

Two tightly written sentences with no wasted wording. The core action and return fields are front-loaded, followed by the use case.

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 read tool with full schema coverage and no output schema, the description is mostly complete. It names the returned fields, but it could say more about what tier values mean or what happens when resolution fails.

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 the schema already documents both parameters. The description mentions resolving a passport/agent and returning a capability band, but it adds no meaningful semantics beyond the schema, especially for the optional 'need' 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?

States a specific verb and resource: resolve trust score and reputation for a passport/agent. It also clarifies the intended use for evaluating counterparties, though it does not explicitly differentiate from siblings like pabandi_verify_passport or pabandi_verify_trust_attestation.

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?

Gives a clear usage context: agents should use it to evaluate counterparties before transacting. It lacks explicit when-not guidance or named alternatives, so it falls short of a full 5.

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 disclosure burden. It does usefully disclose the paid nature of the call ('Price: $0.01 USDC') and the shape of what comes back, but says nothing about whether the call fails or returns a neutral result for an unknown or unverified passport, nor about any auth or rate 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?

Three short sentences, front-loaded with the action and result, followed by the usage condition and the price. The phrase 'to assess reliability' is mildly redundant with 'trust score', but there is no padding worth cutting.

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, non-destructive read with no output schema, the description covers purpose, trigger, return fields, and cost. The main residual gap is failure/edge-case behavior for an unknown or unverified passport, which matters given the per-call fee.

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 parameter with 100% schema description coverage, so the baseline is 3. The description adds only the framing that the ID belongs to a 'human trust passport' rather than an agent passport, which is a marginal but real semantic contribution beyond the schema 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 and resource ('Verify a human trust passport') and names the payload of the response (trust score, tier, verification status). It implicitly scopes to humans ('any human counterparty'), which hints at a distinction from the agent-facing pabandi_verify_passport sibling, but it never names that sibling outright.

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?

Gives a clear trigger condition: call it before booking or transacting with a human counterparty. It does not state when NOT to use it, nor does it route the agent to pabandi_verify_passport, pabandi_check_counterparty, or pabandi_verify_trust_attestation, which occupy adjacent ground.

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 disclosure burden. It does add real value by naming the return fields (valid, grantedCapabilities, riskBand, expiresAt) and stating "Works offline", but it is silent on failure behavior (invalid/expired token), whether verification is side-effect-free, and any rate or freshness 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?

One tight paragraph that front-loads the verb and resource, then inputs, then returns, then the offline trait and a concrete example. Dense with no filler, though the trailing example duplicates the schema sample and makes the block slightly run-on.

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 correctly compensates by enumerating the returned fields, and it documents both inputs, so an agent can invoke it confidently. The gap is negative-path behavior (invalid or expired attestation) for a verification tool with no annotations 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 coverage is 100% and both properties are documented, so the schema already carries semantics. The description restates token as base64-encoded and need as an example capability without adding format, encoding, or failure semantics beyond the schema; 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?

Specific verb+resource: "Verify a Pabandi PTP attestation" with the subject types it covers (agent/business/individual/trust rail). However, it does not distinguish itself from the sibling pabandi_verify_trust_attestation, which reads like the same class of operation, leaving the agent to guess which verifier applies.

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 example ({"token": ..., "need": "act:book"}) and by noting the optional need gate, and "Works offline" hints at when this is preferable. But there is no explicit when-to-use/when-not statement and no named alternative despite a near-duplicate verify sibling.

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 discloses meaningful behavior: it re-executes an HMAC-SHA512 signature over a fixed field subset, returns 'valid' plus verified claims, and makes a real HTTP call to the canonical endpoint. It omits auth requirements, failure modes, and rate limits, which keeps it from 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?

The purpose and mechanism are front-loaded, and most sentences earn their place. The last sentence ('makes a real HTTP call... actual platform response') partially restates the preceding offline-verifiable point, costing a bit of tightness.

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 the description compensates by stating the return shape ('valid + the verified claims'). For a one-parameter verification tool with no annotations, this is nearly complete; only permission/auth context 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 coverage is 100% for the single required 'token' parameter, so the schema already documents the format (base64-encoded PTPAttestation). The description adds no further detail about the token, and the schema's 'optional: need=capability to gate on' note is not clarified anywhere. 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?

The description names a specific verb and resource ('Verify a Pabandi PTP attestation') and enumerates the four attestation types it covers. It does not differentiate itself from the sibling pabandi_verify_passport, which shares the 'verify' verb, so it stops short of full sibling disambiguation.

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 implies usage by calling itself 'the trust primitive every third-party action gates on', suggesting when an agent should reach for it. However, it gives no explicit when-to-use versus pabandi_verify_passport, and no exclusions or prerequisites.

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 useful runtime behavior: a 'real HTTP call to the canonical Pabandi endpoint', a real Noir circuit compiled at startup, and a degraded 'constraint-execution proof' fallback when no SNARK prover is available. It says nothing about permissions/auth for agent_secret, cost, latency, or whether any server-side state is created by generating a proof.

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 first sentence is well front-loaded, but the text then repeats itself: the purpose is restated in the '[owner]' sentence and the 'upgrades to a succinct SNARK' claim appears twice in nearly identical wording. Roughly a third of the description is redundant rather than additive.

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 an 8-required-parameter tool with no annotations and no output schema, the description names the artifact produced ('PTP attestation ... verifiable offline by any third party') but never sketches what the response actually contains or how failures surface. It is adequate to understand the intent, thin on what the agent gets 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?

Schema coverage is 100%, which sets a baseline of 3, but the description adds the arithmetic relationship the schema cannot express: 'deposit = price - commission, fee = deposit*rate' plus a 'binding commitment to the valuation'. That tells the agent the parameters are coupled and must be internally consistent, which is real meaning beyond the field descriptions.

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: 'Generate a zero-knowledge proof that an escrow split ... is valid', and scopes the privacy guarantee ('WITHOUT revealing the private price/valuation/secret'). It does not, however, distinguish itself from plausible siblings like pabandi_start_escrow or pabandi_verify_trust_attestation, so an agent still has to infer which step of the flow this is.

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 call this rather than pabandi_start_escrow, pabandi_verify_trust_attestation, or pabandi_verify_passport, and gives no prerequisites (e.g. must an escrow exist first?). 'The privacy + verifiability moat' is marketing framing, not routing guidance.

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