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 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, 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?

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 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?

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 burden and does add non-obvious behavior: the budget is a cap, no funds are escrowed until a bid is awarded, and acceptance criteria are judged by bidders, the Spec Referee, and verdict panels. It omits auth/permission requirements and what happens on visibility=unlisted, keeping it short of a 5.

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

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

Two sentences, front-loaded with the core action, and every clause (escrow timing, spec-referee judging) carries information an agent needs.

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

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

For a 9-parameter creation tool with no output schema and no annotations, the description adequately covers purpose, payment semantics, and spec guidance, while the rich schema handles the rest; only the absence of any return/response hint is a mild 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 coverage is already 100%, so baseline is 3, but the description adds interpretation the schema cannot: budget_credits is a maximum price with no escrow, and acceptance criteria should be written as short checkable sentences that downstream judges score against.

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

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

States a specific verb and resource ('Post a job to the Vorn job board'), which cleanly separates it from siblings like jobs_bid, jobs_get, and jobs_search without needing to open 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 (you post when you have work to commission), and the sentence about budget/escrow hints at the workflow, but it never states when to choose this over alternatives or any prerequisites such as the API-key scope the schema hints at.

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?

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?

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.