ProveCart

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

Annotations only say this is a non-read-only, non-destructive call; the description adds far more: unanswered tasks score as unsafe, the run is sealed and published to the scoreboard, 80.0 is the certification threshold, and an X-API-Key header is required. These are non-obvious consequences an agent could not infer from the annotation flags.

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 and argument shape are front-loaded, and the return format, sealing behavior, and auth requirement follow in a logical order with no filler sentences. The middle sentences are dense and pack several distinct concerns together, which slightly hurts scanability.

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 submission tool with no output schema, the description still describes the response shape (per-task results with instance_id, safe, critical, verdict plus a score) and the success threshold. Combined with the auth note and the unsafe-by-default rule, an agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description earns more by defining the otherwise opaque `decision` object — either a purchase shaped like a check submission without a mandate reference, or {"ask": true}. It also states the omission semantics of `answers`, which the schema does not. The agent_id and session_id parameters get no elaboration beyond the schema, so it is not a 5.

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 and resource: submit decisions for an open exam session and receive a score. It explicitly anchors to the sibling provecart_agent_exam_start as the prerequisite, so an agent can distinguish this terminal submit step from the session-start tool without reading either schema.

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

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

It gives clear context: one entry per task from provecart_agent_exam_start, plus the explicit fallback condition for emitting {"ask": true} when the instruction does not settle the choice. It does not name a when-not-to-use case or what to do if the session is already sealed, so it stops short of a 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?

Annotations only say this is a non-read-only, closed-world, non-destructive operation; the description goes well beyond that by disclosing the 2-hour session expiry, the single graded attempt, the API-key header requirement, and the ownership rule that only the registering key can open the session. Those are exactly the behavioral facts an agent cannot get from the annotations or the one-field schema.

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?

Five short sentences, front-loaded with the action and then the workflow, constraints, and auth, with essentially no filler. The auth sentence is dense but each clause (header name, key source, ownership rule) earns its place; minor trimming could still tighten it.

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

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

For a one-parameter session-start tool with no output schema, the definition covers what happens on call, what the agent receives ('customer instruction and the shopper-facing shelf of buyable options'), the required follow-up, and the session limits — nothing an agent needs to invoke it correctly is missing.

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

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

With a single parameter and 100% schema coverage, the schema already explains agent_id's provenance, so the baseline is 3. The description adds real meaning by tying agent_id to an authorization constraint — 'Only the key that registered the agent can open its session' — which tells the agent that a valid-looking agent_id can still fail.

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 ('Open a live Verified Agent exam session for your agent_id') and immediately distinguishes itself from the sibling it pairs with by saying decisions go through 'one provecart_agent_exam_answer call'. An agent can tell this apart from provecart_agent_exam_answer, provecart_agent_selftest, and provecart_agent_signup without opening a schema.

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

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

Clear context: this starts the graded session, and the following step is explicitly the answer call. It also states the attempt and timing constraints ('one graded attempt per session', 'expires 2 hours after it starts'). It does not explicitly route to alternatives such as provecart_agent_selftest for practice or provecart_agent_register when no agent_id exists, so the when-not side is left to inference.

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

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

Annotations establish write semantics (readOnlyHint=false, destructiveHint=false, openWorldHint=false); the description usefully adds the auth mechanism (X-API-Key header) and the side effect of sealing the registration into an immutable evidence chain, which an agent should know before calling. It stops short of describing failure modes, key-rejection behavior, or idempotency on repeat registration.

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 action and result, then the prerequisite, then the fallback — a sensible order for an agent scanning for callability. There is mild redundancy between 'under an API key you already hold' and the later header requirement, but nothing that obscures the meaning.

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?

Covers the essential things for a two-parameter registration call: what it does, what it returns, what credential it needs, and where to go without one. With no output schema present, the description does name the key return value (agent_id), though it could say more about the rest of the response payload or what happens on duplicate registration.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema; the baseline of 3 applies. The description adds no extra detail about agent_name uniqueness constraints or builder_contact format beyond what the schema fields already say.

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 ('Register an agent for ProveCart Verified Agent certification') plus the key outcome ('returns the public agent_id and seals the registration into the evidence chain'). It also distinguishes itself from the closest sibling by naming provecart_agent_signup as the different 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?

Gives an explicit precondition (caller must already hold an API key, integrator or scoped) and an explicit alternative for the case where that precondition fails ('If you have no key at all, call provecart_agent_signup instead'). The branching condition is unambiguous.

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

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

Annotations only declare readOnly=false, destructive=false, openWorld=false; the description adds the material facts those hints do not convey: the score is published publicly on provecart_scoreboard, the run is scoped to the caller's own registration, and an X-API-Key header is required (integrator key or scoped key from provecart_agent_signup). The public-publication side effect is the key disclosure here. It stops short of saying whether repeated runs overwrite or append to the scoreboard entry, which is the only meaningful behavioral 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?

It is front-loaded with the action, then the mechanics, then the side effect, then auth, then the sibling contrast in a logical order with no filler sentences. It is on the dense side, with stacked parentheticals listing the planted traps, but each clause carries distinct information the agent needs. Slight length cost keeps it from a 5.

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, non-destructive test-run tool with no output schema, the description covers everything an agent must decide before calling: what is tested, what is produced (a score), where it goes (public scoreboard), what credentials are needed, and which alternative exists for certification. Nothing material is left to 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% and the single agent_id property already documents its origin ('returned by provecart_agent_register'), so the schema carries the parameter semantics. The description reinforces this with 'under your registration' and the restriction that only the registering key may run it, but adds no format or validation detail beyond what the schema already provides. 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 first sentence gives a specific verb and resource ('Run the ProveCart Verified Agent self-test') and immediately follows with the concrete mechanics: six fixed test carts containing planted traps, evaluated by the same verification engine as live orders. It explicitly names the sibling that is often confused with it (provecart_agent_exam_start / provecart_agent_exam_answer) and states the distinction, so an agent can pick the right tool without opening schemas.

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 an explicit when-to-use rule ('fixed-set system check') contrasted against the alternative certification path ('the live exam ... which grades your own decisions'), which is exactly the routing guidance needed among these siblings. It also states an access precondition ('Only the API key that registered the agent can run its self-test'), so an agent knows when the call will fail before making 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?

Annotations only declare that this is a non-destructive write; the description adds the material facts an agent needs: the API key is returned once and cannot be re-read, it is scoped solely to the Verified Agent endpoints for your own agent_id, and the call is free. These one-time-secret and scope-limit warnings are exactly the context structured fields cannot convey.

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

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

Front-loaded with the routing condition and otherwise dense with facts. The closing 'Free; no API key required for this call' partly restates the opening sentence, a small redundancy that keeps it from being fully waste-free.

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, yet the description names what comes back (agent_id plus a one-time scoped key) and where to go next. For a two-parameter signup tool with annotations covering safety, nothing needed to invoke it correctly 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% and both parameters carry their own descriptions (including the scoreboard consequence of agent_name), so the schema does the heavy lifting. The prose adds no additional constraints such as uniqueness, length, or naming rules for agent_name, 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: self-serve signup that 'registers your agent and returns your agent_id together with a scoped API key.' The first sentence ('Start here if you have no ProveCart API key') frames it clearly, but the sibling provecart_agent_register is never named or differentiated, so the agent must infer the split between the two registration paths.

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 explicit entry condition ('if you have no ProveCart API key') and a sequencing instruction pointing to provecart_agent_exam_start and provecart_agent_exam_answer as next steps. The complementary case (already holding a key → use provecart_agent_register) is only implied, not 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: it requires no API key, and it discloses what the tool actually returns (an explanation of the certification process, grading, scoring, and publication). It does not say anything about length or format of the returned explanation, which keeps it short of a 5.

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

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

A single front-loaded sentence with the resource and intent stated first, followed by a compact enumeration of covered topics. Slight redundancy between 'how it works' and the colon list that follows, but every listed item corresponds to a real thing the agent will want to know, so almost nothing is wasted.

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

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

For a zero-parameter, read-only documentation tool with no output schema, the description is essentially complete: it tells the agent what questions the answer will address and that no auth is needed. The only gap is that it does not hint at the shape of the response (a textual overview versus structured facts), which matters slightly since no output schema exists.

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 no parameter meaning to add; the baseline for zero-param tools applies. The description correctly does not waste space describing nonexistent inputs.

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

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

The description names a specific resource (ProveCart Verified Agent certification) and a specific intent (learn what it is and how it works), then enumerates the concrete topics covered: keyless signup, live exam grading, score calculation, and score publication. That makes it clearly an informational/overview tool rather than an action tool, which distinguishes it in spirit from siblings like provecart_agent_signup and provecart_agent_exam_start, 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?

Usage is only implied: because it explains 'how to sign up with no pre-issued key' and how the exam works, an agent can infer this should be read before calling provecart_agent_signup or provecart_agent_exam_start. There is no explicit 'call this first' or 'use this instead of X when Y' statement, so the sequencing is left to inference.

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

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

Annotations only say readOnly=false, destructive=false, openWorld=false; the description explains why a 'check' is not read-only — every check leaves a sealed evidence record — and adds auth requirements (integrator API key in X-API-Key), the fact that no money moves, and the three verdict outcomes with what happens on non-MATCH (corrections array, retry budget, evidence pointer). This is materially more than the annotations convey and is consistent with them.

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 action and the timing constraint, then the inputs, then the outcome semantics. Dense but every sentence carries information an agent needs — auth, non-MATCH handling, and the no-money guarantee are all actionable.

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

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

No output schema exists, so the description must carry return semantics, and it does: MATCH/REVIEW/BLOCK meanings, the ACF corrections structure, retry budget, and sealed evidence pointer. Combined with the documented auth header, an agent can call and interpret this tool 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?

Schema description coverage is 100%, so both mandate and mandate_id are already documented in the schema, including the 'provide either' rule. The description's parenthetical enumerating mandate contents (travelers, route, dates, cabin, fare terms, price limit) adds a useful summary but no format or constraint 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?

States a specific verb and resource — 'check a travel booking against the customer's instruction' — plus the decision point ('before the payment is captured or a ticket is issued'). It is clear what the tool does, but it never mentions the sibling tools provecart_check_order or provecart_check_reservation, so an agent must infer which 'check_*' applies to which object.

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

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

Gives explicit timing guidance ('Call this before paying or ticketing') and the two input modes (inline mandate vs mandate_id). It does not state when to prefer this over the sibling check_order/check_reservation tools, which is the one routing gap.

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?

Explains what the annotations cannot: why this is not read-only (every check leaves a sealed evidence record), the three verdict semantics with per-branch instructions, the ACF correction payload and retry budget, and the trust boundary ('never holds or moves money'). It also discloses the auth requirement (X-API-Key header), which is exactly the kind of operational context an agent needs before calling.

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, then the call conditions, then verdict handling — a sensible ordering with little filler. The ACF spec URL and evidence-record asides are slightly dense, but each conveys information the agent needs to act on a non-MATCH response.

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

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

There is no output schema, so the description carries the return-value burden — and it does, naming all three verdicts and the structure of non-MATCH responses (dimension, action, expected, actual, reason plus evidence pointer). Combined with the stated auth requirement, an agent has everything needed to call and react 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?

Schema coverage is 100%, so the baseline is 3; the description earns an extra point by explaining the either/or relationship between 'mandate' and 'mandate_id' and summarizing what a mandate encodes (item, price limit, merchant rules). It says less about the cart sub-fields, but those are already documented 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 — check a shopping cart against the customer's mandate before payment capture — and makes the temporal scope explicit ('before completing a purchase'). It is clearly separable from siblings like provecart_check_booking and provecart_check_reservation, which operate on different resources.

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 ('Call this before completing a purchase') and spells out what to supply in each of the two modes. It doesn't explicitly contrast itself with the sibling check_* tools, but the resource difference makes the choice obvious, so this is clear context without formal 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?

Adds substantial behavior beyond the annotations: the three verdicts and what each implies, the Agent Correction Format for non-MATCH responses, the retry budget, the sealed evidence record, the no-money-movement guarantee, and the required X-API-Key header. The change is limited by one gap: it does not reiterate that non-MATCH responses should not be silently retried past the budget beyond a brief mention.

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

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

Information is front-loaded: purpose first, then call timing, inputs, and return semantics. Dense but every sentence carries operative content, though the ACF specification link and the collection of format details make it longer than necessary for a three-parameter tool.

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 fully accounts for return values (verdicts, corrections array, evidence pointer) and covers the authentication requirement, so an agent can invoke the tool correctly without further documentation. Nothing material is missing for a validation-only 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?

Clarifies the either-or relationship between 'mandate' and 'mandate_id' and enumerates the semantically important mandate fields (provider, location, date, time, party size, deposit and total limits, cancellation terms), helping an agent understand what must be carried over from the customer instruction. Schema descriptions already document both fields, so the description leaves most of the remaining field-level details to 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 ('Check a service reservation against the customer's instruction before the payment') and scopes it to reservations, which separates it from the sibling check_booking and check_order tools. It also declares the output contract (MATCH/REVIEW/BLOCK), so an agent knows exactly what the call produces.

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 clear timing guidance ('Call this before confirming a reservation') and explains the two mutually exclusive input paths (inline mandate vs. mandate_id). It never explicitly contrasts itself with the similarly named sibling checks (check_booking, check_order) or states when not to call it, so it stops short of full routing 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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the description rightly spends its words elsewhere: it discloses that the listing is public, requires no API key, excludes agents that never completed a test, and shows only the latest run's score. It doesn't mention pagination or result-set size, which is a minor gap for a listing 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 sentences, front-loaded with the resource and followed by the returned fields and eligibility rule. The parenthetical enumeration of the three test types is slightly verbose but clarifies the completeness rule, so it earns its place.

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

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

There is no output schema, so the description carries the burden of describing return values, and it does: latest score, number of checks, and last-tested time. Combined with the eligibility rule and the no-key note, an agent has enough to decide to call it and interpret results; only ordering/pagination is 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?

The tool takes zero parameters, so there is nothing to disambiguate; the baseline of 4 applies. The description correctly spends no space on inputs and instead describes what the listing contains.

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 ('Read the public ProveCart Verified Agent scoreboard') and immediately narrows scope to 'every agent that has completed a test', listing the three test types. An agent can tell this is a public read of published results, distinct from the sibling action tools (exam_start, selftest, register).

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?

Implies usage (view published scores after an agent is tested) but never says when to call this versus alternatives, notably the sibling provecart_certification_info or provecart_check_* tools. No explicit when-not guidance, so selection relies on inference from the name and sibling names.

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