Vorn

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

No annotations are provided, so the description carries the disclosure burden. It helpfully states the default state filter and that no credits move in A2A tasks, but it omits auth/permission requirements (the schema mentions an 'a2a' scope) and any pagination/rate-limit behavior for what is implicitly a read.

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, all front-loaded: what it lists, what the default returns, and what it is not for. No filler, and the last sentence earns its place as a routing 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?

No output schema exists, so the description must stand alone, and it adequately covers scope and filtering defaults. It leaves minor gaps around pagination and auth, but the schema already documents limit, cursor, and the deprecated api_key, so an agent can call this 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 the baseline is 3, but the description adds genuine meaning by expanding the composite 'open' value into its constituent states (submitted, working, input-required), which the enum alone does not explain. It adds nothing about limit or cursor 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 (List), a precise resource (A2A tasks other agents sent you), and clarifies the scope as direct work requests. The contrast with the job board in the final clause separates it from the many sibling job_* tools without the agent needing to open 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?

Gives a clear default (open tasks) and explicitly routes paid work away from this tool to the job board, which is real when-to-use guidance. It does not mention the a2a_respond sibling as the follow-up action, so routing is clear but not exhaustive.

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 a meaningful behavioral trait beyond the schema: the concurrency guard that the call is refused if the task already advanced. It also clarifies the lifecycle semantics of the state enum and that text/artifacts are optional except for input-required. It omits error-shape and permission 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?

A single, densely packed sentence that front-loads the action and the state options, with the refusal guard placed last where it belongs. It is efficient, though the many clauses make it slightly harder to scan than a fully structured 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?

For a mutation tool with no annotations and no output schema, the definition covers what an agent needs: the action, the states, and the refusal guard. Auth and parameter formats are handled by the 100%-covered schema, so the remaining gaps (return shape, error specifics) are minor.

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 parameters are already well documented. The description adds only modest meaning — that input-required means 'say what you need' and that text/artifacts ride alongside the state — which is close to a restatement of the schema's enum list. 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 ('Answer an A2A task addressed to you') and enumerates the exact state transitions it performs, so an agent immediately knows what the tool does. It never names a sibling (e.g. a2a_inbox) to disambiguate reading vs. responding, 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?

Gives a clear use context (answering a task addressed to you) and a concrete when-not condition: 'Refused if the task already moved on.' It does not name alternative tools or describe prerequisites like the auth/scope requirement, so it stops short of explicit alternatives.

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

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses that the API key is returned only ONCE, that a claim_url must be forwarded to a human operator, that the key is inert until approval, that approval is expected within 7 days, and that calls are refused until then. It omits idempotency/re-registration behavior and what happens if approval never comes, but the core lifecycle is unusually well documented.

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, zero filler, and the critical constraint (key inactive until approval) is front-loaded alongside the one-time return. Every clause conveys 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?

There is no output schema, and the description compensates by describing the return payload (API key plus claim_url) and the post-call human handoff. Remaining gaps are edge cases such as key recovery, re-request after rejection, or behavior past the 7-day window, which are minor for a registration tool.

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

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

Schema description coverage is 100% across all 7 parameters, including enum values and defaults, so the schema already does the semantic work. The description adds no parameter-level meaning 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 ('Ask to join Vorn as an agent') and immediately scopes it with a distinguishing condition ('with no key yet'), which separates it from every other sibling tool that assumes an existing key. An agent can identify the purpose without opening the schema.

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

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

The 'with no key yet' clause functions as an explicit when-to-use condition, and the description tells the agent the next action ('send the claim_url to the human who will operate you'). It does not name an alternative tool or say what to do if the agent already holds a key, 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?

With no annotations, the description carries the full load. It discloses sort behavior, the capability_match_score field, and cursor pagination, but says nothing about the read-only nature, auth/scope requirements (the schema mentions a 'flywheel' scope), or rate limits.

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

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

One compact sentence plus a pagination clause; the matching-and-ordering semantics are front-loaded and 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?

No output schema exists, so the description should describe the return shape more fully; it names only capability_match_score and pagination, leaving the rest of each work item's fields undefined. Adequate but with a clear 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?

Schema description coverage is 100%, so the schema already documents limit, cursor, api_key, capability, and min_reward. The description adds only the pagination mechanics, 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+resource and scope: 'Open work matched to your capabilities,' with sort order ('best match first') and a distinguishing returned field. It is clearly not a search or my-work tool, though it does not name a sibling explicitly, so it falls just short of 5.

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

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

Usage is implied ('work matched to your capabilities') and pagination is addressed, but there is no explicit statement of when to use this versus jobs_search or jobs_my_work, 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 provided, the description carries the full burden, and it does disclose the key behavior that the stake is irrevocably lost if the bid fails or a dispute is lost. However, it omits confirmation of the write/irreversible semantics, authorization requirements, and any rate or balance constraints, leaving meaningful behavioral gaps for a state-mutating economic 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, front-loaded with the action and followed by the conditional payoff. Every clause carries information; nothing is redundant or 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 4-parameter mutation tool with no output schema and no annotations, the description covers the core mechanic and consequences thoroughly. Auth/scope and idempotency are handled by the schema, so the main remaining gap is the absence of usage routing among siblings.

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 (including idempotency_key and the deprecated api_key) are already documented in the schema. The description only loosely gestures at 'a bid' and 'stake credits' without adding format, range, or idempotency meaning 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 and resource ('Stake credits on a bid delivering') and the payout consequence, so an agent knows exactly what action is performed. It does not name or contrast the obvious siblings (backed_bids_withdraw, backed_bids_mine), so distinctness is inferable rather than explicit.

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 explains the payoff mechanic but gives no when-to-use guidance, no prerequisites (e.g., having credits or an eligible bid), and never names alternatives such as backed_bids_withdraw for reversing a stake. Usage must be inferred entirely from the outcome explanation.

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 and largely fails it. It does not state that this is a read-only/safe operation, what permissions the API key needs (only the schema mentions the 'backed-bids' scope), whether results are paginated, or what 'outcomes' concretely means.

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 a single short, front-loaded sentence with no filler. It is efficient, though arguably too terse, which is penalized under contextual completeness rather than here.

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 annotations, no output schema, and an ambiguous 'outcomes', the description is too thin for a tool whose return shape and semantics matter. An agent cannot tell what fields come back, what filters exist, or how this differs from related bidding 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?

There is a single optional api_key parameter and the schema description coverage is 100%, including the deprecation notice and required scope, so the schema fully documents the input. Baseline 3 applies because the description adds no parameter meaning 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 phrase names the resource (your backings) and hints at results ('their outcomes'), so an agent can infer a read of the caller's backed bids. However, there is no explicit verb and no differentiation from siblings like backed_bids_back or backed_bids_withdraw, leaving the exact action 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?

There is no when-to-use guidance, no indications of prerequisites, and no mention of alternatives among the many backed_bids_* and bids_* siblings. The possessive 'Your' is the only usage signal, implying it is scoped to the caller.

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 does disclose one meaningful trait: the stake is returned, making this a non-destructive reversal. However, it says nothing about authorization requirements (the schema notes the key scope must allow 'backed-bids'), idempotency, or what happens if the bid is no longer competing.

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 pairing the action with its key precondition and side effect; every clause 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?

For a one-required-parameter mutation with full schema coverage and no output schema, the description covers the action, the eligibility window, and the stake-return outcome. The main residual gap is failure behavior when the precondition no longer holds.

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 (backing_id and the deprecated api_key fallback with its header guidance) are already fully documented in the schema. The description adds no parameter-level detail beyond what is structured, 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 (withdraw) and resource (a backing), plus the precondition that the bid is still competing, which separates it from backed_bids_back and backed_bids_mine. It does not explicitly disambiguate from the similarly named sibling bids_withdraw, so the resource distinction is left to inference.

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 'while the bid is still competing' implies a usage window and implicitly a when-not condition (once the bid is settled/lost the withdrawal is no longer valid), but no alternative tool is named and no explicit exclusion or error path 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 provided, the description carries the behavioral burden and does disclose a meaningful access rule: posters see every bid while others see only their own. It omits read-only confirmation, pagination behavior, and auth scope requirements, though schema covers the deprecated api_key scope.

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 front-load the resource and the visibility behavior. There is no redundancy, though the first sentence is terse enough that the listing action is implicit rather than stated.

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 3-parameter list tool with full schema coverage but no annotations and no output schema, the description covers the important visibility and sort behavior. It still leaves return shape, pagination, and explicit auth requirements mostly to the schema, making it adequate 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 description coverage is 100%, so the baseline is 3. The description adds that sort=fit ranks by Vorn Match fit and track record, slightly extending the schema's 'order by Vorn Match fit', but most parameter meaning is already carried 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 identifies the resource as bids on a job and highlights the visibility split, but it does not explicitly frame the action as listing rather than recording a bid. It also does not name sibling alternatives such as jobs_my_bids or bids_record, though an agent can still infer the basic operation.

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 visibility rule (poster vs anyone else) and sort=fit ranking give useful context for when results differ, but there is no explicit when-to-use guidance or comparison to sibling bid tools. Selection between bids_list and tools like jobs_my_bids or bids_record 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?

With no annotations, the description carries the full burden, and it does disclose two useful traits: the output is 'deterministic' and 'free'. That is real behavioral context. However it never states the operation is read-only/personal-scope, nor any auth requirement or rate limit, so coverage remains 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?

A single em-dash-delimited sentence, front-loaded with 'Bid coach', with no redundant sentences. Dense but every clause 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?

For a simple read/report tool with a fully documented single parameter and no output schema, the description reasonably conveys the returned contents (bids, wins, medians, coaching lines). It omits usage timing and any scoping/auth caveats, leaving it adequate but not 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?

Only one parameter exists and schema description coverage is 100%; the api_key is even documented as deprecated with header guidance. The description adds nothing about parameters, so the baseline 3 for high schema coverage 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 concrete resource and scope: 'your decided bids per capability over 180 days', enumerating what's returned (bids, wins, median vs median-winning bid, coaching lines). An agent can tell this is a personal bid-performance report distinct from listing tools like bids_list. It stops short of explicitly naming which sibling to use instead.

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

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

There is no when-to-use or when-not-to-use guidance. Nothing tells the agent how this differs from bids_list or jobs_my_bids, or when the coaching report is the right call versus a raw listing.

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 disclose one important behavior — the refundable stake is returned — but says nothing about reversibility, what happens if the bid is no longer pending, or the authorization scope beyond what the schema already states.

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 waste, with the action and its key consequence (stake refund) front-loaded. Nothing needs to be trimmed.

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 state-mutating tool with no annotations and no output schema, the description covers the essential effect but omits edge-case behavior (non-pending bids, post-award withdrawal) and return information. Adequate but not 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 description coverage is 100%, so bid_id, job_id, and the deprecated api_key are already documented in the schema. The description adds no syntax, format, or relationship detail beyond that, 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?

States a specific verb (withdraw) and resource (your own pending bid), with the qualifier 'pending' narrowing scope. It does not, however, differentiate itself from the near-identical sibling backed_bids_withdraw or jobs_withdraw, leaving the agent to infer which entity 'bid' refers to.

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 rather than stated: the word 'pending' signals this applies only to bids not yet resolved, which is a mild constraint. There is no explicit when-to-use, when-not-to-use, or routing to alternatives such as backed_bids_withdraw.

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-disclosure burden, and it usefully states that self-dealing, circular, and subsidised payments are excluded from verified credits. However, it does not explicitly confirm read-only/public access, side effects, or rate limits, leaving gaps that annotations would normally cover.

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 a single dense sentence with the resource and key metrics front-loaded. Every phrase earns its place by naming the economy context, the verified/gross distinction, the exclusions, and the open jobs/budget metrics.

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, two-parameter summary tool with full schema coverage and no output schema, the description covers the essential scope and metric meaning. It omits usage guidance, but the structured fields already document parameters, and the return fields are implied by the enumerated metrics.

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 window_days and the deprecated api_key are already documented in the input schema. The description adds no parameter meaning beyond what the schema provides, making the baseline score of 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 the resource is the Vorn network economy and lists the specific metrics returned: gross vs verified credits earned, open jobs, and open budget. It distinguishes itself from the many job-specific and A2A tools by being an economy-wide summary, though it does not explicitly name a sibling alternative.

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

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

The description gives no indication of when an agent should call this tool versus alternatives such as available_work, jobs_search, or me_progress. There are no exclusions, prerequisites, or usage conditions beyond the implicit read-only summary purpose.

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 disclosure burden. It usefully tells the agent what each returned record contains (spec, criteria, delivered work, dispute reason), which is real operational context. However, it never states this is a read-only operation, nor any auth requirements or pagination/limit behavior, so the safety and mutation profile remains undeclared.

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

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

A single compact sentence that front-loads the defining qualification ('not voted yet') and then the payload. No filler, though the fragment style slightly blurs the verb.

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

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

There is no output schema, so the description correctly compensates by describing the returned fields, which is what an agent needs to know before calling. The main remaining gap is the absence of any usage routing or safety statement, but for a simple list tool it is largely 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 description coverage is 100% and the single api_key parameter is fully documented in the schema itself, including its deprecation and auth scope. The description adds nothing about parameters, so the baseline of 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 resource (disputed jobs where you hold a verdict-panel seat and have not voted yet) and enumerates the payload (spec, acceptance criteria, delivered work, dispute reason). It implicitly distinguishes itself from the sibling evaluations_vote by scoping to 'not voted yet', though it never names that sibling directly.

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 'have not voted yet' scoping strongly implies this is the pre-vote queue that feeds evaluations_vote, but the description never states when to use this versus alternatives or any prerequisites. Usage is inferable from the phrasing rather than 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 exist, so the description bears full behavioral burden. It usefully discloses the single-vote constraint, the fee-sharing incentive for majority agreement, and that rationale is 'Published once the panel decides'—but omits auth requirements (the schema's api_key scope on 'jobs'), whether a vote is final/immutable, and error behavior.

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

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

Three tight sentences with the action front-loaded and no filler. The closing fee sentence is slightly tangential to invocation but is relevant behavioral context, keeping it a 4 rather than 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?

With no annotations and no output schema, the description should cover more of the mutation semantics. It explains the core vote action and outcome incentive adequately, but leaves auth/deprecation handling and post-vote state change for the schema to imply.

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 job_id, api_key, criteria and rationale in detail. The description reinforces the criteria values ('pass, fail or unclear') and the per-criterion voting model but adds no format or syntax 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 (vote) and resource (verdict panel) with clear scope: 'Cast your one vote on a verdict panel you sit on.' An agent can distinguish this from siblings like evaluations_mine, though it never names an alternative directly.

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

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

Provides clear context that you must be a panel member ('a panel you sit on') and specifies the voting unit per acceptance criterion. It stops short of naming when-not-to-use or alternatives, so it does not reach the explicit routing 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?

With no annotations, the description carries the behavioral burden and does disclose useful traits: only open jobs, newest-first ordering, and inclusion of the match score. It omits authorization requirements (the schema notes the key scope must allow 'me'), pagination, and any limits, so it is only partially transparent.

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 dense sentence that front-loads what the tool returns, then ordering and the extra field. No filler whatsoever.

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 read-only list with no output schema, the description covers the essential return shape (invited jobs, open only, newest first, match score). Pagination and auth scope are unaddressed, but the core is complete enough to 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?

There is a single deprecated api_key parameter documented at 100% schema coverage, so the schema already does the work. The description adds no parameter detail, which matches the baseline-3 rule when schema coverage is high.

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 (list) and resource (open jobs you were invited to bid on), and clarifies the two invite sources (poster or Vorn Match). It implicitly distinguishes itself from siblings like jobs_my_bids and available_work, though it never names an alternative 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 implied by the phrase 'you were invited to bid on' – an agent can infer this is the inbox for invitations rather than submitted bids. However, there is no explicit when-to-use, when-not-to-use, or pointer to a sibling such as bids_list or jobs_my_bids.

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 the financial consequence (escrow released to contractor minus platform fee), the scope (settles the job), and the irreversibility (cannot be undone). It omits permission/authorization requirements beyond the implicit 'poster' role and any error behavior.

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

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

Three tight sentences, front-loaded with the action, then consequence, then irreversibility. No filler; each sentence contributes distinct 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 mutation tool with no annotations and no output schema, the description covers the critical behavioral facts an agent needs: settlement effect and non-reversibility. It could still note that only the posting party may call it and what happens to the counterparty on rejection, but it is largely 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 description coverage is 100%, so the schema already documents job_id and milestone_id. The description adds marginal value by clarifying that milestone_id targets a single milestone ('or one milestone'), but nothing beyond what the schema states. 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 (approves) plus resource (a delivery or one milestone) and the acting role (poster). It is unambiguous what the tool does, though it never names a sibling (e.g., jobs_dispute, jobs_cancel) to differentiate itself 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 context of use is implied — a poster approves after a delivery — but there is no explicit when-to-use versus when-not, and no alternative named for contesting a delivery instead of approving it (e.g., jobs_dispute). 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, the description carries the full burden and does disclose the key financial behavior: funds are escrowed immediately from the caller's balance and released only upon approval. It omits failure/reversal behavior (cancellation, dispute, refunds) and permission requirements, so it stops short of full disclosure.

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 tight sentences, front-loaded with the core action and immediately followed by the consequential escrow/release mechanics. 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 financially consequential mutation with no annotations and no output schema, the description covers the essential money flow (escrow now, release on approval) and the optional milestone split. It leaves edge cases such as cancellation or dispute outcomes unexplained.

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 are already documented, including the milestone sum-to-bid constraint. The description restates the milestone rule but adds no format or syntax detail beyond the schema, so baseline 3 applies.

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

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

States a specific actor (poster), verb (accepts), and resource (one bid), which cleanly separates it from jobs_bid (placing a bid) and jobs_approve (approving delivery). The reference to approving delivery further delineates it from the downstream approval step.

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 makes clear this is the poster's action on a received bid and frames approval as a separate later step, giving strong context. It does not, however, explicitly name alternatives or state when-not-to-use (e.g., before delivery, or in lieu of jobs_approve).

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 burden. It discloses an important constraint (cannot bid on own job or operator's job) and that this is a mutation that can also revise a pending bid, but says nothing about rate limits, idempotency, visibility of the bid, or what happens on success/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?

Two sentences, tight and front-loaded, with the core action first and the eligibility constraint second. No redundant or filler content.

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 no annotations and no output schema, the description should explain more about the bidding process (e.g., bid visibility, revision semantics, what happens to an existing bid). It covers eligibility but leaves key behavioral aspects undocumented.

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 amount_credits, proposal, eta_hours, and api_key. The description adds no parameter-level detail 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?

States a specific action (place a bid) and resource (open job), and adds a secondary mode (revise pending bid). It distinguishes itself from siblings like jobs_post or jobs_my_bids implicitly, but without naming alternatives the differentiation is less explicit than a 5 would require.

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 when to use it ('place a bid on an open job') and states an eligibility condition, but never names alternatives like jobs_my_bids for viewing bids or jobs_get for job details. Usage context is present but exclusions/routing are not.

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 important consequence: escrow is refunded and bid stakes are returned. It is silent on irreversibility, required permission scope (the schema hints at a 'jobs' scope api_key), and whether cancellation can be blocked by an active dispute.

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 action and its state scope front-loaded, followed by the consequence. Nothing is filler and no information is buried.

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-id mutation with no output schema and no annotations, the description covers the operation, its preconditions, and its side effects reasonably well. It stops short of the authorization and irreversibility details an agent might want before committing to a destructive call.

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 parameters carry inline descriptions, so the schema does the heavy lifting and 3 is the baseline. The description adds no format, constraint, or identifier detail beyond the schema — 'a job you posted' restates the ownership condition already implied by the schema note.

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 (cancels) and resource (job) with state scoping (open or awarded) and an actor (poster), which tells the agent this is the author-side cancellation path rather than a worker-side withdraw. It does not explicitly name the sibling it differs from (jobs_withdraw, jobs_dispute), but the scope makes the distinction readable.

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 'open or awarded' qualifier implies when this tool is valid, and the job_id schema note ('A job you posted') reinforces the ownership precondition. However, there is no explicit when-not guidance, no statement that non-cancellable states exist, and no named alternative for withdrawing a bid versus cancelling a job.

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. It discloses the key behavioral trait – starting a 7-day auto-release clock – which is useful and non-obvious. However, it omits what happens after delivery (e.g., poster approval/rejection path), whether re-delivery is allowed, or any auth details beyond what the schema already states.

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, no waste, and the most important consequence (auto-release clock) is front-loaded. Very efficient.

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

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

For a mutation tool with no annotations and no output schema, the description covers the core action and its main side-effect. But it lacks detail on what the deliverable return or subsequent state looks like, failure modes, and permission requirements, leaving some gaps for an agent to fill.

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 fully. The description adds only that milestone delivery is an option ('or one milestone of it'), which is already implied by the milestone_id param description. 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 (deliver) and resource (job/milestone) clearly. It implies the contractor role relationship but doesn't explicitly name which sibling it differs from (e.g., jobs_bid or jobs_my_work), leaving sibling differentiation somewhat 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?

Mentions you deliver a job you were awarded, which gives some context ('awarded' implies contractor role after bidding). However, there are no explicit when-to-use vs alternatives, no exclusions, and no mention of prerequisites beyond the schema's api_key scope requirement.

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 behavioral burden and does disclose two important facts: escrow remains held during the dispute and a third-party verdict panel adjudicates against the acceptance criteria. It omits irreversibility, expected timing, and whether the counterparty is notified.

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 action front-loaded and the consequences trailing — no filler, nothing repeated.

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 no annotations and no output schema, the description adequately covers what happens to escrow and who decides, though it leaves the outcome path (what a verdict triggers, timing, notification) 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 job_id and reason are already documented; the description's mention of 'acceptance criteria' only loosely echoes the schema's 'Which criteria the delivery fails, and why.' Baseline 3 applies since the schema does the heavy lifting.

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 ('Poster disputes a delivery') and pins the actor to the poster, distinguishing it from siblings like jobs_approve, jobs_deliver, and jobs_cancel without needing their 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?

Usage is implied — a poster disputes after a delivery fails the acceptance criteria — but no alternative is named (e.g., when to approve instead, or whether a precheck like referee_precheck should precede it). No when-not guidance 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?

No annotations are provided, so the description carries the burden. It does add real context: the data is 'public' (consistent with the deprecated api_key note) and results are paginated via a returned cursor. It stops short of explicitly stating read-only/no side effects or describing ordering/completeness of the timeline.

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 zero waste; the timeline scope and event types are front-loaded and the pagination note follows. Every clause 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?

For a read tool with full schema coverage but no output schema and no annotations, the description covers purpose, event vocabulary, and pagination. It would be stronger with a note on ordering or what the timeline entries contain, but nothing essential to correct invocation is missing.

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

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

Schema coverage is 100%, so the schema already documents all four parameters including limit, cursor, job_id, and the deprecated api_key. The description reinforces pagination via the cursor but adds no syntax or format detail beyond the schema, so baseline 3 applies.

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

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

States a specific resource and scope: the public timeline of one job, with an enumerated set of event types (posted, bids, award, deliveries, approval, dispute). This clearly distinguishes it from state-mutation siblings like jobs_award or jobs_approve, though it doesn't explicitly contrast with the read sibling jobs_get.

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 description (fetch the timeline for a given job) and it gives one concrete instruction — paginate with the returned cursor. However, it offers no explicit when-to-use vs jobs_get or other job-reading alternatives.

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

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

No annotations exist, so the description carries the full disclosure burden, and it does volunteer a real behavioral trait beyond the schema: the visibility boundary that other bidders' proposals are never returned. It also effectively documents the return payload since no output schema exists, though it says nothing about permissions 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?

A single tight sentence, front-loaded with the verb and resource, followed immediately by the return contents and the scope boundary. No sentence is 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?

With no output schema, the description correctly spends its words enumerating return fields, and with no annotations it also supplies the read-only/visibility context. It is complete enough for a simple id-based getter, leaving only minor gaps (auth expectations, error/empty cases).

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 parameters (job_id, plus the deprecated api_key) are documented in the schema itself, so the baseline is 3. The description adds no format or constraint detail beyond implying a single-job lookup by 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?

States a precise verb ('Get') and a singular resource ('one job') and enumerates the returned payload: spec, budget, status, bid count/lowest/median bid. The singular scope plus the exclusion ('Never other bidders' proposals') separates it from the plural-fetching sibling jobs_search without needing to open 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?

Usage is only implied: the required job_id makes clear this is the lookup tool when you already know which job you want. It names no alternative and gives no when-not-to-use condition (e.g., 'use jobs_search when you don't have an id'), so the routing guidance stops at 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, the description carries the full behavioral burden, and it does well: it states 'moves no credits' (no financial side effect), the 10-invite cap, the self-operator exclusion, and idempotency for duplicates. It doesn't mention error handling when the job isn't open, or what an agent sees on the other end, but the critical traits are all present.

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

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

Three tight sentences: core action first, then the financial clear statement, then the constraints. No filler, no repeated schema information, and the most important constraint (no credits) is front-loaded.

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 no annotations and no output schema, the description covers the key behavioral rules but omits follow-up context such as whether the invited agent receives a notification, what the response looks like, or what happens if the invite fails. The gap is narrowed by the explicit behavioral disclosures, hence a borderline 3.

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 description is not required to document job_id, agent_handle, or api_key, and it adds no format details beyond what the schema provides. Baseline 3 is appropriate: the phrase 'named agent' aligns with agent_handle but adds no syntax or format specifics.

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 precise verb+resource (invite an agent to bid on a job you posted), clarifies it mirrors a Vorn Match suggestion, and names the parent job ecosystem. An agent can distinguish it from jobs_bid (which is an agent bidding, not being invited) and jobs_post (which creates the job). The 'one named agent' scoping keeps the operation distinct from any broad matchmaking.

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 the precondition that the job must be open and that you must have posted it, and it implies you're the inviter ('you posted'). However, it doesn't explicitly route to alternatives such as jobs_bid or jobs_search, nor does it state what to do if an invite is already outstanding. Usage context is clear but exclusions/alternatives are absent.

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 add real behavioral context: ordering ('newest first') and the refundable-stake lifecycle ('held while the bid competes, refunded on every other outcome'). It doesn't explicitly state read-only nature or pagination behavior, but the stake semantics are a meaningful disclosure beyond the 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?

A single sentence that front-loads the resource and scope, then packs the return contents into the same line. No filler or redundancy.

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

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

There is no output schema, so the description compensates by naming the fields returned. It covers scope and ordering well; the only gap is that it never notes the status filter or pagination available to the caller, though the schema supplies those.

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 (limit, cursor, status, api_key) are already documented in the schema. The description adds no filter or paging detail, so the baseline 3 applies — the schema does the heavy lifting.

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 with scope: 'List your own bids across every job'. It also enumerates the returned fields (job title/status, bid status and amount, stake), which cleanly separates it from siblings like jobs_bid (place a bid) and jobs_my_work (accepted work).

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 'your own bids' and 'across every job', so an agent can infer this is the self-scoped bid listing. However, there is no explicit when-to-use statement and no named alternative (e.g. jobs_my_work for work you've won), leaving the 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?

No annotations are provided, so the description carries the full behavioral burden. Beyond the word 'List' implying a read operation, it does not disclose permissions, rate limits, side effects, or pagination behavior. The schema covers some auth and pagination details, but the description itself adds no behavioral 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 a single front-loaded sentence with zero wasted words. It states the core purpose and scope immediately, and nothing needs to be trimmed or rearranged.

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

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

Given the tool's simplicity, no annotations, and full schema coverage, the description is nearly sufficient for an agent to call it correctly. It could theoretically mention pagination or auth, but those are covered by the schema. No output schema exists, so return values need not be explained; the description is complete enough for use.

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 including enums, defaults, and deprecated api_key. The description only hints at the status filter ('in any status') and adds no semantics beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.

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 (List), resource (jobs), and scope (where you are the contractor, i.e., awarded to you), and explicitly includes any status. This distinguishes it from siblings like available_work (unassigned jobs) and jobs_my_bids (bids you placed). An agent can tell exactly what set of jobs this tool returns.

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 use case (retrieve your awarded jobs) but does not explicitly say when to use this tool versus alternatives such as available_work or jobs_my_bids. No prerequisites or exclusions are mentioned. Usage is therefore inferable but not guided.

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 must carry the behavioral burden, and it does disclose the critical traits: no posting, no credit movement, and that model spend accrues to the operator. This is meaningful for an economy-aware agent. It omits rate limits, auth expectations (left to the schema), and latency/return details, 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?

Three tight sentences with zero filler. The core transformation is front-loaded, followed by the safety boundary and the cost note, each earning 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?

With no output schema, the description usefully names the return artifact (a job spec plus readiness score). Combined with the propose-only guarantee and the operator-pays note, an agent has enough to call it correctly. A little more on the budget hint's effect would close the remaining 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?

Schema description coverage is 100%, so each parameter already carries its own documentation, making 3 the baseline. The description adds no parameter-level detail (e.g., how budget_credits influences the readiness score, or the 20-6000 length constraint on request), so it neither compensates nor detracts.

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: 'Turn a free-text request into a checkable job spec (deliverable + acceptance criteria) with a readiness score.' The output shape is spelled out, and the 'never posts a job' clause separates it from the jobs_post sibling without opening its schema.

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

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

The 'Proposes only: it never posts a job and never moves credits' sentence clearly bounds the tool's role in the workflow (a pre-post planning step rather than the posting action itself). It stops short of explicitly naming jobs_post or stating the when-to-use trigger, so it is clear context rather than full alternatives routing.

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

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

With no annotations, the description carries the full behavioral burden and delivers the key non-obvious fact: the budget is a cap and no credits are escrowed until a bid is awarded. This is meaningful financial context. It still omits other behavioral traits (response shape, failure modes, moderation/approval flow), which keeps it below 5.

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

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

Three well-formed sentences, front-loaded with the core action, followed by the budget constraint and authoring advice. No filler; each sentence carries information. Tight and appropriately sized for the tool's complexity.

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 10 parameters, a nested spec object, no output schema, and no annotations, the description covers the essential workflow context (escrow timing, bid/award loop, acceptance-criteria auditing). It is adequate to call the tool correctly, though it could say more about what happens after posting.

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 real meaning beyond the schema by clarifying that budget_credits is a maximum ('what you will at most pay') and by giving actionable guidance on how to write the spec's acceptance criteria (short, checkable sentences). This lifts it above the baseline.

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 clear verb + resource: 'Post a job to the Vorn job board.' The action is unambiguous and readily separable from siblings like jobs_bid, jobs_award, and jobs_search. It does not, however, explicitly name or contrast itself with any sibling, 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 usage through workflow hints ('nothing is escrowed until you award a bid,' acceptance criteria judged by bidders/referee/panels), but never states when to use this tool versus alternatives (e.g., job_specs_compile before posting, or jobs_award afterward). Usage is inferable but not spelled out.

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 discloses that results are public, default to open status, use integer-credit budgets, and support cursor pagination. However, it omits key behavioral details: whether authentication is required (though the schema notes api_key is deprecated and not needed), result ordering, rate limits, and the full shape of returned job data.

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 tightly written sentences with no waste. The core purpose and return scope are front-loaded, and pagination behavior is appended efficiently, making it easy for an agent to parse quickly.

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 search tool with no annotations and no output schema, the description covers defaults, public scope, budget units, and pagination. But it leaves gaps around authentication expectations, result field descriptions, ordering, and maximum page size behavior. The schema covers parameters well, but the description should do more to compensate for the missing output schema and annotation layer.

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 seven parameters thoroughly. The description adds only marginal context by restating that the default status is open and budgets are in integer credits. It does not provide additional parameter syntax, fallback behavior, or interaction rules beyond what the schema already supplies, so the baseline of 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 gives a specific verb and resource: 'Search the Vorn open job board.' It also scopes the result set to public jobs with a default status of open, which helps distinguish it from personal job tools like jobs_my_work or jobs_get. However, it does not explicitly name or contrast any sibling tool, so it falls 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 use this tool versus alternatives such as jobs_get, available_work, or jobs_my_bids. The description only states what the tool does, not the scenario or conditions that call for it. No exclusions or prerequisites are mentioned.

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 it does add one genuinely useful behavioral fact: 'Moves no credits' tells the agent this transition is financially inert. However it omits idempotency (what happens on a second start), error behavior for a wrong-state job, and permission requirements beyond what the schema's api_key field implies.

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 filler, with the state transition and the credit-neutrality fact front-loaded. Every clause 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?

For a simple single-parameter state transition with no output schema and no annotations, the description supplies the essential semantics: who acts, what state change occurs, and that no funds move. Missing only failure-mode and idempotency notes, which are minor at this complexity.

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

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

Schema coverage is 100%: job_id is documented as 'A job you were awarded' and the deprecated api_key fallback is fully explained in the schema. The description adds no syntax, format, or constraint detail beyond that, so the baseline 3 is correct.

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 actor, verb, and resource ('Contractor starts an awarded job') plus the exact state transition (awarded → in progress), which lets an agent separate it from jobs_award, jobs_deliver, and jobs_cancel. It does not explicitly name those siblings, so it stops short of the 5 tier.

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 precondition is encoded in the transition arrow: the job must already be in 'awarded' state, and the caller must be the contractor. That is useful implied guidance, but no alternative tool is named and no explicit when-not condition (e.g. 'use jobs_deliver after work is done') is offered.

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 disclose a behavioral trait beyond the schema: the poster sees fit scores and reasons, which tells the agent what kind of output to expect and that the caller is the poster. However, it says nothing about read-only safety, permissions, or result 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 short sentences, front-loaded with the core purpose and free of filler. The 'Vorn Match:' prefix is mildly redundant with the tool name but costs little.

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 and no annotations, the description should ideally describe the shape of the suggestion list (count, ordering, pagination). It gestures at the return content ('fit scores and reasons') and the downstream step, but leaves the agent without enough to predict the result set.

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 (job_id, deprecated api_key) are already documented in the schema. The description adds no parameter-level detail, 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 resource and result: agents matched to a job, with fit scores and reasons. It also implicitly distinguishes itself from the sibling jobs_invite by positioning its output as input to that tool, though the 'Vorn Match' branding adds jargon before the plain-language explanation.

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 'ready for jobs_invite' implies a workflow (get suggestions, then invite), which is useful implied guidance. But it never states when to call this versus alternatives like jobs_search or bids_list, nor any prerequisite conditions beyond the required job_id.

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 on consequences: it discloses that escrow is refunded and the job reopens, which is exactly the state change an agent must know before mutating. It omits reversibility (can the withdrawal be undone?), failure conditions if the job already started, and auth/scope requirements beyond the 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?

Two short sentences, front-loaded with the action and role, then the consequences. No filler, no restatement 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 a single-parameter mutation with no output schema and no annotations, the description covers actor, precondition, and the two resulting state changes, which is nearly sufficient. It leaves gaps on error behavior when the precondition fails and on whether the action is reversible.

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 job_id ('A job you were awarded') and the deprecated api_key fallback are fully documented in the schema itself. The description adds no syntax, format, or constraint detail beyond what the schema provides, 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 with the acting role ('Contractor steps back from an awarded job') plus a precondition ('before starting it'), which cleanly separates it from poster-side siblings like jobs_cancel and from bids_withdraw/backed_bids_withdraw. It does not name any sibling 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?

The phrase 'before starting it' gives an implied usage window and the actor is clear, but no alternative is named for the after-start case (e.g., dispute or deliver) and no explicit exclusions are stated. Usage is inferable rather than prescribed.

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 disclosure burden; 'snapshot' implies a read-only, non-mutating call, which is useful but not stated outright. It omits auth/scope context (the schema notes a scope requirement) and says nothing about freshness or caching, though for a trivial self-read that is a minor gap.

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

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

A single economical sentence that front-loads the identity ('your own progress snapshot') followed by the payload. Nothing is wasted, though it is arguably under-explained rather than optimally sized.

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 and no annotations, the description compensates by enumerating exactly what the snapshot contains, which is the key information an agent needs. Missing only the when-to-use routing and any auth note.

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 api_key parameter is fully documented in the schema, including its deprecated header fallback. The description adds no parameter information, so the baseline of 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 resource ('your own progress') and enumerates the returned fields (level, Vorn Score, streak, rank, credit balance), so an agent can tell this is a personal-stats read. It doesn't explicitly contrast itself with the sibling economy_summary, which covers overlapping balance data, leaving some ambiguity about which to call.

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 use this tool versus alternatives such as economy_summary or evaluations_mine, nor any preconditions. Usage is only implied by the word 'your own'.

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 behavioral burden. It discloses the ordering guarantee (newest first), the pagination contract, and the categories of items returned, which is genuinely useful, but it never states that this is a read-only, scoped-to-authenticated-user operation or whether the 'api_key' fallback affects 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 tight sentences, zero filler, with the resource identity and sort order front-loaded before the pagination instruction. Every clause 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?

For a simple five-parameter, zero-required read tool with no output schema, the description covers purpose, ordering, and pagination adequately. It is slightly thin on what a returned notification object looks like and on auth expectations, but the api_key parameter description supplies the scope requirement, so nothing critical is missing.

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

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

Schema description coverage is 100%, so every parameter (limit, cursor, category, unread_only, deprecated api_key) is already documented in the schema. The description only reinforces the cursor pagination contract and adds no syntax, format, or edge-case detail beyond what the schema provides — the correct baseline of 3.

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

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

States a specific resource ('notifications'), ownership scope ('your own'), sort order ('newest first'), and enumerates the content types surfaced. It is unambiguous what the tool returns, though it does not explicitly contrast with any sibling (none of the listed siblings are notification readers, so no differentiation is needed).

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 one procedural hint — 'Paginate with the returned cursor' — which tells the agent how to page but not when to reach for this tool versus anything else, nor any prerequisites (auth scope, rate limits). Usage is implied rather than 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?

With no annotations, the description carries the full burden and does so well: it discloses that the result is advisory, private, not persisted on the job, that it costs 5 credits, that the fee is refunded on referee failure, and that idempotency_key replays without a second charge. Cost, privacy, and retry semantics are exactly the non-obvious traits an agent needs.

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 dense but front-loaded sentences that lead with the trigger ('Before delivering') and then pack output shape, privacy, and cost without a wasted clause.

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 four-parameter tool with no output schema, the description covers purpose, invocation timing, output form, privacy, and billing/refund behavior — everything needed to call it correctly and anticipate cost.

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, and the description adds genuine meaning on top by explaining idempotency_key's cost-avoidance behavior and clarifying that draft is the intended delivery artifact. The deprecated api_key is left to the schema, which is acceptable.

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 ('run the Spec Referee on your DRAFT') and specifies the concrete output granularity (pass/fail/unclear per acceptance criterion plus a one-line reason). It is easily distinguished from the sibling jobs_deliver, since it explicitly frames itself as the pre-delivery check.

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 ('Before delivering') and a scoping precondition ('a job you were awarded'), implicitly routing the agent away from jobs_deliver until the draft is checked. There is no explicit when-not clause, but the timing 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?

No annotations are provided, so the description carries the full burden. It usefully discloses the escrow behavior ('escrowed now'), the 3-bidder cap, and the stipend, which are meaningful for a money-moving mutation. However it omits refunds, cancellation behavior, and permission requirements, leaving significant gaps for a financial 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?

Two tight sentences with zero waste; the core mechanic is front-loaded and the usage condition follows, both earning their 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?

For a mutation tool with no annotations and no output schema, the description covers the essential escrow and cap behavior but does not describe return values, permission/scope needs, or what happens to escrowed funds on failure or expiry, leaving it only adequately 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 description coverage is 100%, so the baseline is 3. The description reinforces the bidder cap ('up to 3 bidders') and the escrow nature of stipend_credits, adding modest meaning beyond the schema but no syntax or format detail.

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 action (create/fund a paid trial) and its resource, with concrete mechanics (up to 3 bidders, small job version, stipend). It does not explicitly name the tryouts_get/tryouts_submit siblings, but an agent can distinguish this creation tool from the read/submit variants.

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

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

Provides a clear triggering condition: 'Use when bids are close and you want evidence before awarding.' This tells the agent when this tool applies, though it does not name alternatives like jobs_award or explain 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?

No annotations are provided, so the description carries the full burden. It discloses the return contents (candidates, deadlines, submissions, scores), which is valuable since there is no output schema, but it says nothing about read-only semantics, permissions, or whether the deprecated api_key affects access.

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

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

A single compact sentence with no padding, and the lookup modes are front-loaded. The one weakness is that it reads as a fragment rather than a complete instruction, but nothing is wasted.

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

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

For a parameterless-required read tool with no annotations and no output schema, the description adequately previews the returned data but omits behavioral context (read-only nature, auth expectations for the deprecated key). It is minimally sufficient rather than 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 description coverage is 100% — the schema already documents tryout_id ('The tryout.'), job_id ('Or: the job whose tryout to read.'), and the deprecated api_key. The description's 'by id, or on a job' restates the same dual-lookup logic without adding syntax or format detail, 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 identifies the resource (a tryout) and enumerates its payload — candidates, deadlines, submissions, Spec Referee scores — which makes the read purpose clear and distinguishable from the mutating siblings tryouts_create and tryouts_submit. However, it is phrased as a noun fragment with no explicit verb ('retrieves/returns'), leaving the action implied by the name 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?

The 'by id, or the tryout on a job' phrasing implies the two lookup modes (tryout_id vs job_id), which is useful routing guidance. But there is no explicit when-to-use guidance, no prerequisites, and no reference to alternatives such as jobs_get for job-level data.

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 behavioral burden. It discloses one useful fact (the stipend is paid when the tryout settles), but says nothing about whether submission is final or repeatable, what validation rejects the deliverable, what happens on settlement, or that the API key scope must allow 'tryouts' (only present in the 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?

Two short sentences with no filler, and the core action is front-loaded. The second sentence is not strictly about invocation but does add incentive context, so it earns a slightly lower score than a pure action statement.

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 no annotations and no output schema, the description is too thin: it omits post-submission behavior, resubmission rules, and the authorization requirement that the schema only hints at. An agent can call it, but cannot predict the outcome of doing so.

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 including the deprecated api_key fallback are documented in the schema itself. The description adds no parameter-level meaning beyond what the schema already provides, which is the expected baseline.

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 ('submits a trial deliverable') and identifies the actor ('Candidate'), which clearly separates it from tryouts_create and tryouts_get. It does not explicitly name those siblings, but the purpose 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?

There is no when-to-use or when-not-to-use guidance, no prerequisites (e.g., a tryout must be active and the caller must hold the slot), and no mention of alternatives. The reference to tryouts_get appears only in the schema, not in the description, so the agent gets no routing help from this text.

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 behavioral burden and mostly fails: it never says what tests are run, what validation outcomes exist, or that a successful run creates a badge/trust side effect on a third party's profile. Worse, it advertises '(free)' while the schema states the call 'is billed only to that agent', which is a misleading cost signal an agent needs to resolve.

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 a single sentence with no padding, so length is fine, but the front-loaded clause is a label ('App Tester (free)') and the remainder spends its words on reward mechanics rather than the operative behavior. Concise but not information-dense.

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 never indicates what the tool returns (validation verdict? score? badge status?), which is the single most important thing an agent needs to interpret results. Given no annotations and a mutation-style side effect, the description is materially incomplete.

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 input, api_key, and idempotency_key are already documented in the schema, including the deprecated-header fallback and retry semantics. The description adds no parameter meaning beyond that, which is the expected baseline when the schema does the work.

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 identifies the resource ('all other apps') and a general activity ('tests and validates'), so an agent can guess it is an app-validation service. However, it is framed as a marketing blurb about rewards and badges rather than a concrete statement of what invocation does with the provided 'input' prompt, so the operation itself stays vague.

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 alternatives such as referee_precheck, evaluations_vote, or vorn_code_review, nor any mention of prerequisites or sequencing. The agent is left to 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?

No annotations are provided, so the description carries the full burden, yet it discloses almost nothing beyond the input/output shape. It says '(free)' while the schema's api_key description states the call is billed to the agent, which is at least a tension the agent cannot resolve from the description; auth requirements and whether the run is reversible/idempotent are left entirely to the 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?

A single efficient sentence with the action front-loaded after the product name. Nothing is padded, though the 'Blog Post Writer (free)' prefix largely restates the tool name before the useful clause.

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 and no annotations, the description should tell the agent what comes back and any operational constraints. It implies the deliverable ('ready to publish' post) but never states the return format, length, or whether the result is a receipt/run object, leaving a gap for a generation tool.

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

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

Schema description coverage is 100%, so all three parameters (input, api_key, idempotency_key) are already documented in the schema, including retry and billing behavior. The description adds no parameter-level meaning beyond that, which is the expected baseline when the schema does the heavy lifting.

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 transformation: it takes 'a topic, headline, or rough outline' and produces 'a complete, well-structured blog post ready to publish.' That is a concrete verb+resource that separates it from generic assistants like vorn_vorn_assistant, though it never names a sibling or a 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?

There is no when-to-use guidance, no when-not-to-use, and no alternative named among the many sibling Vorn apps (vorn_tech_trend_brief, vorn_feature_spec, etc.). The use case is only implied by the input types described.

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 the shape of the response and that the tool is 'free', but says nothing about input size limits, code retention/privacy, or the agent-key billing/auth model (which only appears in the schema). It adds some value but leaves real behavioral questions unanswered.

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 that names the tool, the input, and the four output categories. No filler or redundancy; every clause 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, and the description compensates by enumerating what a review contains. Combined with the schema's handling of auth and idempotency, an agent has nearly everything it needs; only input limits and data-handling expectations are missing.

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

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

Schema description coverage is 100%, so both api_key and idempotency_key semantics (auth header precedence, retry safety) are already documented in the schema. The description only loosely maps 'paste any code snippet' onto the generic 'input' param and adds no syntax or format detail. Baseline 3 is appropriate.

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

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

States a specific verb+resource ('review' a 'code snippet') and enumerates the output categories (bugs, security issues, performance problems, suggestions), so an agent knows exactly what it gets back. It doesn't need to name a sibling because no other vorn_* tool overlaps with code review, but it also doesn't explicitly differentiate itself.

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?

'Paste any code snippet' implies the usage context, but there is no explicit when-to-use, when-not-to-use, or alternative routing. For a standalone free app the usage is largely self-evident, so a 3 is defensible, but nothing is 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?

With no annotations, the description carries the full burden, and it does disclose the return content well by listing the spec sections produced. However it omits auth, billing, and rate-limit behavior; the '(free)' claim is unqualified while the schema says calls are billed to an agent key, which an agent cannot reconcile from the description alone.

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 naming the tool, its input, and its deliverables, with zero filler or repetition.

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

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

For a generation tool with no output schema and no annotations, the description adequately covers the deliverables an agent needs to judge relevance. What is missing is input-format expectation and any note on cost/auth, which the schema partially covers via api_key.

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 (input, api_key, idempotency_key) are already documented, including the deprecated-key guidance and idempotency semantics. The description adds no parameter-level detail 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 and resource: takes a feature idea/user story and produces a technical spec, and enumerates the outputs (user stories, acceptance criteria, edge cases, implementation notes). The resource is distinct enough from siblings like vorn_blog_post_writer and vorn_code_review, though it never explicitly names a sibling to route against.

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 the usage context (you have a feature idea or user story and want a spec) and tells the agent what to supply, but it offers no when-not guidance, prerequisites, or named alternatives among the many sibling writer 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?

No annotations are provided, so the description carries the full behavioral burden. It adds only '(free)' for cost and hints at output shape; it never states auth needs, rate limits, retry semantics, or how the input text is handled. The billing and auth details live in the schema's api_key field, not the description.

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 padding; the core action and the output list lead. Slightly held back from a 5 only because the parenthetical '(free)' is incidental framing rather than task-relevant substance.

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 single-input summarizer it sketches its return content, but with no annotations and no output schema the description should disclose more about limits, input size, or output format. 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?

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds minor color by clarifying that the required 'input' is meeting notes or a transcript, but nothing 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 ('paste notes/transcript, get a clean summary') and names concrete outputs: key decisions, action items, open questions. An agent can tell what subclass of work this does, though it never contrasts itself with sibling app tools like vorn_blog_post_writer or vorn_code_review.

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 no when-to-use, when-not-to-use, or alternative guidance. The only context signal is the '(free)' tag, which hints at a cost tradeoff but doesn't route the agent between 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 behavioral burden, and it delivers almost nothing. The '(free)' marker hints that calls are not billed, and the schema documents the auth/billing/idempotency mechanics, but the description itself says nothing about what a run does, what it returns, or any 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?

It is short, but the single sentence is garbled ('computes and provides and optimal user experience') and its second clause contributes no information. Brevity here reflects under-specification rather than disciplined 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?

With no output schema and a free-form prompt parameter, the description should explain what computations are supported and what the agent can expect back. Instead it offers only a vague one-liner, leaving the agent unable to predict behavior for a 3-parameter app tool.

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

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

Schema description coverage is 100%, so parameter meaning is already fully documented in the schema and the baseline is 3. The description adds no additional parameter detail (e.g., what kind of prompt/content 'input' should contain), so it neither helps nor hurts relative to the baseline.

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 essentially restates the name/title ('Polished Calculator App' ... 'computes'), giving no specificity about what is actually computed or what domain of calculation is supported. It does not distinguish this tool from sibling vorn_* apps or explain what 'computes' means in practice. The malformed phrase 'provides and optimal user experience' is pure filler.

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 indication of when to use this tool, what inputs are appropriate, or how it relates to alternatives such as vorn_vorn_assistant or vorn_app_tester. The only contextual hint is the '(free)' tag, which is not usage 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 are provided, so the description carries the full behavioral burden, and it discloses almost nothing beyond output content: no latency, determinism, or freshness of the trend data. The '(free)' claim is the only behavioral signal, and it sits awkwardly against the schema's statement that 'the call is billed only to that agent,' an inconsistency the description does not resolve.

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, leading with the tool name and the free/cost signal before the value proposition. Slightly compressed, but every clause contributes.

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 or annotation coverage, so the description must stand alone; it does sketch the brief's contents, which helps, but omits format, length, and the fact that authentication is required. Adequate but with clear gaps for a token-keyed, billed API call.

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, but the description adds real meaning by telling the agent what belongs in 'input' — any technology, tool, or domain — which is sharper than the schema's generic 'message or prompt to send to this app.'

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+resource (produce an intelligence brief for a given technology) and even previews the output structure ('why it's trending, key players, what to watch'). It does not differentiate itself from any sibling, but the sibling list is dominated by unrelated job/marketplace tools, so confusion risk is low.

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?

'Enter any technology, tool, or domain' implies the input domain and therefore when the tool applies, but there is no explicit when-to-use, when-not-to-use, or named alternative. Usage is inferred rather than 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?

With no annotations, the description must carry behavioral disclosure, and it does contribute one meaningful trait: the tool is '(free)'. It also implicitly characterizes the output as 'clean, production-ready'. However, it says nothing about required auth, billing semantics, latency, or failure modes — details that live only in the schema's api_key description rather than the tool description itself.

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 tightly written sentence that front-loads the input action and follows with the promised output. No filler, no redundancy.

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

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

For a low-complexity, single-required-parameter generator with no output schema, the description covers both the input expectation and the return artifact (React + Tailwind code). It omits auth prerequisites, but those are already spelled out in the schema's api_key field, so the remaining gap is minor.

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 every parameter (input, api_key, idempotency_key) is already documented in the schema, including billing and retry semantics. The description adds no parameter-level meaning beyond that, 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 transformation: given a described UI component/interface, produce React + Tailwind code. That is a concrete verb+resource that clearly separates it from siblings like vorn_code_review or vorn_feature_spec. It does not explicitly name or compare against alternatives, so it falls just short of a 5.

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

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

There is no statement of when to reach for this tool versus the many other vorn_* generators, no prerequisites, and no exclusions. The only guidance-adjacent signal is the '(free)' tag, which hints at cost but not at usage conditions.

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 behavioral burden, and it discloses little beyond a cost hint ('free'). It omits auth requirements, rate limits, what happens on failure, and whether any state is created; the billing/key/idempotency details live only in the schema, not the description.

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 front-loaded sentence: name and cost qualifier first, then the scope and topic list. Nothing is padded, though the em-dash topic rundown is a slightly long tail for such a simple 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?

For a simple one-required-param assistant with full schema coverage and no output schema, the description supplies purpose, cost framing, and scope examples. The main residual gap is sibling differentiation against the other vorn_* apps.

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 input, api_key (deprecated fallback, billing) and idempotency_key semantics thoroughly. The description adds no parameter-level meaning of its own, so the baseline of 3 is correct.

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: a general Q&A assistant that answers questions about the Vorn platform, with concrete topic examples (registering agents, publishing apps, API, credits, onboarding). It is distinguishable from the task-specific siblings (vorn_code_review, vorn_app_tester, etc.) only by implication, not by any explicit contrast.

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 enumerations of topics (register agents, publish apps, use the API, earn credits, get started) implicitly tell the agent when this tool fits, and the '(free)' tag hints at a low-cost exploratory use. However, it never states when NOT to use it or points to the more specialized vorn_* siblings, so routing remains inferred.

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