ruzora

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description usefully signals the generated content (a legal check is run on the questions, the rubric is anchored 1-4), but it says nothing about whether the kit is persisted, its output shape, or whether it consumes any stored role 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?

A single front-loaded sentence with a colon-delimited list of deliverables; nothing is redundant. It is dense and slightly noun-phrase-heavy rather than imperative, but no sentence wastes space.

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

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

With no output schema, the description carries the burden of describing return content and it does so by enumerating the kit's components, which is the most important thing an agent needs here. The remaining gap is routing guidance against the many interview-related siblings, which no other field supplies.

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

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

Schema description coverage is 100% for both parameters, so the schema already explains 'role' and 'details'. The description adds no meaning beyond that — the enumerated kit components describe output, not inputs — 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 names a concrete deliverable — a structured interview loop for an engineering role — and enumerates its parts (stages, owners, time budget, questions, 1-4 rubric, legal check), which is specific enough to distinguish it from question-only siblings like developer_interview_questions or design_coding_assessment. It does not, however, explicitly contrast itself with those siblings, and the verb is carried by the tool name rather than the text.

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 prerequisites, and no mention of alternatives. With siblings such as design_coding_assessment, developer_interview_questions, build_role_scorecard and score_interview_notes, an agent must guess which one applies to a given request.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds some useful context about the target audience (new software engineer) and the plan's construction, but does not describe auth needs, output shape (no output schema exists), or whether it depends on other tools.

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 dense sentence, front-loaded with the deliverable and followed by an itemized content list. Every phrase carries weight; slightly list-heavy but effective.

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?

Without an output schema the description is the only place return values could be explained, but it does not describe the plan's format or structure beyond topic mentions. For a generated-artifact tool with two params and full schema coverage, what is present is 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%: role and details are both documented, and details even enumerates expected inputs such as start date, team, systems, scorecard outcomes, contributor type. The description adds no further parameter guidance, so the schema-carried 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?

The description states a clear deliverable (a 30-60-90 day plan) and itemizes its contents: least-privilege day-1 access, first PR in week one, buddy plan, milestones. It is distinguishable from siblings like build_role_scorecard or build_interview_kit, though its sibling-differentiation is by topic rather than explicit routing sentence.

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

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

No when-to-use guidance, no prerequisites, and no naming of alternatives. The description does not tell the agent when to pick this over build_role_scorecard, even though the plan's milestones depend on the scorecard outputs.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds that this is a generative structuring step (producing a scorecard artifact), which is useful, but it says nothing about return format, latency, or how the generated content is persisted.

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 value proposition and output list front-loaded, then a placement cue. 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?

With no output schema, the description usefully names the scorecard sections it produces, so the agent knows what comes back. It could say more about persistence or whether the artifact is saved/retrievable, which is the only gap for a generative 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 the four parameters are already documented in the schema, and the baseline is 3. The description frames the tool as taking a vague role description, which loosely maps to role_title/stack, but adds no syntax or format detail 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?

Specific verb (turn) and resource (a vague engineering hire into a role scorecard), and it enumerates the outputs: mission, measurable 12-month outcomes, must-haves, competencies and an interview map. An agent can tell it apart from siblings like write_job_description or build_interview_kit at a glance.

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?

"Start here before writing a job post" gives clear sequencing guidance and positions it ahead of write_job_description. It does not state explicit exclusions or when to prefer a sibling, so it falls short of a 5.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: it reveals the analytical method (scope-over-years), that it flags title inflation, and that it returns '3 questions' — output-shaping context the annotations do not carry.

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 sentences with no filler. The dual mode is stated first, the method constraint second, and the output value last — an effective front-loaded structure.

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 compensates by telling the agent what to expect (title-inflation flags, three differentiating questions) and confirms the accepted evidence inputs. For a 4-parameter, 100%-covered read-only tool this is nearly complete; only explicit prerequisite/routing guidance 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 each parameter (mode, company_size, role_description, candidate_evidence) is already documented in the schema, including the two-valued enum. The description only echoes the candidate inputs ('CV, interview notes or an assessment report'), which adds little beyond the schema 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 states a specific verb+resource ('work out what level a role really needs ... or what level a candidate really is') and splits the task cleanly into the two branches the tool supports. Its scope ('by scope, not years') and its output ('flags title inflation and gives 3 questions') are concrete enough that an agent can separate it from siblings like check_hiring_fit or build_role_scorecard.

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: use it to determine the level a role needs, or the level a candidate is, and the description hints at the methodology ('by scope, not years'). However, it names no sibling alternative and gives no explicit when-not-to-use guidance, so an agent must infer routing from the surrounding tool list.

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

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

Annotations mark this as non-read-only, open-world and non-idempotent, and the description adds real context beyond them: it discloses that the name, email and company are transmitted to Ruzora, that pricing is flat monthly with no price list, and that the typical outcome is a 15-minute founder call. It omits the verified-email/buyer_token prerequisite, though the schema documents that parameter in detail.

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

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

Three compact sentences, front-loaded with the five questions and the payoff, with no filler. The phrasing is slightly tangled around 'the next step to it', but the information density is high and appropriate.

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 nine-parameter, non-read-only tool with no output schema, the description covers roughly what the tool does, what it sends, and the typical next step. It does not say what the fit assessment itself returns or reference the verification prerequisite, which matters for a tool that submits PII.

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 nine inputs, including the enum values. The description only restates the underlying question topics (roles, runway, budget, timing) and adds no format, default or edge-case detail beyond the schema.

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

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

The description gives a concrete verb and resource: answer five questions (roles, runway, budget per engineer, timing) to get a fit assessment and a next step. That is clearly distinct from siblings like explain_ruzora_terms or request_vetted_shortlist. It stops short of naming any sibling explicitly, so it does not reach 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?

Usage is implied rather than stated: an agent can infer this is the tool for 'does a quote make sense / what does it cost' questions, reinforced by 'Explains the flat monthly pricing; no price list'. But there is no explicit when-to-use/when-not or a named alternative such as explain_ruzora_terms or request_project_scoping_call.

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

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

Annotations already establish readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety and determinism are covered. The description adds that checks are applied uniformly and are origin/accent-neutral, which is useful policy context, but it says nothing about what the red-flag log contains or how the protocol proceeds.

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 purpose before the fairness constraint. The long parenthetical listing threat schemes is slightly dense but each clause carries information; nothing is redundant.

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

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

For a read-only, idempotent tool with one optional parameter and no output schema, the description covers purpose, scope and fairness policy adequately. An agent would still want to know roughly what the red-flag log returns, but the low-stakes read-only nature makes this a minor 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?

There is a single optional parameter with 100% schema description coverage, so the schema already documents 'situation' fully, including the maxLength and the warning not to paste ID documents. The description adds no syntax or format guidance beyond what the schema provides, matching the baseline-3 case.

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 function — an identity-verification protocol for remote engineering hires that produces a red-flag log for one candidate — and enumerates the threat classes it addresses (fake candidates, stand-ins, DPRK IT-worker schemes). It is distinguishable from near-siblings like detect_resume_injection and verify_work_email, though it does not explicitly name those alternatives.

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 'Same checks for every finalist' implies the tool is used at the finalist stage, which is a weak usage cue. There is no explicit when-to-use/when-not statement and no routing to siblings such as detect_resume_injection or plan_reference_check, so selection still requires inference.

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

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

Annotations already declare it read-only, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuinely new behavior: the output is qualitative (each stack reads 'Available' or 'On request'), with no counts or profiles returned — useful since no output schema exists.

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

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

Two short sentences with no filler, and the availability-verdict promise is front-loaded followed by the output constraint. The compressed, colon-heavy phrasing slightly hurts readability 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 one-optional-param read tool with no output schema, the description supplies the missing return-value contract ('Available'/'On request', words only) that would otherwise be unknowable. Only the relationship to sibling availability/search tools is left unaddressed.

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

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

Schema description coverage is 100% and the single optional 'stack' array is fully documented with an example, so baseline 3 applies. The description echoes the array-of-stacks semantics ('each stack reads...') but adds no format or constraint detail 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 check against a specific resource: availability of Ruzora's vetted senior Latin America engineers for a given stack. It is distinguishable from search_vetted_engineers and request_vetted_shortlist by promising only an availability verdict, though the telegraphic 'Whether Ruzora has...' opener is grammatically awkward rather than a crisp verb+resource statement.

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 (run this to see if supply exists for a stack before searching or requesting a shortlist), but the description never names an alternative tool or states when not to use it. With siblings like search_vetted_engineers and request_vetted_shortlist present, an explicit boundary would have been cheap and valuable.

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

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

Annotations already cover readOnly/idempotent/non-destructive and openWorld=false, so the bar is lower; the description still adds non-obvious context by disclosing the temporal nature of the data ('Dated') and a liability caveat ('not legal advice'). It also previews the return shape (applicable laws plus the statute for each), which the annotations do not.

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, no filler: the core capability with its inputs and output is front-loaded, and the scope/liability caveat is compressed to a single trailing fragment.

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 must describe the return, and it does (applicable laws with the statute for each, covering pay range, benefits, close date). A read-only, idempotent lookup with 100% schema coverage needs little more, though the exact response shape and multi-location handling remain unstated.

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

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

Schema description coverage is 100%, so the schema already documents remote, locations and employee_count. The description restates the driving factors (hiring location, company size, remote status) without adding format or edge-case guidance beyond the schema's example values and threshold note. 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 (check/applies) and resource (US state and city pay-transparency laws for a job post), including the inputs that drive the answer and what is returned (the statute for each). It is clearly distinct from writer/linter siblings like lint_job_post and write_job_description.

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

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

Usage is implied by the resource scope (you call it when you need to know which pay-transparency laws apply to a post), but there is no explicit when-to-use, when-not-to-use, or named alternative such as lint_job_post for general compliance-style checks. 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?

Annotations already declare a safe read-only, idempotent, non-destructive call, so the bar is lower; the description still adds real value by disclosing the 12-month horizon, the uniform formula across options, and the publisher's conflict of interest as a staff augmentation firm. It stops short of describing the output shape, but that is partially excused by the absent output 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 sentences, front-loaded with the core comparison, then the methodology and bias disclosure. Every clause earns its place; nothing 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?

For a read-only tool with full parameter coverage and annotations carrying the safety profile, the description is nearly complete. The one gap is that no output schema exists and the description does not hint at what the comparison returns, which an agent would want to know.

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

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

Schema coverage is 100%, so the schema already documents both parameters and the baseline is 3. The phrase 'on your own numbers' loosely ties to the numbers parameter but adds no format or syntax detail beyond what the schema provides.

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 (compare) and a precisely enumerated resource (12-month cost and risk across six named hiring models), so the agent knows exactly what this produces. Nothing in the sibling list overlaps this resource, so it is distinguishable despite not naming a sibling 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 description never states when to reach for this tool versus the many adjacent hiring tools (check_hiring_fit, explain_ruzora_terms, start_honest_read). 'On your own numbers' hints at a prerequisite but gives no when-to-use or when-not-to-use guidance.

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

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

Annotations already declare the mutation/open-world/non-idempotent profile, and the description meaningfully adds to it: the result is a buyer_token valid 7 days, a Sol account is opened, and the email plus code are transmitted to Ruzora (a noteworthy data-disclosure behavior consistent with openWorldHint=true). It does not cover failure modes or whether the code is consumed on retry, so not a 5.

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

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

It is a single dense sentence with no filler, which is efficient, but the grammar is tangled ('the 6-digit code ... becomes a buyer_token') and the actual action is buried after the outcome, making it harder to parse than a short imperative lead would be.

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 returned artifact (buyer_token, 7-day validity) and the account side effect, and it covers the two invocation modes for the 3 parameters. It omits error/edge handling (expired code, already-used verification_id, mismatch with verify_work_email), which keeps it from being 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%, and the schema already explains that code is the 6-digit email code, work_email must match verify_work_email, and verification_id comes from that tool. The description restates the same facts rather than adding format, constraint, or fallback semantics, 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 frames this as 'Step 2' of the email verification flow and names its sibling verify_work_email as the source of verification_id, so an agent can place it in the sequence. However, the action verb is never stated directly (the sentence's subject is 'the 6-digit code'), so the purpose is inferred from the title plus the flow position rather than cleanly declared.

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

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

It gives concrete routing: pass code + verification_id together, or verification_id alone once the user has clicked the confirmation link. That is real when-to-use guidance tied to the sibling tool. It stops short of stating prerequisites or what to do on failure (e.g., expired or wrong code), so it is not fully explicit.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false, so the safety profile is covered. The description adds only marketing framing ('Fixed-price development by senior LATAM engineers') and says nothing about what happens after submission, expected response time, or any side effects of the open-world write — the exact context that would earn credit here.

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 actionable purpose. The second sentence is largely promotional but occupies little space, so the cost is minor.

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 full schema coverage and annotations carrying the behavioral profile, the description is minimally adequate for a 6-parameter lead-capture tool. It nevertheless omits what an agent would want to set expectations: that budget and timeline are optional, and what the submission triggers.

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

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

Schema description coverage is 100%, with all six parameters documented including two enums, so the baseline is 3. The description contributes no additional parameter meaning beyond re-stating that a project is being requested.

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 and resource: requesting a custom software project from Ruzora's Software Factory. The nature of the inquiry (custom project work) implicitly separates it from siblings like create_hiring_lead and request_demo, though the description never names or contrasts those alternatives.

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 prerequisites, and no mention of alternatives such as request_demo or create_hiring_lead. The agent must infer from the name alone whether this is the right lead-capture tool for a given user intent.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context about the deliverable's composition (hidden rubric, follow-up conversation, seeded-bug review), though it says nothing about determinism, length limits, or how the hidden rubric is surfaced.

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 opening with the purpose, followed by the differentiating detail. It is dense with comma-separated option lists, slightly more than strictly necessary, 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 read-only generative tool with no output schema and fully described parameters, the description covers the main design approaches and the expected artifacts. It leaves minor gaps on output shape and scope limits, but an agent has enough to invoke it correctly.

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

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

Schema coverage is 100% with three well-documented params (role, stack, details), so the schema carries the weight. The description adds no parameter-level meaning beyond that, which is the expected baseline when structured fields are complete.

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 ("Design a coding test") with an explicit qualifier ("that still works when candidates have AI") and concrete design patterns (seeded-bug review, extend-a-codebase, paid trial). This clearly separates it from siblings like send_coding_challenge (which ships a challenge) and developer_interview_questions (which writes questions).

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 AI-resilience framing — you reach for this when authoring a hiring assessment — but there is no explicit when-to-use/when-not statement and no sibling alternative named. An agent must infer that this designs rather than sends a challenge.

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

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

Annotations already cover read-only, idempotent, non-destructive and closed-world, but the description adds the human-in-the-loop semantics that annotations cannot express: it flags rather than acts, and explicitly 'never rejects'. That is meaningful context about what the tool will and won't do. It stops short of describing output shape or threshold/confidence 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 dense sentence with the action front-loaded, followed by the behavioral guarantee. No filler, and the most decision-relevant facts (what it detects, that it only flags) come first.

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 carries more of the return-value burden; it tells the agent the result is a human-facing flag but not the structure or severity levels. For a two-parameter detection tool with full annotation coverage, this is nearly complete but leaves the agent guessing at the response shape.

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 are documented in the schema, so the baseline is 3. The description's mention of invisible characters loosely corresponds to the hidden_segments parameter but adds no format or usage detail beyond what the schema already provides.

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 (check/detect) on a specific resource (resume text) and enumerates exactly what it looks for: prompt injection ('ignore previous instructions'), invisible characters, and keyword stuffing. This clearly distinguishes it from siblings like triage_resumes and check_identity_risk, which handle routing and identity rather than adversarial content.

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 when-to-use condition ('before any AI reads it') and states the downstream behavior ('Flags for a human; never rejects'). It does not explicitly name the alternative tools or state when NOT to use it, but the timing guidance is strong enough to route the agent correctly.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuine content-level transparency (the kit includes answer-quality and bluff-detection cues plus follow-up ladders), but says nothing about output volume, format, or generation 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?

A single dense sentence that front-loads the audience and then enumerates deliverables via a colon list. Every clause carries information and nothing is 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 two-parameter, annotation-covered, read-only tool with no output schema, the description is adequate about what it returns. It falls short on sibling disambiguation (build_interview_kit) and on any indication of depth, length, or relationship to downstream tools like score_interview_notes.

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

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

Schema description coverage is 100%, with both 'role' and 'details' documented, so the schema does the heavy lifting. The description only vaguely echoes this with 'tailored to the stack and level', adding no new syntax or constraint guidance beyond what the schema already states.

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

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

The description names the artifact produced (questions, strong-answer/bluff signals, follow-up ladders) and the intended audience, so an agent can tell it apart from design_coding_assessment or score_interview_notes. However, it never disambiguates against the very similar sibling build_interview_kit, which appears to produce an overlapping artifact.

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

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

There is no explicit when-to-use or when-not-to-use guidance and no prerequisite/ordering information. Given the near-duplicate sibling build_interview_kit in the tool list, the omission of any routing hint is a real gap.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered structurally. The description adds one useful provenance note ('from the published terms'), indicating the answers are authoritative, but says nothing about format, length, or fallback behavior when a term is absent.

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 resource immediately and then enumerates the subject matter, with no filler. It is dense but each clause corresponds to a distinct enum value, so 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, but the description enumerates the topics covered, which effectively communicates what the tool returns. Combined with the read-only annotations, an agent has enough to invoke it correctly; only return-format details are unaddressed.

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

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

Schema coverage is 100% and the enum labels are self-describing, so baseline would be 3. The description goes further by unpacking what the topic values actually cover (e.g., 'commitment' = 90-day initial commitment and notice; 'guarantee' = 60-day replacement guarantee and its limits), letting an agent map a user question to the right topic without guessing.

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 (explain Ruzora's standard terms) and enumerates the exact content: pricing model, 90-day commitment and notice, 60-day replacement guarantee and limits, refunds, warranty, speed, engagement start. An agent can tell this apart from the hiring-oriented siblings at a glance without opening any 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 content scope implies when to use it (questions about Ruzora's terms), but there is no explicit when-to-use, when-not-to-use, or named alternative. It is adequate but the routing guidance 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety and determinism profile is fully covered structurally. The description adds content-scope context (what subject areas the static payload covers), but says nothing about return format, length, or freshness of the information.

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; the content enumeration is the only substantive information. 'Comprehensive' is slightly redundant with the enumerated list that follows, but the sentence 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 no-argument, read-only lookup with no output schema, the description is adequate: it names the subject areas returned so the agent can decide relevance. It could be improved by stating that no inputs are needed and roughly what form the response takes.

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

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

The tool takes zero parameters, so there is no parameter semantics to document and the baseline is 4. The description correctly does not invent parameter behavior.

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 (Get) and resource (company info) plus the exact content domains returned: services, process, value proposition, and differentiators. It is clearly distinct from the action-oriented siblings (create_factory_inquiry, submit_candidate_application), though it does not name them explicitly.

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

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

Usage is only implied: an agent can infer this is the tool for questions about the company itself rather than roles or inquiries. There is no explicit when-to-use statement, no exclusion, and no pointer to sibling tools for adjacent questions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety and idempotency profile is fully covered structurally. The description's only added behavior is naming the fields returned, which is modestly useful given there is no output schema, but it discloses nothing about lookup failure behavior (e.g., unknown slug).

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 a verb, resource, and payload; every clause earns its place and nothing is redundant.

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

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

For a simple single-parameter read tool with complete annotations and full schema coverage, the description is adequate; naming the returned content compensates partially for the absent output schema. A note on unknown-slug behavior would make it 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% and the slug parameter is documented with concrete examples ('devops-engineer', 'ai-engineer'). The description adds no additional meaning beyond what the schema already provides, 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?

States a specific verb and resource ('Get detailed information about a specific job role') and names the payload (responsibilities, requirements, tech stack). It is clear on its own, but does not distinguish itself from the sibling list_open_roles, which an agent could plausibly confuse with it when browsing roles.

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 'slug' parameter signals a single-record lookup, presumably after finding a role elsewhere. There is no explicit statement of when to use this versus list_open_roles, and no note that the slug must already be known.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and non-destructive, so the safety profile is covered. The description adds real behavioral value beyond that by naming the four possible statuses and noting that scores appear only once the report is delivered, which tells the agent what state transitions to expect.

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 filler, front-loading the purpose and closing with the required input. 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 the possible return states and the score-delivery condition. Combined with the annotated safety profile and a fully documented single parameter, an agent has everything needed to call and interpret this tool.

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

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

Schema coverage is 100% and the single parameter is fully documented there, including the 'or its token' shorthand. The description's 'Pass the status page URL' restates the schema without adding format, source, or validation detail, so baseline 3 applies.

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

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

States a specific verb and resource ('Check progress on a coding challenge you sent through Ruzora') and even enumerates the outcome space (not started, in progress, finished, expired, plus scores). An agent can distinguish this from send_coding_challenge or design_coding_assessment without opening any 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 phrasing implies the prerequisite clearly: you already sent a challenge and received a status page URL, and 'Pass the status page URL' tells the agent what input is needed. It gives no explicit exclusions or named alternatives, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: 'Deterministic; nothing stored' tells the agent results are reproducible and the post text is not persisted, which matters for pasting sensitive drafts. It could go further on what the fix list contains beyond examples.

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?

Single front-loaded sentence: the action ('paste any job post and get a fix list') leads, followed by the itemized checks and a compact behavioral clause. The enumeration is informative rather than filler, though it is slightly 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?

With no output schema, the description carries the return-value burden and does so by describing a 'fix list' with representative entries. Parameters are fully schema-documented and annotations cover safety. Minor gap: no detail on fix-list format or ordering.

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 all three parameters are documented in the schema, so the baseline is 3. The description implies the role of 'locations' via 'pay range where required' but adds no syntax or format detail beyond what the schema already provides.

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 ('lint/check a job post') and enumerates the exact defect classes it detects (pay-range, citizenship restrictions, coded language, salary-history asks, must-have overload). This is clearly distinguishable from siblings like write_job_description or check_pay_transparency, which write or narrowly check pay rather than lint the whole post.

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 phrasing 'Paste any engineering job post' implies the usage context, but there is no explicit when-to-use, when-not-to-use, or comparison to the adjacent check_pay_transparency and write_job_description tools. The agent must infer routing from the stated scope alone.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds value beyond that by disclosing the returned payload (titles, tech stacks, experience levels, application URLs), which is meaningful since no output schema exists.

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

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

Two tight sentences with no filler, and the scope (all currently open engineering roles) is front-loaded before the return-value detail. Every sentence 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?

With no parameters, full annotation coverage of the safety profile, and return fields documented in lieu of an output schema, the definition is largely complete. The only gap is the absence of guidance about how this differs from get_job_details.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify; the baseline for a parameterless tool is 4. No misleading or missing parameter information is present.

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 (Get) and resource (currently open engineering roles at Ruzora), with clear scope via 'all'. It is distinguishable from get_job_details in spirit (list vs single), though it never names that sibling 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 name and scope — call this to enumerate open roles — but there is no explicit when-to-use guidance, no exclusions, and no pointer to get_job_details for per-role information. The agent must infer the routing.

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

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

Annotations already establish the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false), so the agent knows this is a safe, side-effect-free planning operation. The description adds that the output is a plan with three named components, which is useful context beyond the annotations, but it says nothing about prerequisites or data sourcing.

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 resource and then listing its parts; no filler. The colon-list structure is a bit terse 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?

With no output schema, the description reasonably compensates by naming the three deliverables the plan returns, and both inputs are fully documented in the schema. It is largely complete for a plan-generation tool, though it omits any indication of scope limits or the data the plan draws on.

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

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

Schema coverage is 100% with two well-described string parameters, so the schema already carries parameter meaning and the baseline is 3. The description does not reference the parameters at all, so it adds no syntax or format detail beyond the schema.

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

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

The description names a specific resource (a reference-check plan) and enumerates its three concrete deliverables: referee verification, a call script, and a risk register. It is distinctly different from siblings like build_interview_kit or score_interview_notes, though it never explicitly contrasts itself with them.

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

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

There is no explicit when-to-use or when-not-to-use guidance; the phrase 'for an engineering finalist' hints at the hiring stage but reads as a description of the output rather than a routing condition. No alternative tools are named for adjacent needs.

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

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

Annotations already declare the write/open-world/non-idempotent profile. The description adds real value on top: it discloses that a fit check gates the outcome, that a booking link is returned only when it fits, and that the supplied name, email and company are transmitted to Ruzora. It does not mention the buyer_token prerequisite or error behavior, which the schema covers.

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 that front-load the audience and intent before the mechanics. Minor marketing padding ('fixed price, milestones') is the only waste, but it does convey commercial context cheaply.

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, no-output-schema lead tool, the description covers the key unknowns: it tells the agent a booking link is the return value and that fit is conditional. The buyer_token prerequisite is left entirely to the schema, and the not-a-fit path is only implied, keeping it just short of 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 every parameter, enum value, and the buyer_token flow is already documented in the schema. The description only echoes 'budget, timing' and 'name, email and company' without adding format or validation meaning, 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?

The description names a specific action (request a scoping call), the provider (Ruzora's Software Factory), and the two qualifying intents (new build, rescue). It is clear what the tool does, but it never distinguishes itself from the sibling create_factory_inquiry, leaving that routing decision 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?

It gives clear target-audience context ('anyone who wants an app or software built, or a failing app or agency project rescued') and states the qualifying condition (fit on budget/timing). There are no explicit exclusions or named alternatives, so it stops short of full routing guidance.

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

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

Annotations already flag readOnlyHint=false, idempotentHint=false, openWorldHint=true, so the agent knows this is a mutating, open-world call. The description adds meaningful context beyond that: a 72-hour turnaround promise, blind profiles until an agreement is signed, and an explicit data-disclosure note that the provided name/email/company are sent to Ruzora.

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

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

Three compact sentences, front-loaded with the core action and scope, then turnaround/blind-profile terms, then the data-sharing disclosure. No filler, though the phrasing is slightly telegraphic ('Sends the name, email and company given to Ruzora').

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 output schema, the description covers the key expectations an agent needs: fulfillment time, blind-profile condition, required contact channel, and data handling. It stops short of naming the sibling it replaces or the exact confirmation returned after submission.

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 one of the 11 parameters is already documented in the schema, setting a baseline of 3. The description reinforces only the work-email requirement and the role-scorecard note, adding no syntax or format detail beyond what the schema provides.

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 (request) and resource (shortlist of vetted senior engineers in Latin America), plus the qualifier that it should come from a role scorecard. This clearly distinguishes it from a generic get, but it never names or contrasts the closest sibling (search_vetted_engineers), so differentiation is by inference rather than explicit routing.

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 implied usage context ('ideally from a role scorecard') and a prerequisite ('needs a work email'), but never states when to use this versus search_vetted_engineers or get_vetting_status. The agent must infer the selection condition from field descriptions rather than the description itself.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorld=false, so the safety profile is covered. The description adds meaningful substance beyond that: it discloses the review's components (quality signals, authorship checks, risky-function trace, probing questions) and that output is plain-English for a non-technical audience.

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 states the action, the audience, and the deliverables with no filler. The colon-list is dense but the length is appropriate and every clause carries information.

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

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

With no output schema, the description carries the burden of describing returns, and it does so by naming the four review components, so an agent knows what comes back. Given only two well-documented parameters and full annotation coverage, the remaining gap (e.g., length or depth of the review) 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 role and code_or_repo are fully documented in the schema itself, establishing the baseline of 3. The description echoes the input surface ('GitHub repo or code sample') but adds no format, length, or content guidance beyond what the schema already states.

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 and resource and enumerates the concrete outputs (quality signals, authorship checks, risky-function trace, revealing questions), which clearly separates it from siblings like detect_resume_injection or design_coding_assessment. An agent can tell what it does 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?

States the target scenario explicitly ('for non-technical hirers' reviewing a candidate's GitHub repo or code sample), which gives a clear usage context. It stops short of naming when to prefer it over adjacent tools such as detect_resume_injection or design_coding_assessment, so no exclusions or alternatives are 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?

Annotations declare non-read-only, non-idempotent, open-world writes; the description usefully adds that it sends role details to Ruzora and requires a verification token. It does not disclose what saving overwrites, whether the role becomes public, 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?

Two compact sentences, front-loaded with the primary action and workspace, followed by prerequisites and remote effect. Efficient, though it crams multiple ideas into one sentence.

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

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

Covers purpose, destination, remote side effect and auth prerequisite for a mutation tool with rich schema and annotations. Without an output schema it reasonably omits return values, and mutation semantics remain partly implicit.

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

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

Schema coverage is 100%, so all six parameters (including buyer_token, work_email, title, stack, notes, seniority) are already documented with formats, maxLengths and an enum. The description only names the buyer_token token, adding little 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 (Save) and resource (role) into a named workspace, clarifying what Sol is ('Ruzora's hiring agent') where shortlists/documents collect. This distinguishes it from siblings like build_role_scorecard or list_open_roles, though it doesn't explicitly contrast with create-role-like alternatives.

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

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

Implies usage by noting the buyer_token prerequisite from confirm_work_email and pointing to verify_work_email, but gives no explicit when-to-use vs alternatives or when-not-to-use 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is the output shape — scorecard per interviewer plus debrief with evidence, disagreements and bias flags — and the explicit statement that the tool does not render the hiring decision. That is meaningful beyond the annotations, though it says nothing about note-quality failure modes or length limits.

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

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

Two sentences, both earning their place: the first front-loads the transformation and the deliverables, the second states the decision boundary. No filler or restatement of the title.

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

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

With no output schema, the description does the work of describing returns (scorecard per interviewer, debrief memo with evidence, disagreements, bias flags), which is the key gap it needed to fill. Minor omission: zero required parameters, so the agent gets no guidance on what happens if notes or must_haves are absent.

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 (notes, must_haves) are already documented in the schema and the baseline is 3. The description echoes the 'per interviewer' labeling convention but adds no format, size, or handling guidance beyond what the schema already states.

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 ('turn raw interview notes into') plus two concrete deliverables: an anchored scorecard per interviewer and a debrief memo with evidence, disagreements and bias flags. This clearly separates it from siblings like build_role_scorecard (constructs a scorecard from role inputs) and check_hiring_fit (evaluates fit), so an agent can route without opening schemas.

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

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

Usage is implied by the described inputs (raw interviewer notes plus must-haves), and 'You make the decision' signals the human-in-the-loop boundary rather than when to pick this tool. It never names a precursor like build_role_scorecard or an alternative such as check_hiring_fit, so the agent must infer sequencing and selection.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds genuinely useful behavioral context the annotations do not: results are 'blind' (anonymized candidate profiles), only pre-vetted and currently-available engineers appear, and the pool is geographically constrained to Latin America. It omits result-count/pagination behavior, but the page parameter carries that.

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 the returned resource ('blind profiles of senior engineers... available now') and only then lists the filters. Every clause earns its place; nothing is padded or repeated from the title.

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

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

With no output schema, the description must signal what comes back, and it does (blind vetted profiles, availability, region). Combined with annotations covering safety and a fully documented input schema, an agent has enough to call this correctly; only the shape/size of the returned list is left unstated.

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

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

Schema description coverage is 100%, so the schema already documents stack, level, page and min_overlap_hours with types, bounds and enums. The description restates the filter dimensions ('stack, level and US-hours overlap') without adding syntax, defaults, or semantics beyond the schema. Baseline 3 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?

States a concrete resource (blind profiles of senior engineers in Latin America who passed Ruzora's coding and interview vetting and are available now) plus the filterable dimensions, so the agent knows exactly what it returns. It stops short of naming or contrasting against a sibling such as request_vetted_shortlist or check_market_supply, which is the only thing separating this from a 5.

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

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

The description characterizes the result set but never says when to reach for this tool versus the many adjacent sibling tools (request_vetted_shortlist, check_hiring_fit, check_market_supply). No exclusions, prerequisites, or alternative routing are provided; the agent must infer usage from the resource description alone.

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

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

Annotations confirm this is a non-read-only, open-world, non-idempotent write. The description adds genuinely useful behavior beyond that: data is sent to a third party (Ruzora), the assessment is free and ~25 minutes, and the candidate must be informed. It stops short of describing permission/auth implications or repeat-call 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 dense sentences with no filler; the value proposition and prerequisites are front-loaded. It is compact for the amount of information conveyed, though slightly cramped.

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 10-parameter, non-idempotent, open-world tool with no output schema, the description covers purpose, runtime/cost, data recipients, prerequisites, and return values. It is largely adequate, with the main gap being how errors or the buyer_token flow are handled at call time.

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 10 parameters are already documented, including the buyer_token's dependency on confirm_work_email. The description only loosely echoes some inputs ('both names, the email, company and profile links') and adds no syntax or format meaning. 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: sends Ruzora's coding challenge and technical questions to a candidate, and names what comes back (candidate link + status link). It is clearly distinct from build/design assessment siblings, 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 context is implied ('on a candidate the user found') and one prerequisite is stated (the user must confirm the candidate knows). It does not state when not to use this tool, nor does it route to verify_work_email/confirm_work_email for the buyer_token, which only appears in the schema.

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

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

Annotations already cover readOnly, idempotent, openWorld and non-destructive, so the safety profile is settled. The description adds meaningful behavior the annotations cannot: the call returns an *interview for the AI to run* rather than the analysis itself, and it names the downstream artifacts (Idea Read, verdict, PDF). With no output schema, this disclosure is valuable; only auth/rate-limit details are absent.

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 colon-led sentence that front-loads what the tool is before describing the return value, with no filler. It is slightly dense, packing the interview mechanic plus three artifact types into one clause, 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 one-optional-param, read-only, non-destructive tool with rich annotations, the description covers the key unknown: what comes back (an interview to run) and what it feeds into (Idea Read, verdict, PDF), which compensates for the missing output schema. Routing relative to sibling tools is 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?

There is a single optional parameter with 100% schema description coverage, so the schema already documents 'idea' fully. The description's phrase 'the idea in the user's words' loosely echoes the schema's wording but adds no format, length, or defaulting guidance beyond it, matching the baseline 3 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?

States a specific verb ('Start') and resource ('Honest Read') and explains the product jargon by defining it as a 'free scoping interview for an app or software idea'. An agent can tell this initiates an interview rather than evaluating an idea, though it never explicitly contrasts with submit_honest_read or build_interview_kit.

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 context is implied by 'for an app or software idea' and 'free scoping interview', so an agent knows the domain. However, there is no explicit when-to-use, no exclusions, and no named alternative among the 33 sibling tools (e.g., when to call submit_honest_read or request_project_scoping_call instead).

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

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

Annotations already flag this as a non-read-only, open-world, destructive-intent write, but the description adds genuine context the annotations cannot: that submitted details are transmitted to a US-hosted recruiter and that submission constitutes consent, with a privacy link. It does not explain post-submission behavior (confirmation, follow-up), which keeps it out of 5 territory.

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

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

Three short sentences, front-loaded with the core action, then eligibility, then the consent notice. Every sentence carries distinct information, though the privacy sentence is slightly detached from the rest.

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 write tool with no output schema and a fully documented input schema, the description covers audience, consent, and data residency. It leaves the agent without any notion of what a successful submission returns or what happens next, but nothing required to invoke it correctly is missing.

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

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

Schema description coverage is 100% and all 7 fields carry their own descriptions, so the schema does the heavy lifting. The description adds only indirect meaning about role targeting, which loosely maps to role_category, so the 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 ("Apply to Ruzora's talent network") and narrows the audience to LATAM software engineers seeking remote US-startup roles. It is clearly distinguishable from siblings like create_hiring_lead or request_demo, 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?

Gives a concrete eligibility condition (software engineers in LATAM interested in remote USD positions with US startups), which tells the agent when this tool applies. It stops short of stating when not to use it or which sibling to pick for non-matching users.

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

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

Annotations already declare non-read-only, open-world, non-idempotent, non-destructive behavior, so the bar is lower. The description adds real value by disclosing that the email, first name, and Idea Read are transmitted to a third party (Ruzora) and that the report arrives by email; it could still note that a repeated call re-sends/re-runs rather than returning the same result.

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

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

Front-loaded and short, but the third sentence ('Sends the email, first name and Idea Read given here to Ruzora, which uses them to send the report') largely repeats the first sentence's content, so not every sentence fully 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?

With no output schema, the description usefully explains what comes back (a keep-going/one-developer/small-team verdict) and how (PDF by email), and it names all three inputs. It is essentially complete for a 3-param submission tool, missing only idempotency/resubmission behavior.

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 3 is the baseline, but the description adds meaning: it clarifies the email is only a delivery address ('Any email works'), that first_name is used in the report, and that idea_read_markdown is the full interview output. That is modest but genuine value beyond the schema text.

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

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

States a specific verb and resource — send the AI-written Idea Read to Ruzora for a verdict plus PDF — and names the sibling that produces the input (start_honest_read), so an agent can distinguish it from the other 30+ tools. The verdict categories are even enumerated.

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

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

It clearly places the tool after start_honest_read ('the Idea Read your AI wrote') and notes 'Any email works,' which resolves a likely prerequisite worry. It stops short of explicit when-not-to-use guidance or warning against resubmitting an already-submitted read.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower. The description still adds real value by disclosing the non-decisional stance ('Organizes evidence; never rejects anyone for you') and the hidden-text flagging behavior, which an agent cannot derive from the annotations.

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 feature set, then a single boundary clause. No filler; every clause carries information.

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

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

With 3 well-documented parameters, no output schema, and full annotation coverage, the description is nearly complete: it states purpose, outputs, and the non-rejection boundary. It could say a bit more about the shape of the evidence output, but nothing essential for invoking it correctly is missing.

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

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

Schema description coverage is 100%, so the schema fully documents resumes, blind_mode, and must_haves, making 3 the baseline. The description references must-haves and blind mode but adds no format or syntax detail beyond what the schema already provides.

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 ('Screen engineering CVs') and enumerates the concrete outputs (evidence scores, blind mode, hidden-text flags, screening-call questions), so an agent knows exactly what the tool produces. It does not explicitly differentiate itself from siblings like detect_resume_injection or check_hiring_fit, which is the only thing keeping it below 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?

Usage is implied by the purpose (screening CVs against must-haves) and the closing boundary ('never rejects anyone for you') clarifies the tool's advisory role. However, it never says when to reach for this versus sibling tools such as detect_resume_injection or score_interview_notes, so the agent must infer the routing.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds genuine value by disclosing what the check returns (realness, stack coverage, vetting date), which matters because no output schema exists.

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

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

Two tight sentences with no padding; the purpose and its returned information are front-loaded before the brief input note.

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 describes what a caller learns back, which is the main completeness risk for this tool. It remains implicit about error behavior for an invalid or expired badge, keeping it just short of full completeness.

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 'badge' parameter is fully documented as a UUID or verification URL. The description merely restates that accepted input without adding format or edge-case detail, 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 (check/verify) and resource (Ruzora Vetted badge) and enumerates what the result reveals: validity/currency, covered stacks, and vetting timestamp. It does not, however, differentiate itself from the sibling get_vetting_status, so an agent must infer which to pick.

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

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

The only guidance is 'Pass the badge ID or badge URL,' which is an input instruction rather than a when-to-use rule. There is no statement of when this tool is preferred over get_vetting_status or check_identity_risk, so usage is only implied.

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

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

Beyond the annotations, it discloses the external side effect that the email address is sent to Ruzora (openWorldHint=true is corroborated rather than merely repeated) and describes the two-step code round-trip, which explains why idempotentHint=false matters. It still doesn't mention code expiry or resend limits, but it adds real context the structured fields lack.

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 clauses, flow position front-loaded, no filler. Every sentence carries distinct information: when to call, what it sends, and who consumes the result.

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

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

For a two-parameter tool with no output schema and full annotation coverage, the description covers the prerequisite role, the side effect, and the handoff to confirm_work_email. Only the failure/retry path (expired or mistyped codes) is absent.

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, including the for_tool enum and its purpose, are already fully documented in the schema. The description only alludes to work_email ('emails the user'); it adds no syntax or format detail beyond what is structured. 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 action (emails a 6-digit code plus confirm link) and its position in the flow ('Step 1 before a Ruzora action that needs a verified buyer'). It clearly separates itself from the sibling confirm_work_email, which is named as the tool that takes the code back.

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

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

Explicitly says to call this first, before any action requiring a verified buyer, and names confirm_work_email as the required follow-up. It does not say what to do if the buyer is already verified, so the when-not condition is left implicit.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the write-vs-read ambiguity is worse than it looks: the tool is annotated as a non-mutating, idempotent operation even though its name implies authoring. The description adds useful context that the output includes a compliance check (pay range rules by location, citizenship wording, exclusionary language, requirement inflation), which is behavior beyond the annotations. It does not say whether anything is persisted, so the name/annotation tension is never resolved.

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 dense sentence that front-loads the verb and resource and then packs four compliance dimensions into a colon list. It is efficient but the list feels like feature enumeration rather than guidance, and the core drafting behavior (output format, sections) is never 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?

Enough to know what the tool roughly does and that it returns a compliance check, but with no output schema the description should say more about what comes back (a draft? a report? both?) and how it relates to lint_job_post. For a content-generation tool in a crowded sibling set, that is a real 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 100%, so the schema already documents both params, including that details accepts a scorecard/notes with ownership, stack, team, pay range, remote rules, locations and benefits. The description lists the compliance dimensions but adds no parameter syntax or format information beyond the schema. Baseline 3 is appropriate.

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

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

The description states a specific verb (Write) and resource (software engineer job post), and adds secondary scope (compliance check) that distinguishes it from the closest sibling lint_job_post. It doesn't explicitly name alternatives, but the purpose is clear and specific.

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

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

No when-to-use guidance and no exclusions. The overlap with lint_job_post is left unresolved; an agent cannot tell from the description whether drafting (this tool) vs. reviewing an existing post (lint_job_post) is the intended split, or whether both should be run.

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