100Hires - AI ATS & Recruitment Software

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

Annotations indicate a non-read-only, non-destructive mutation, but the description adds no behavioral detail beyond that. It doesn't say whether tags are appended, deduplicated, or if non-existent tags are auto-created, nor does it mention error or idempotency behavior.

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

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

The description is a single, fluff-free sentence that gets to the point. It is short and clear, though so brief it adds little beyond the tool name.

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

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

With siblings hires_batch_add_tags and hires_remove_candidate_tag, the description should specify when to use this single-candidate tool vs. alternativesGu. It also omits whether tags are appended or replaced, and what side effects occur. No output schema or additional context compensates.

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 schema documents the 'id' parameter, and the 'tags' parameter is described as an array of strings without further semantics. The tool description clarifies the verb 'add' but doesn't explain tag uniqueness, case sensitivity, or whether unknown tags are created — leaving the agent to guess.

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, specific operation ('Add tags to a candidate') that matches the tool name. However, it does not differentiate this from the sibling hires_batch_add_tags, so an agent comparing tools would not know the scope/single-target intent without extra reasoning.

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 guidance is given on when to use this tool versus hires_batch_add_tags, hires_remove_candidate_tag, or other tag-related tools. The description provides no context about bulk vs. single-candidate operation, or what should happen if a tag already exists.

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 and destructiveHint=false, indicating a mutation that is not destructive. The description adds no behavioral context beyond restating the action, such as side effects, permission requirements, or idempotency. With annotations covering safety, the description contributes little extra value.

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

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

The description is a single sentence, which is concise and easy to parse. However, it is so minimal that it borders on under-specification, providing almost no informative content beyond the tool name. It's not verbose, but it lacks substance.

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

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

For a mutation tool with no output schema, the description should explain what the expected outcome is, whether it's idempotent, and any relevant return values. None of this is mentioned. Given the tool's simplicity, the description is incomplete for an agent to confidently invoke it without further context.

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 50%: 'id' is described as 'Job id or alias', but 'user_id' has no description. The description vaguely maps 'company user' to user_id and 'job' to id, but doesn't clarify what user_id represents (e.g., a company user ID) or provide any additional semantics. It fails to compensate for the missing schema description of user_id.

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

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

The description clearly states the action (Add), the resource (a company user), and the target (the job's hiring team). This is a specific verb+resource combination that distinguishes it from other add tools like hires_add_candidate_tags, though it doesn't explicitly name an alternative. The purpose is unambiguous.

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

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

The description provides no guidance on when to use this tool versus alternatives, such as hires_list_hiring_team for viewing the current team or other add tools. It doesn't mention prerequisites, expected use cases, or when not to use it.

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

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

Annotations already declare destructiveHint=true and openWorldHint=true, covering the mutating nature. The description adds that the stage is determined by workflow order and that stage_id is unnecessary, providing behavioral context beyond the annotations, though it omits side effects like notifications.

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

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

A single sentence with the action verb front-loaded and the critical detail (no stage_id) included without extra words. Every word earns its place.

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

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

For a simple two-parameter mutation tool with annotations covering safety, the description is adequate for the core operation. However, it doesn't mention return values, side effects, or how to choose this over related tools, leaving some gaps for a fully informed call.

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

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

Schema description coverage is only 50% (include is described, id is not). The tool description does not mention either parameter, failing to compensate. An agent must rely on the schema for include's meaning and has no guidance for id beyond it being required.

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 the verb 'Advance' and resource 'application', plus specific behavior 'to the next stage in workflow order' and clarifies no stage_id is needed. This clearly distinguishes it from sibling tools like move_application and transfer_application without needing to inspect their schemas.

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

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

The description gives a precise action and the key constraint that stage_id is not required, which is useful. However, it does not explicitly say when to use this tool versus alternatives such as move_application or transfer_application, leaving the decision 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 indicate a non-read-only, non-destructive operation. The description adds valuable behavioral detail: the per-item results (implying partial success reporting) and the 100-candidate cap. This goes beyond the annotations and gives agents insight into failure granularity.

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, scope, and key return behavior with zero filler. Every word earns its place.

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

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

For a simple batch operation, the description covers the core aspects: adding tags to candidates, the limit, and per-item results. However, it does not mention potential tag limits, duplicate handling, or error scenarios beyond per-item results, leaving some gaps for a complete understanding.

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 50% – only 'ids' has a description, while 'tags' lacks any description. The description does not compensate by explaining the format or semantics of the tags parameter, despite the moderate coverage gap. The parameter names are self-explanatory, but the description adds nothing beyond that.

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 action ('Add tags'), the target resource ('candidates'), and a scope ('up to 100'), which distinguishes it from the singular hires_add_candidate_tags via the 'batch' implication. However, it does not explicitly name a sibling or clarify when the batch version should be preferred over the singular one.

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

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

The description implies batch usage with the 'up to 100 candidates' limit, giving context for when this tool is appropriate. Yet it offers no explicit exclusions (e.g., for fewer than 100 candidates, use the singular tool) and does not mention alternative tools like hires_batch_remove_tags.

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 show this is a write without destructiveHint, but the description adds a non-structured behavioral trait: 'one failure does not stop the others' – that per-item failure isolation is genuinely useful and not inferable from the schema or annotations. It also communicates that messages are scheduled ('scheduled messages'), another behavior trait. It does not cover rate limits, permission prerequisites, or partial-failure response format, but the presence of annotations and these additions justify a 4.

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

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

The description is one sentence of substantive content: action, scale, and fault behavior. No filler, no redundancy, and the key constraint (up to 100) is front-loaded. Every clause earns its place.

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

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

With a complex nested array schema and no output schema, the description covers the core purpose, item count, and fault model, but omits what the caller sees on failure (per-item results?), potential permissions, and any additional scheduling defaults. It is good baseline for a batch-write but such a thorough tool needs a bit more detail to be 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 0% at the top level, and the description does not explain any of the nested properties (cc, bcc, from_account_id, etc.). With low schema coverage, the description carries more responsibility to clarify the messages array, but it only gives 'scheduled messages' context and the up-to-100 limit; it does not add meaning to any specific parameter. The agent must infer the semantics of `to`, `subject`, `body` and optional fields.

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

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

The description states a specific verb+resource ('Create ... scheduled messages'), the volume limit ('up to 100'), and the single-request scope, which clearly distinguishes it from single-send tools like hires_send_candidate_message. The title correctly completes the resource context, so no agent would confuse this with a non-batch or non-message tool.

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

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

There is no explicit when/when-not guidance or mention of alternatives. The 'in one request' and 'up to 100' imply a batch use case, but the description never names hires_send_candidate_message or any other tool, nor does it say when the agent should stop 'favor' this over a single-send or scheduled message update. These are excluded endpoints that transition outside key meanings.

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 and destructiveHint=false, so the safety profile is covered. The description adds the batch behavior (multiple jobs at once) but doesn't disclose what 'board publication states' includes (e.g., which boards, what statuses) or whether partial failures occur for invalid job IDs. With annotations covering safety, a 3 is appropriate.

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

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

A single sentence that is front-loaded with the verb and resource, and includes the key batch qualifier. Zero wasted words; every element earns its place.

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

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

For a simple read-only batch tool with one fully documented parameter and safety annotations, the description is mostly sufficient. However, it doesn't clarify what 'board publication states' means (e.g., which boards, what statuses are returned), and there is no output schema to fill that gap. An agent might not know what to expect in the response.

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

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

Schema description coverage is 100%: the only parameter 'jobs' is described as 'Job ids' with a number array type. The description adds the semantic that these are used to fetch board publication states, but doesn't add detail beyond the schema. Baseline 3 is correct.

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

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

The description states a specific verb ('Get'), resource ('board publication states'), and scope ('for several jobs at once'), which clearly distinguishes it from single-job variants like hires_get_job or hires_publish_to_job_board. It doesn't explicitly name a sibling alternative, but the batch scope is clear enough to differentiate it from related board tools.

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

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

The description implies when to use it: when you need board publication states for multiple jobs in one call. It doesn't explicitly state when not to use it or name alternatives like hires_list_job_boards or hires_get_job, but the batch phrasing provides adequate context for an agent to select it over single-job tools.

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

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

Annotations already mark the tool as destructive, so safety is covered. The description adds valuable behavior beyond annotations: per-item results, partial success allowed, and a 100-item ceiling. It does not detail failure behavior or reversibility, but the annotation covers the core warning.

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

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

One compact sentence front-loads the batch size and core action, then appends result semantics. There is no filler or redundant restating of the schema.

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

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

For a two-parameter batch operation, the description covers the inputs, the batch limit, and the key outcome behavior. It is slightly incomplete because there is no output schema and the exact per-item result format is not described, but this is 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?

Schema coverage is only 50%, leaving stage_id undocumented. The description maps 'applications' to ids and 'stage' to stage_id, providing some semantic grounding. Still, it does not explicitly confirm that ids are application IDs or describe what kind of stage_id is expected.

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

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

The description states a specific verb and resource: 'Move up to 100 applications to a stage in one request.' It also distinguishes itself from the single-application sibling by emphasizing 'batch' and capacity limits. The scope is immediately clear.

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

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

The description implies when to use it: moving multiple applications in one request. However, it never names the single-item alternative (hires_move_application) or states when not to use this tool, so the agent must infer the routing from sibling names.

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 and destructiveHint=false, so the description isn't responsible for conveying that this is a write operation. The description adds the 'queue' semantic, implying asynchronous enqueueing, and the batch scope, which is valuable. However, it does not disclose side effects, whether operation is asynchronous, authentication needs, or rate limits. With annotations covering the safety profile, the description adds moderate context, earning a 3.

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

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

The description is a single, focused sentence with no filler. It front-loads the core action and objects, making it easy to parse. While the batch operation might benefit from a bit more detail, conciseness itself is well-executed, so it earns a 4 rather than 5 due to slight under-specification.

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 batch mutation tool with two parameters and no output schema, the description is sparse. It does not explain what 'publication' entails, whether the operation is asynchronous, how results are returned, or any constraints (e.g., boards must exist, jobs must be active). The 'queue' hint adds some context, but the description leaves many operational details unaddressed, making it incomplete for an agent to anticipate outcomes.

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

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

Schema description coverage is 100%: the 'jobs' parameter is described as 'Job ids' and 'boards' as 'e.g. indeed, linkedin'. The description adds no additional meaning beyond the schema, which is sufficient given the baseline for high coverage. No further elaboration is necessary.

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

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

The description uses a specific verb ('Queue') and identifies the resource ('several jobs') and target ('given boards'). It clearly conveys a batch operation, which distinguishes it from single-publish tools. However, it does not explicitly reference sibling tools like hires_publish_to_job_board or hires_batch_job_boards, leaving some potential for confusion, so it falls short of a 5.

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

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

The description provides no guidance on when to use this tool versus alternatives such as hires_publish_to_job_board or hires_batch_job_boards. It does not mention prerequisites, conditions, exclusions, or any context where one should prefer a different tool. The agent is left to infer the usage scenario.

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 mark destructiveHint as true Secret. The description adds important behavioral details: batching limit (100), per-item results, and partial success. However, it does not disclose the exact nature of per-item errors or how 'partial success' is reported (e.g., response structure, which item failed). Since no output schema exists, these details are left to the agent's inference, creating a significant gap for a destructive batch operation.

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

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

The description is a single sentence, concise and front-loaded with the core purpose and limits. It covers key points but could be slightly more structured to separate behavior from alternatives individually, though it is appropriately short.

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

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

The tool is a batch destructive operation with no output schemaonics, so the description must fully explain the invocation context. It covers the batch size, optional reason, and partial success, but lacks details on error handling for per-item failures, which is critical for an agent to correctly interpret responses. Given the 'openWorldHint' and destructive nature, more completeness would be expected.

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 describes the parameters (ids array with max 100, rejection_reason_id). The description adds the semantic that 'rejection_reason_id' is optional ('optionally with a reason') and clarifies the batch size limit, which helps beyond the schema. The lack of enum/description for rejection_reason_id's format is minor given the reference to 'hires_list_rejection_reasons' in the schema.

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

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

The description clearly states the verb (reject), the resource (applications), and the batch scope (up to 100). It distinguishes itself from the single-reject sibling (hires_reject_application) by the batch aspect, so it is easily identifiable among siblings.

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

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

The description implies the batch use case (rejecting multiple applications) and mentions 'per-item results' and 'partial success allowed', which conveys behavior but does not explicitly contrast with the single reject alternative (hires_reject_application) or state when to choose one over the other. With the sibling named 'hires_reject_application', a more explicit routing would be helpful.

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 signal destructive and open-world behavior, and the description adds useful context by clarifying that the destructive action is specifically deactivating publication visibility on boards, not deleting jobs. Scoping the effect to 'given boards' is meaningful additional behavioral information beyond the raw destructiveHint.

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

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

The description is one short front-loaded sentence with no filler: it states the action, the target resources, and the scope. Every word contributes to the meaning.

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

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

The description covers the basic operation and the schema is well documented, but there is a notable gap: 'boards' is optional in the schema while the description implies specific boards are always given. It does not explain what happens when boards is omitted, and there is no output schema or side-effect note to fill that vacuum.

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 input schema covers 100% of parameters with descriptions and an example (e.g. indeed, linkedin), so the description does not need to re-explain them. It adds no extra detail about parameter behavior, such as what an omitted boards value means, so the baseline score of 3 is appropriate.

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

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

The description names a specific action ('deactivate publication') on a specific resource ('several jobs on the given boards'), and the batch wording clearly separates it from singular siblings like hires_remove_from_job_board and the opposite operation hires_batch_publish_to_boards. It is unambiguous and immediately actionable.

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 'several jobs' implies this is the batch variant, and sibling names reinforce that, but the description does not explicitly state when to choose this tool over hires_remove_from_job_board or hires_batch_publish_to_boards. There are no exclusions, prerequisites, or alternative routing cues beyond the implied batch context.

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 destructive nature (destructiveHint=true, readOnlyHint=false). The description adds useful context about the 100-candidate cap and per-item result behavior, but it does not disclose permanence, idempotency, or how nonexistent tags are handled.

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

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

A single compact sentence that front-loads the action and scope, with no filler or redundant restatement of the tool name.

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

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

For a destructive batch operation with no output schema, the agent knows the action, capacity, and a high-level return shape. Missing details include the format of tags, how partial versus total failures are communicated, and whether the 100 limit is strictly enforced per request.

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 only 50%: ids are documented but tags are not. The description clarifies that tags are being removed from candidates and implies the ids limit, but it does not explain what tag values should look like or any constraints on the tags array, so it only partially compensates for the schema gap.

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 action ('Remove tags') on a specific resource ('candidates'), includes the batch scope ('up to 100'), and announces per-item results. This clearly differentiates it from the singular sibling hires_remove_candidate_tag.

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 batch limit of 100 candidates implies usage for multi-candidate tag removal, and the sibling set includes hires_remove_candidate_tag as the singular alternative. However, the description never explicitly states when to choose this tool over alternatives or when not to use it.

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

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

Although annotations already declare destructiveHint=true, the description adds critical nuance: it clearly states that sent notifications are unaffected, which is a key behavioral detail that prevents misinterpretation of destructive scope. This goes beyond the simple 'cancel scheduled notifications' title and provides valuable context about what is preserved.

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

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

The description is a single, concise sentence that conveys the core action (cancel scheduled emails), the scope (all scheduled for a candidate), and a key exception (sent ones unaffected). No filler or repetition; every part earns its place, and the important nuance is front-loaded.

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

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

Given the tool has only one parameter and no output schema, the description sufficiently covers the action and its behavioral scope. It is complete enough for an agent to understand the tool's effectyahoo without additional context. However, it could briefly mention that only scheduled, not sent, notifications are affected, which it does. The lack of alternative tool guidance slightly reduces completeness, but for a simple cancel operation, it is adequate.

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

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

The schema already provides full coverage (100%) for the single parameter `candidate_id` with its description 'Candidate id or alias'. The tool description adds no additional semantic meaning about the parameter, such as how the alias is resolved or any constraints. Since the schema carries the burden, a baseline of 3 would be expected, but the description fails to add even marginal context, so a score of 2 is warranted for lack of added value.

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

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

The description clearly states the tool cancels all scheduled notification emails for a candidate, and explicitly notes that sent ones are unaffected, distinguishing its scope from related operations like deleting or updating individual notification messages. However, it does not explicitly differentiate from the sibling `hires_delete_notification_message`, though the description implies a bulk cancellation versus a single delete.

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

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

The description implies when to use this tool (to cancel scheduled notifications for a candidate) but does not provide explicit guidance on when not to use it or alternatives. Given the sibling `hires_delete_notification_message`, the tool could benefit from noting that this is a bulk operation for all scheduled messages, not a per-message delete. The description is clear about the effect but lacks exclusion 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 indicate readOnlyHint=false and destructiveHint=false, so this is a non-destructive write operation. The description adds no further behavioral details such as stage defaulting or side effects, which are partially covered by stage_id's schema description. It is consistent with annotations but contributes no new context.

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

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

A single sentence with zero fluff, leading with the action. It is efficiently structured and immediately conveys the core operation.

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

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

There is no output schema, and the description does not mention return values, side effects, or prerequisites beyond 'existing candidate'. The presence of siblings like hires_submit_career_application suggests a need for differentiation, which the description lacks. The nested cv object and optional include parameter are not contextualized.

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 description provides no parameter guidance; it relies on the schema. With 60% schema coverage, several parameters like job_id lack descriptions, and the description does not compensate for the missing semantics, such as the optional nature of cv or how include affects the response.

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 the verb 'Link' and the resource 'existing candidate to a job', creating an application. It is clear that this is for internal linking, not public applications, but it does not explicitly name a sibling to differentiate from hires_submit_career_application.

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

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

The description implies usage when an existing candidate needs to be associated with a job. It does not provide explicit context about when to choose this over alternatives like hires_submit_career_application or hires_update_application, so usage is inferred but not definitive.

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

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

With readOnlyHint=false and destructiveHint=false, the description carries the burden of behavioral disclosure. It does say the tool creates a candidate and may also create an application, and it sets an expectation that binary data must not be sent, but it does not describe what happens on duplicate email, required identity fields, or likely side effects beyond those already inferable from 'create'.

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, front-loaded with the core purpose and followed by the key resume-handling constraint. There is no filler or redundant overhead.

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

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

Given a 13-parameter create operation with no output schema, the description is acceptable but not complete. It does not clarify whether candidate identity fields are mandatory, how duplicate candidates are handled, what IDs are returned, or how an application with job_id/stage_id behaves alongside the candidate creation.

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 description adds meaning to job_id/stage_id by calling them an optional application group and explains that resume_text must be extracted plain text, never binary. However, with 13 parameters and 62% schema coverage, it leaves several important parameters such as company_id, last_name, phone, and state to the schema alone without additional context.

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 the action and resource clearly: create a candidate, optionally with an application and resume text. It is specific enough to separate from most sibling tools, but it does not explicitly differentiate itself from hires_create_application, since both can be tied to a job/application.

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

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

The description gives an operative instruction about passing resume_text plain text, but it provides no guidance on when to use this tool versus hires_create_application, hires_update_candidate, or other candidate-related flows. No exclusions, prerequisites, or alternatives are named.

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 indicate write activity (readOnlyHint=false) and non-destructive intent (destructiveHint=false). The description adds value by revealing specific side effects: provisioning of a public career site (slug) and public branding (name, logo). This goes beyond the generic annotations and informs the agent of the scope of effects.

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

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

The description is a single, tightly worded sentence (16 words) that front-loads the primary action, then adds a concise elaboration on side effects. No redundancy or filler; every word 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?

Given 8 parameters (including a nested logo object), no output schema, and openWorldHint=true indicating external side effects, the description is insufficient. It does not explain parameter inputs, constraints, or outcomes beyond branding and career site, leaving significant gaps for an agent to correctly invoke the 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 only 13% (few parameters have descriptions), yet the tool description only mentions 'name' and 'logo' in the context of branding. It does not clarify the required fields company_owner_email and company_owner_name, nor optional ones like website, is_staffing_agency, or the logo object's structure. The minimal hint about name/logo does not compensate for the low schema coverage.

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

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

The description clearly states the action 'Create a client company' with a specific resource, and distinguishes it from other create tools (e.g., hires_create_job, hires_create_candidate) by focusing on company creation. It also specifies that it provisions a career site and branding, adding operational clarity beyond a generic create.

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 explicit guidance on when to use this tool versus alternatives, such as hiring_update_company for modifications or hiring_restore_company for restoration. The name and description imply it is the correct tool for creating a company, but there is no direct comparison or exclusion of alternatives, leaving the agent to infer usage from the name.

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

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

The annotations already indicate this is a write operation (readOnlyHint: false) and not destructive (destructiveHint: false). The description adds value by noting that subject and body accept placeholders and points to where to get exact tags, which is a behavioral nuance beyond bare creation. However, it does not disclose side effects, required permissions, or the return value after creation, leaving some transparency gaps given the minimal 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?

The description is two sentences long with no fluff. It front-loads the core purpose ('Create an email template') and then delivers the placeholder guidance in a secondary clause. Every sentence contributes information, and the structure is efficient and easy to parse.

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 creation tool with four parameters and no output schema, the description is adequate but not complete. It explains the placeholder mechanism and directs to helper tools for exact tags, but omits any explanation of the 'name' and 'company_id' fields. It also does not mention what happens on success (e.g., return object or confirmation). Given the tool's simplicity, the gaps are moderate but could cause an agent to guess parameter semantics.

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

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

With schema description coverage at 50% (subject and body have descriptions, name and company_id do not), the description compensates partially by clarifying that subject and body support placeholders. It does not, however, address the meaning or purpose of the 'name' and 'company_id' parameters. While subject and body are enriched, the remaining parameters are left to inference, so the description adds some but not full compensatory value.

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

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

The description clearly states the tool's function: 'Create an email template.' The verb 'create' distinguishes it from sibling tools like hires_update_email_template and hires_delete_email_template. It also specifies the resource (email template) and hints at the placeholder feature, leaving no ambiguity about what this tool does.

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

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

The description implies when to use this tool (when creating an email template) and provides guidance on handling placeholders by referencing hires_list_template_placeholders and hires_prepare_template_placeholders. However, it does not explicitly compare with alternatives like updating or deleting templates, nor does it state any prerequisites or exclusions. The usage context is implied rather than explicitly articulated.

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 indicate this is a non-read-only (write) and non-destructive operation. The description adds the behavior of optionally attaching existing questions, which is useful, but it does not disclose other behavioral aspects like return value, side effects, or required permissions. Given the annotations cover the basic write nature, a score of 3 reflects the moderate additional transparency.

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

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

The description is a single, tightly worded sentence that front-loads the primary action and the optional attachment behavior. There is no redundant or filler text, and it is appropriately sized for the tool's simplicity.

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 create operation with three parameters and no output schema, the description covers the core purpose and the optional attachment but omits details about 'name' and 'company_id'. It also does not hint at the response or any creation constraints, making it only partially complete for an agent to call it confidently.

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 only 33% (only the 'questions' parameter has a description). The description clarifies that 'questions' refers to existing question IDs to attach, but it does not explain 'name' or 'company_id'. Since the schema leaves these undocumented, the description fails to compensate, leaving the agent to guess their meaning or purpose.

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

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

The description uses a specific verb ('Create') and resource ('application form'), clearly distinguishing it from sibling tools like hires_create_application or hires_create_question. It also mentions the optional action of attaching existing questions, which adds specificity without ambiguity.

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

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

The description implies usage (creating a form, optionally with questions) but does not explicitly state when to use this tool over alternatives like hires_create_application or when not to use it. There is no mention of prerequisites or context where another tool would be preferred, leaving the agent to infer from the name and sibling 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?

The annotations only say the tool is not read-only and not destructive; the description adds a meaningful behavioral detail by disclosing that the location is matched to an existing record or created. That is a side effect an agent would not infer from the schema. It could still mention other effects or preconditions, but it goes beyond the structured data.

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

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

The description is two short sentences with no filler. The core action is front-loaded, and the non-obvious location behavior is appended in a single concise 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?

For a six-parameter mutation tool with no output schema, the description covers the core purpose and the most non-obvious behavior. It falls slightly short of complete because it does not explicitly identify `id` as the application identifier or state prerequisites like a valid existing application.

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 high at 83%, so most parameters are already described. The description adds real value to the location parameter, explaining that the free-text location is normalized by matching it to an existing record or creating one. It does not add much for the other parameters, but the schema already covers their meaning.

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

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

The description identifies a specific verb and resource: 'schedule an interview for an application.' It clearly conveys what the tool does and distinguishes it from unrelated create siblings, though it does not explicitly differentiate itself from other interview-related endpoints such as hires_get_interview or hires_list_interviews.

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 intended use is implied: use this tool when an application needs an interview scheduled. However, it provides no explicit when-to-use/when-not-to-use guidance, no prerequisites such as 'the application must already exist,' and no mention of alternatives, so the guidance is thin.

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 indicate a write operation (readOnlyHint=false) and non-destructive behavior (destructiveHint=false). The description adds no behavioral context beyond 'Create a job,' such as side effects (auto-created form/workflow), response behavior, or permission requirements.

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

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

A single sentence with zero filler; the core action is front-loaded and the only additional content is a compact list of required or conditional fields. Every word 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?

This is a 30-parameter creation tool with no output schema and limited behavioral guidance. The description only covers mandatory input basics, leaving the agent without context on return values, optional-field dependencies, default side effects, or when to supply related object IDs from list_* endpoints.

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 description restates required fields that are already in the schema's 'required' array and repeats the location_city/is_remote condition already present in the schema. With 63% schema coverage, it does not meaningfully document the remaining 11 undocumented parameters or add new semantic value.

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?

'Create a job' clearly states the verb and resource, and the required-field list adds a concrete scope. It is distinguishable from sibling create_* tools, though the phrasing largely restates the tool name.

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

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

The description gives no guidance on when to use this tool versus alternatives such as hires_update_job or hires_create_application. It does not mention exclusions, prerequisites, or scenarios where a sibling would be more appropriate.

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?

Even with annotations present, the description adds meaningful behavior not captured there: the signing_secret is returned only once and must be used to verify the x-hires-signature-v2 header. This is important operational information for the agent. No contradictions with 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 concise sentences containing only high-value information: the action, the scope, and the critical one-time secret behavior. It is front-loaded and has 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 appropriately explains the key return value (`signing_secret`), that it is returned once, and how it should be used. For a two-parameter create tool with complete schema coverage, this is sufficient.

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 input schema already covers both parameters at 100%, including the HTTPS-public-host restriction on `url`. The description adds no additional parameter semantics, so baseline score of 3 is appropriate.

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

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

The description uses a specific verb, 'Register an HTTPS webhook', names the resource (a job webhook), and specifies its event scope ('this job's events'). This clearly distinguishes it from generic webhook tools like hires_create_webhook and from read/list webhook tools.

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

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

The description gives clear contextual scoping: it is for registering a webhook for a specific job's events. It does not explicitly name `hires_create_webhook` as the alternative for non-job webhooks, but the 'for this job's events' framing is clear enough for an agent to decide when to use this tool.

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?

The description discloses a key side effect: @mentions email the mentioned users, which goes beyond the raw annotations (readOnlyHint=false, destructiveHint=false). It also mentions visibility options. While it doesn't address auth requirements or reversibility, the annotations already indicate a write operation, and the description adds the email notification behavior, which is valuable.

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

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

The description is a single, front-loaded sentence that states the primary action first, then the optional features. It contains no filler or redundant phrasing, and every clause contributes to understanding the tool's behavior.

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 create tool with 100% schema coverage, the description covers the essential purpose and side effects. It doesn't mention required parameters (candidate_id, body) explicitly, but those are in the schema. There's no output schema to explain, and the behavior is simple. It lacks details like whether the note appears in a candidate timeline, but that's implicit from the tool's purpose. Overall, it's adequate for an agent to call it correctly.

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

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

Schema description coverage is 100%, so each parameter already has a description (e.g., body allows HTML, candidate_id accepts id or alias, visibility defaults to all). The tool description summarizes these features but adds no new meaning beyond the schema. It does not explain interactions between parameters or provide context beyond what's already documented.

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 ('Create'), resource ('discussion note'), and target ('for a candidate'), and lists optional features (visibility, @mentions). It clearly distinguishes from sibling tools like hires_update_note and hires_delete_note by indicating this tool creates, not modifies or removes, a note.

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

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

The description implies usage (add a note to a candidate) but provides no explicit guidance on when to choose this over alternatives like hires_update_note or hires_delete_note. It also doesn't mention any conditions or prerequisites, such as the candidate needing to exist or user permissions. The context is clear from the name, but the description itself offers no direct 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 indicate the tool is not read-only (readOnlyHint: false) and not destructive (destructiveHint: false), so the description doesn't need to repeat that. It adds minimal behavioral context beyond the annotation, mentioning the ordered nature of steps and the optional trigger, but does not disclose side effects, prerequisites, or return behavior.

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

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

The description is a single, front-loaded sentence that immediately identifies the action and key characteristics. Every word earns its place, with no filler or redundancy.

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

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

Given the tool's complexity (nested steps array, 11 parameters, no output schema), the description is relatively thin. It conveys the core concept but does not explain return values, prerequisites, or the interplay of scheduling parameters. The comprehensive schema mitigates this, but for a creation tool of this complexity, more context would help an agent avoid missteps.

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 high (82%), so the baseline is 3. The description adds value by stating that steps are 'ordered' and listing the step types, which clarifies the array semantics beyond the schema's individual field descriptions. However, it does not explain the many optional top-level parameters (timezone, delay_time, etc.) or the required fields, relying on the schema to carry that load.

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

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

The description clearly states the tool creates a nurture campaign and enumerates the specific step types it supports, which distinguishes it from sibling tools like update, delete, and list. It also mentions the optional workflow-stage trigger, making the purpose unambiguous.

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

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

The description implies this is the creation variant by using 'Create' and listing step types, which is clear enough for an agent to select it over update/delete/list. However, it does not explicitly state when not to use it or name alternatives, leaving the usage guidance to be inferred from the tool name and context.

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?

The description adds a useful behavioral constraint (options only apply to select/multiselect types) beyond the annotations. However, it does not disclose other behaviors like idempotency, permission requirements, or what happens on duplicate creation. Annotations already indicate a non-read-only operation, so the description adds some value but not extensive transparency.

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

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

The description is a single sentence, front-loaded with the main action and constraint. It is appropriately concise with no wasted words, though it could include more context without becoming verbose.

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 create tool with no output schema, the description omits return behavior or success indicators. It does not mention company_id requirements or any caveats beyond the options constraint. Given the tool has four parameters and two are undocumented, the description is incomplete for a fully informed call.

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

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

The schema already documents options with the same note, so the description adds little for that parameter. It does not compensate for the undocumented parameters text and company_id (50% schema coverage). The type parameter's guidance to list_question_types is not repeated in the description, and no additional semantics are provided for the remaining params.

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

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

The description states a specific verb and resource ('Create a reusable question') and adds a clarifying constraint about options. It is clear but does not explicitly differentiate from other create_* tools like create_form or create_application, though the resource name makes it unambiguous.

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

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

No guidance is provided on when to use this tool versus alternatives such as update_question or list_questions. There is no mention of exclusions, prerequisites, or scenarios where another tool is preferable.

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 indicate non-read-only (readOnlyHint=false) and non-destructive (destructiveHint=false), so the mutation nature is known. The description adds one useful behavior: the signing_secret is returned once and must be used for verification. It does not disclose that the webhook is company-scoped is already in description, but it does not mention what happens on duplicates, permissions, or whether the secret is in output (no output schema). It adds slight value beyond annotations but not rich context.

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

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

Two sentences with zero redundancy. The main purpose is stated first, then a critical security note. Every word is functional. Perfectly sized for a 2-parameter tool.

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

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

The tool is simple with low complexity, and the annotations cover safety (non-destructive mutation). The description covers the creation purpose and the secret behavior. However, it does not specify the return format (no output schema) beyond the secret, and does not mention error cases (e.g., duplicate URL) or permissions. Given the low complexity, it 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 coverage is 100%: both id and url have descriptions. The description adds a constraint that the URL must be HTTPS on a public host (already in schema for url) and that the signing_secret is returned once. The description ties the id to the company scope, which is not in the schema's id description. This adds meaningful context for the id parameter beyond the bare 'Company id'.

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

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

Description clearly states it creates a company-scoped webhook)Skip over the clear verb 'Create' and the resource 'company-scoped webhook.' It distinguishes from create_job_webhook (which is job-scoped) but does not explicitly name that sibling; the distinction is implied by the scope. It is clear enough for an agent to identify it among the many create_* tools.

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

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

The description gives a clear context: when creating a company-scoped webhook, but it does not explicitly state when to choose this over create_job_webhook or list/delete/rotate webhooks. It states the purpose, but there is no explicit 'use this when...' or comparison. It provides practical guidance (signing_secret) for post-creation, but not usage alternatives.

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

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

The description explicitly says 'Permanently delete', which reinforces the destructiveHint=true annotation and adds the nuance of irreversibility. This is meaningful context beyond the bare annotation, but there's no mention of side effects (e.g., associated data) or permission requirements. The bar is lower with annotations present, and this clears it but doesn't go further.

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

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

Three words, front-loaded with the verb and irreversibility. Zero 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?

The operation is destructive and permanent, and the description communicates that, but it omits any context about side effects (e.g., whether related records are cascaded, whether this is irreversible after a grace period, or what the response is). A one-line description of a destructive tool leaves the agent without guidance on preconditions or consequences.

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 schema exposes only 'id' with no description flags, and the description does not elaborate beyond the obvious implication that the id targets an application. With schema description coverage at 0%, the description should compensate but does not – it never tells the agent what id refers to, how to obtain it, or any validation constraints. The single parameter is barely self-explanatory.

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

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

The description uses a specific verb ('Permanently delete') and identifies the resource ('an application'), making it clear what the tool does. It distinguishes itself from sibling delete tools by specifying the target resource, though it doesn't clarify whether 'application' refers to a job application or an applicant record.

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 guidance on when to use this versus related siblings like hires_advance_application, hires_batch_reject_applications, or hires_update_application. An agent must infer that deletion is for removing an application entirely, with no mention of prerequisites or consequences.

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?

The annotations already declare destructiveHint=true, so the description's mention of 'Permanently delete' reinforces the destructive nature. It adds a slight nuance by saying 'permanently', indicating irreversibility, but it doesn't disclose other behavioral aspects like cascading effects on related data (e.g., applications, notes) or whether authentication is required. Since annotations cover the core hint, the description's value is limited but not redundant.

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

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

The description is a single sentence with no fluff. It front-loads the core action and permanence, making it immediately clear. Every word earns its place, and there is no unnecessary content.

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

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

Given that the tool has only one parameter, a clear schema, and a straightforward purpose, the description is adequate. It doesn't include return value details, but there is no output schema, and for a delete operation, the return is likely a simple success response. The description covers the essential intent and destructive nature, which is comprehensive enough for an agent to call it correctly.

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

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

The schema has 100% description coverage for the single parameter, id, with a clear 'Candidate id or alias' description. The description of the tool adds minimal value to the parameter, but the schema already provides sufficient meaning. The baseline for high coverage is 3, and the description's 'candidate' context aligns with the parameter description, earning a slight boost to 4.

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 'Permanently delete a candidate' clearly states the action (delete), the resource (candidate), and the permanence aspect, which distinguishes it from other operations. It is specific and unambiguous, and sibling tools that also delete (e.g., hires_delete_application) are distinguishable by the resource name in the title and 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?

The description implies that the tool is for deleting a candidate permanently, which is a clear use case. However, it does not provide explicit guidance on when to use this tool versus alternatives, such as disqualify_candidate or remove_candidate_tag, which might be less destructive. It also doesn't mention any prerequisites, but the directness of the purpose helps. This is a basic but not comprehensive 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 mark destructiveHint=true and readOnlyHint=false, but the description adds valuable nuance: it's a soft-delete (implying reversibility) and explicitly notes the public career site goes offline. This goes beyond the annotation flags and clarifies the nature of the destructive action. No contradiction with 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?

The description is a single, well-structured sentence that front-loads the action ('Soft-delete a company') and adds a relevant consequence. There is no wasted wording, and it is immediately scannable.

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

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

For a simple single-parameter tool with no output schema, the description covers the core behavior and a key side effect. It implies reversibility via 'soft-delete' but doesn't explicitly mention that restore is possible or what happens to associated data (jobs, candidates). Given the minimal complexity, this is largely sufficient, though a note on the permanent/restorable nature would make it more 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?

The schema has one required parameter 'id' with zero description coverage. The description does not mention the parameter at all, leaving its meaning (the company's identifier) to be inferred from the tool name. With 0% schema coverage, the description should compensate, but it fails to explain what 'id' refers to or any constraints (e.g., must be an existing company).

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 ('soft-delete') and resource ('company'), and adds a concrete consequence ('its public career site goes offline'). This clearly distinguishes it from other delete tools targeting different resources, and the 'soft-delete' nuance differentiates it from a hard delete.

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

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

The description implies usage (delete a company) but doesn't explicitly state when to use this versus alternatives, nor any prerequisites or exclusions. It doesn't mention that a hard delete or permanent removal might be handled elsewhere, nor does it reference the restore_company sibling. The context is inferred from the name and 'soft-delete' but not explicitly guided.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the destructive nature is covered. The description adds value by specifying 'soft-delete' and the automation consequence, which goes beyond the annotations and clarifies the exact side effect.

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

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

The description is a single, front-loaded sentence with zero wasted words. It states the primary action and a key consequence efficiently.

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 delete operation with one parameter and no output schema, the description covers the essential behavior and a notable side effect. It lacks details on return value or error conditions, but these are not critical for a soft-delete tool and are partially covered by annotations.

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 0% for the single 'id' parameter, so the description carries the burden of explaining what id refers to. It does not mention id at all, leaving the agent to infer it is the email template id from context. This is a minimal gap given the obvious parameter name, but it still fails to compensate for the lack of schema description.

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

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

The description clearly states the verb (soft-delete) and resource (email template), and adds a distinguishing behavior: automations that used it cannot pick it for new actions. This makes it unambiguous compared to other delete tools like hires_delete_form or hires_delete_job.

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 explicit when-to-use or when-not-to-use guidance is given. It does not mention alternatives (e.g., using update_email_template to disable instead of delete) or any prerequisites. The usage context is only implicit from the tool name.

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

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

The annotations already flag this as destructive, so the description adds no behavioral detail beyond that. It does not mention whether deletion is permanent, whether it cascades to related data, or whether any confirmation or special permissions are required. With destructive operations, such context would be valuable.

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

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

The description is one short sentence that is immediately understandable and front-loaded with the action and object. There is zero redundant wording or repetition of the tool name.

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

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

For a one-parameter destructive operation, the description plus annotations cover the essential action and risk. However, there is no mention of return behavior, irreversibility, or any effects on related application data, which would improve completeness for an agent deciding whether to call this tool.

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

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

The schema has one required id parameter with no description, and the description names the resource but not the field. However, with only a single numeric id parameter, meaning is inferable: the id identifies the application form to delete. The description provides minimal added value beyond the schema, but the low parameter count limits the need for elaborate explanations.

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 'Delete an application form' clearly states the action and the resource being acted onhol. It distinguishes this from the many sibling tools by specifying the resource (application form) and the destructive action. It is more specific than the bare tool name, though it does not elaborate on what 'form' refers to beyond the name.

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 guidance is given about when to use this tool versus alternatives like update_form or get_formhol. The description is just a single phrase with no context, prerequisites, or caution about when deletion is appropriate. In a large sibling list, this is a notable 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 destructiveHint=true, readOnlyHint=false, and openWorldHint=true. The description merely repeats 'Delete a job' and adds no extra behavioral context such as irreversibility, cascade effects, permission requirements, or whether deletion can be undone. It does not contradict the annotations but contributes no additional transparency.

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

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

The description is one sentence with no wasted words and the action is front-loaded. It is appropriately terse for a single-parameter delete tool, though it sacrifices informative detail for brevity.

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 destructive tool with no output schema, the description is minimally acceptable but lacks details about deletion semantics such as permanence, side effects, or success response. The annotations and complete parameter schema make the tool callable, but the description alone leaves some contextual gaps.

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

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

Schema description coverage is 100%, and the id parameter is already documented as 'Job id or alias.' The tool description adds no additional parameter semantics beyond targeting a job by id. With high schema coverage, the baseline score of 3 is appropriate.

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

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

The description states a clear action verb and resource: 'Delete a job.' This distinguishes it from sibling delete_* tools because the resource is named. However, it essentially restates the tool name and title without adding any scope or nuance, 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?

There is no guidance about when to delete a job versus alternatives like updating it, closing it, setting its status, or other lifecycle operations. No conditions, exclusions, or sibling comparisons are provided. The agent must infer usage solely from the tool name.

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

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

The description adds no behavioral context beyond what annotations already provide. Annotations include destructiveHint=true, and the description says 'Delete', which aligns but adds nothing new. It does not mention permanence, side effects, or prerequisites. With annotations covering the destructive nature, a score of 2 reflects the lack of additional transparency.

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

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

The description is a single sentence and is extremely concise. It is front-loaded and easy to parse. However, it is so terse that it sacrifices valuable information that could fit without bloat, so it is not perfect.

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 delete tool, the description is insufficient. It lacks usage guidance, parameter semantics, and behavioral context beyond the action. An agent would not know the relationship between 'id' and 'webhook_id' or any consequences of deletion. The absence of an output schema and the minimal description leave important gaps.

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

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

The schema description coverage is 50%, with only 'id' documented as 'Job id or alias' and 'webhook_id' having no description. The tool description does not explain either parameter, so it fails to compensate for the missing webhook_id semantics. The name hints at webhook_id being a webhook identifier, but that is implicit.

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 'Delete a job webhook' clearly states the action (delete) and the resource (job webhook). It is specific enough to distinguish from general webhook tools like hires_delete_webhook, though it doesn't explicitly call out that distinction. The purpose is unambiguous.

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

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

No guidance is provided on when to use this tool versus alternatives. The description does not mention that this is for job-specific webhooks, nor does it reference sibling tools like hires_delete_webhook or hires_rotate_job_webhook_secret. An agent would have to infer usage from the name 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 destructiveHint=trueabb. The description adds that it targets scheduled messages and must occur before sending, providing useful behavior context. No details on idempotency or error behaviors beyond the annotation safety profile.

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 clear sentence, front-loaded with the verb and subject. No filler or redundant restatement of the tool name.

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

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

For a simple single-parameter destructive operation, the description plus annotations are mostly sufficient. The 'before it is sent' constraint clarifies the primary edge case that gates the operation. Missing details about failure when the message is already sent, but the phrasing implies the limitation.

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 has one parameter (`id: integer`) with zero description coverage (0%). The description never mentions the parameter, so an agent must infer that `id` refers to the scheduled message ID. Minimal compensation for the schema gap.

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?

Description states a specific verb ('Cancel') and resource ('a scheduled message'), distinguishing it from sibling delete tools like hires_delete_notification_message. The qualifier 'before it is sent' adds scope.

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

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

The description implies when to use (only for scheduled messages that haven't been sent), but it doesn't explicitly contrast it with alternatives like hires_delete_message vs hires_delete_notification_message. It provides context but no explicit exclusion or alternative 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?

The annotations clearly indicate destructiveHint=true, so the description does not need to re-state that it's destructive. The description adds no further behavioral context beyond that, such as irreversibility or side effects on related data. Given the annotation coverage, this is acceptable but could be improved by noting that deletion is permanent.

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

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

The description is extremely concise (one short sentence), which is appropriate for a simple delete operation. It front-loads the action and resource. No fluff, but also no additional valuable context.

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

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

For a simple delete tool with one parameter accruing to a well-known resource (note), the description is arguably sufficient. However, it lacks any mention of what a 'note' is or how it is identified, and with no output schema, the agent has no info on success/failure response. Given the sibling list includes many other delete tools, a small clarification could help.

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 schema has 0% description coverage for the parameter 'id', and the description does not explain what 'id' refers to (probably the note's ID). The agent must infer that 'id' is the primary key of the note to delete. With no param info in the description, and schema lacking descriptions, this is a significant gap.

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 ('Delete') and a resource ('a note'), which clearly matches the tool's name and distinguishes it from the many sibling tools that operate on different resources (e.g., delete_application, delete_candidate). However, the description is minimal and doesn't provide additional context about what a 'note' is, but the name alone is unambiguous.

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

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

The description lacks any guidance on when to use this tool versus others. There is no mention of prerequisites (e.g., note must exist) or whether it can be deleted only under certain conditions. No alternatives are mentioned, but given the destructive nature, the user might need to confirm 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 indicate destructive Hint=true and readOnlyHint=false. The description adds the non-obvious boundary that only scheduled messages are cancelable, which is material behavior not present in structured fields. It does not contradict 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?

The description is one concise, front-loaded sentence with no filler. The core action and the critical constraint are both included without redundant wording.

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

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

For a one-parameter destructive tool, the description covers the essential context: scheduled emails can be canceled, sent ones cannot. There is no output schema, and the example-like omission is minor; it does not need to explain return values.

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

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

With 0% schema description coverage and no parameter documentation, the description provides little direct meaning for the `id` parameter. It is implicitly the identifier of the scheduled notification, but the description never explicitly states that the parameter represents the notification to cancel.

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 action ('cancel') on a specific resource ('scheduled notification email'), and the follow-up clause clarifies that sent messages are out of scope. This distinguishes it from general deletion tools like hires_delete_message and from batch cancellation like hires_cancel_all_notification_messages.

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 clearly identifies the target case (scheduled notification emails) and an explicit exclusion (sent messages cannot be canceled). Though it does not name alternative sibling tools, the when-to-use condition is explicit enough for an agent to select it 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 mark destructiveHint=true and readOnlyHint=false, indicating a write operation. The description adds useful behavioral context: 'soft-delete' implies recoverability Secretly may not be true, and 'running executions stop' discloses the immediate side effect. These are beyond the annotations. However, it does not clarify whether the deletion is reversible, what happens to associated data, or if any cascading effects occur. A 3 is appropriate because the soft-delete distinction adds value but not enough detail about the full behavioral impact.

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

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

The description is a single sentence, highly concise and front-loaded with the primary action. The behavioral effect is included immediately after the action. There is no wasted wording; every word adds clarity. It is appropriately sized for a simple tool with one parameter.

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

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

Given the tool is a delete operation with one parameter and no output schema, the description is minimal. It does not mention return behavior (likely success/failure), error conditions (e.g., invalid id), or irreversible consequences. It also does not specify whether the operation is idempotent or what happens to ongoing executions in detail. The annotations cover destructiveness, but the description is too sparse to be considered fully complete for an agent to use without additional assumptions.

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 0%, so the description must compensate for the lack of parameter documentation. The only parameter is 'id' (number), but the description does not explain what 'id' refers to (likely the campaign ID) or whether it is required (though schema says required). The description does not add any detail about the parameter beyond what is in the schema, leaving an agent to guess the id's purpose. Since coverage is 0%, the description fails to provide the minimal clarification that 'id' is the nurture campaign identifier.

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

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

The description clearly states the action ('soft-delete') and the resource ('nurture campaign'), and it is distinguished from the many other delete tools by specifying the exact resource type. It also notes a side effect ('running executions stop'). However, the term 'soft-delete' is specific and adds clarity, though it does not explicitly distinguish from the other delete tools beyond the resource type, which is sufficient given the naming convention.

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

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

The description implies when to use this tool (when you need to soft-delete a nurture campaign) but provides no guidance on when not to use it or alternatives. For instance, it does not mention whether there is a hard delete option or if there are prerequisites (e.g., campaign must be paused). The 'soft-delete' implies reversibility but does not explain how to undo it, which could mislead an agent into thinking deletion is permanent.

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?

The annotations already declare destructiveHint=true. The description adds 'reusable question' and 'catalog' context, but does not disclose consequences of deletion (e.g., irreversible removal, impact on job postings using the question). No contradiction with 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?

A single sentence with no filler; front-loaded action verb and clear object. Efficient and scannable.

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

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

For a one-parameter destructive action, the description plus annotations is minimally sufficient. However, it lacks details about deletion semantics (permanence, cascading, access requirements) and does not identify how to obtain the id, leaving a moderate gap in 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 coverage is 0% – the description does not explain the 'id' parameter, how to obtain it, or any constraints (e.g., cannot delete in-use questions). The parameter is self-explanatory but the description does not compensate for missing schema parameter descriptions.

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

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

The description uses a specific verb and resource: 'Delete a reusable question from the catalog.' It clearly identifies the action and object, distinguishing it from related get/update/list tools. However, it doesn't explicitly contrast with other delete-family tools, though the question-specific scope is clear.

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 guidance on when to use this tool versus alternatives such as update_question or delete_form. The context is implicit for a delete operation, but there is no mention of prerequisites, effects on dependent data, or when not to use.

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 destructiveHint=true, so the description's 'Delete' aligns with that. However, the description adds no context about irreversible effects, required permissions, or what happens to associated data. It merely restates the destructive nature already captured by 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?

The description is a single, efficient sentence with no filler. It states the essential action and scope, making it appropriately concise and front-loaded.

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

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

For a simple delete operation, the description is adequate but minimal. It does not mention how to obtain the webhook_id (e.g., via list_webhooks), any prerequisites, or explicitly differentiate from the job-webhook deletion tool beyond the scope word. Given the tool's simplicity and the annotations covering destructive intent, this is a borderline acceptable level of 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 coverage is 50% (only 'id' has a description). The description adds no parameter information at all; it does not explain that 'webhook_id' identifies the webhook to delete or clarify the relationship between the two parameters. The description fails to compensate for the missing schema documentation.

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 ('Delete') and a clearly scoped resource ('company-scoped webhook'). This distinguishes it from sibling hires_delete_job_webhook, which targets job-scoped webhooks, so the purpose is unambiguous.

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

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

No guidance is provided on when to use this tool versus alternatives like hires_delete_job_webhook or when not to use it. The only hint is the phrase 'company-scoped', which implies the scope but does not explicitly route the agent away from job-scoped webhooks.

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?

The annotations already declare destructiveHint: true)Skip. The description adds that it affects all active applications and returns affected ids, which clarifies side effects, but it doesn't mention reversibility, permissions, or impact on related entities.

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

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

The description is a single front-loaded sentence: action first, object second, return value third. No redundant phrasing or 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 two-parameter tool with a direct description, the essential semantics are clear: what it doesaint, what it operates on, and what it returns. It lacks explicit edge-case guidance (e.g., what if candidate has no active applications) but this is minor given the simple interface.

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 description doesn't need to repeat parameter meanings. It does add the scope clarification ('all active applications') and return value, which go slightly beyond the bare schema.

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

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

The description clearly states the action (reject), the resource (active applications of a candidate), and the scope (all active). It distinguishes this from individual rejection tools like hires_reject_application, though it does not explicitly name 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?

No guidance on when to use this tool versus alternatives such as hires_reject_application or hires_batch_reject_applications. The intended use case must be inferred from the name and description.

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?

The annotations already mark it read-only and non-destructive, so the safety profile is known. The description adds useful behavioral context beyond the annotations: the 25 MB rejection limit, the returned fields (file_name, mime_type, size, base64 data), and the set of accepted attachment types. No potential contradiction.

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

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

The description is two succinct sentences with the core action and source first, followed by the return value and limit. No fluff or redundant explanation; every clause contributes either to what you get or what breaks the call.

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 a single parameter and no output schema, the description is fairly complete: it states the URL source, the allowed content types, the return fields, and the file size constraint. The only minor gap is that the host restriction is left to the schema, but since the schema is structured and present, the description closes most of what an honest tool would need to be called 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?

The input schema already gives 100% coverage by describing the url parameter as an absolute URL from another tool's response, restricted to the 100Hires API host. The description's phrase 'by the url another tool returned' simply repeats that without adding extra detail, so it does not bring value over the structured schema.

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

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

The description clearly states a specific action—download an attachment—and clearly identifies the resource: attachments like resumes, candidate/application files, mail attachments, or call recordings. It also distinguishes itself from getters and uploads by pointing out it consumes a URL returned by another tool, which makes its purpose unambiguous.

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

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

The description tells exactly when to use it: when you have a URL from another tool that you want to download as file data. It does not name a sibling alternative or state when not to use it, but the input condition is specific enough to make the call context clear, so only the exclusion/alternative mention is missing.

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 and destructiveHint=false, so safety is covered. The description adds valuable behavioral context beyond annotations by noting that the score is 'null until scored', and describes the return structure (per-criterion scores, justifications, follow-up questions). This goes beyond the annotations, so a 4 is appropriate.

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

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

The description is a single, well-structured sentence that front-loads the action and states return contents and null behavior. There is no waste; every clause contributes essential 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?

Given the simple one-parameter tool, annotations for read-only safety, and no output schema, the description is nearly complete. It covers the purpose, return contents, and null-score state. It does not explicitly mention error handling for an invalid ID, but that is standard for a getter and not required. The description sufficiently equips an agent to call it correctly.

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

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

The schema provides only a single 'id' field with no description (0% coverage), so the description must clarify its meaning. While it does not explicitly state 'id is the application ID', the phrasing 'Get the AI score of an application' makes it clear that the single parameter refers to the application. This adds meaning beyond the bare schema, justifying a 4.

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

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

The description clearly states the specific verb ('Get') and resource ('AI score of an application'), and enumerates the return contents ('per-criterion scores, justifications and follow-up questions'). It effectively distinguishes from the sibling 'hires_get_evaluation' by narrowing to the AI score specifically.

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

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

The description implies when to use the tool (when you need the AI score) but does not explicitly mention alternatives or exclusions. No guidance is given on when not to use it (e.g., if you need a human evaluation, use hires_get_evaluation instead). The usage context is implied rather than stated.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the specific fields returned (stage, status, rejection context), which is useful but not rich behavioral context like pagination or side effects. It does not contradict annotations, and the read-only nature is adequately communicated by both.

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

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

The description is a single sentence that front-loads the verb and resource, with no unnecessary words. It efficiently conveys the purpose and key output without wasting tokens.

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

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

For a simple read-only tool with no output schema, the description covers the primary purpose and the fields returned. However, it does not clarify whether the full application object is returned or only the mentioned fields, and it omits any mention of the 'include' parameter behavior. An agent might have minor ambiguity about the exact response structure.

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 50%: the 'include' parameter is described in the schema, while 'id' is not. The tool description does not add any parameter information beyond what the schema provides. Since the description does not compensate for the missing 'id' description, but 'id' is self-explanatory, a score of 3 is appropriate as the baseline for medium coverage.

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

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

The description states a clear verb and resource ('Get an application') and specifies the key fields returned (stage, status, rejection context), making the tool's purpose unambiguous. It is distinct from other get_* siblings because it targets applications specifically, and the listed fields differentiate it from generic application retrieval.

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

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

The description implies usage (retrieve a single application by ID) but does not explicitly mention when to use it versus alternatives like hires_list_applications or hires_get_candidate. There is no explicit exclusions or named sibling for comparison, so guidance is implied rather than 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=true and destructiveHint=false, so the read-only nature is covered. The description adds the specific resource (billing and feature flags) but does not disclose any additional behavioral traits such as response format, errors, or rate limits. No contradictions with 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?

The description is a single concise sentence, front-loaded with the action and object. There is no wasted wording, making it easy to parse quickly.

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

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

Given the simplicity (no params, no output schema, read-only annotations), the description is adequate. It clarifies the scope ('current company') and what is returned. It could mention what feature flags are or typical response fields, but for a minimal getter, this is sufficient.

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 has zero parameters, so the schema covers everything. Baseline for zero params is 4. The description does not need to add param info, and it correctly implies that no arguments are required.

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 the specific verb 'Get' and the resource 'billing and feature flags of the current company'. This is clear, unambiguous, and distinguishes it from sibling getters like hires_get_company or hires_get_career_site_settings by focusing on billing and feature flags.

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

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

The description implies usage: to retrieve billing and feature flags. However, it provides no explicit guidance on when to use it versus alternatives, nor does it mention any context or prerequisites. It is not misleading but lacks explicit 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 include readOnlyHint=true and destructiveHint=false, indicating a safe read operation, which is consistent with the description. The description adds the detail about application summaries, which is useful but does not disclose other behaviors like pagination or full data scope. Since annotations cover the basic safety profile, a 3 is appropriate.

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

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

The description is a single concise sentence that effectively communicates the tool's purpose without any fluff. It gets straight to the point, and every word adds value.

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

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

For a simple retrieval tool with one parameter and clear annotations, the description is largely sufficient. The mention of application summaries gives useful context about what the response will include, though it does not detail other fields. Given the simplicity, a 4 is justified.

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 input schema already documents the 'id' parameter fully with data type and description, so schema coverage is 100%. The description does not add additional parameter semantics beyond what the schema provides; thus, it meets the baseline but does not exceed it.

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 'Get a candidate with application summaries' clearly states the verb and resource and adds some detail (application summaries). It distinguishes it from siblings like hires_get_candidate_resume, but it does not explicitly clarify its scope compared to hires_list_candidates. Hence 4.

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 is clear from the description that this tool is for fetching a single candidate's information, implying use when you need a specific candidate's details. However, it does not explicitly state when not to use it or name alternatives like hires_get_candidate_resume or hires_list_candidates, so guidance is implicit rather than 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 carry readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds the specific return fields and the optional include parameter, which is useful context. However, it doesn't elaborate on behavior like pagination, file size limits, or error conditions. Given the annotation coverage, this is adequate but not rich.

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, well-structured sentence that leads with the resource and action, then lists the return fields and optional extension. No filler or redundancy. Every word adds value.

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

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

For a simple read operation with annotations confirming safety and no output schema, the description explains what is returned (including the download URL and optional text content), which is sufficient for an agent to invoke and interpret the result. It does not mention edge cases like missing resumes, but those are unlikely to be critical given the tool's scope.

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 input schema has 100% coverage: both id ('Candidate id or alias') and include ('text_content: add the parsed plain text') are described in the schema. The description reiterates the include effect without adding new meaning. Thus it meets the baseline for full schema coverage but does not go beyond.

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 ('candidate's primary resume'), and lists the exact fields returned (uuid, download url, file metadata, type). It is clearly distinct from generic file tools like hires_list_candidate_files or hires_download_attachment, so an agent knows exactly what this tool does.

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 clearly indicates when to use it – to fetch a candidate's primary resume. It does not explicitly mention alternatives or when not to use it, but the context is strong enough that an agent can infer it is for resume retrieval specifically, not general attachments. No exclusions are stated, but the narrow purpose makes it clear.

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 and destructiveHint=false, covering the safety profile. The description adds valuable context: it returns 404 for draft, archived, or internal jobs, and specifies the fields included. This goes beyond what annotations provide, though it does not describe other behaviors like response structure or pagination.

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

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

The description is a single, tightly worded sentence that leads with the core action and immediately conveys the key differentiator (public) and the edge-case behavior (404). There is zero redundancy or 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 simple get tool with two clear parameter names, the description captures the main behavioral nuance (404 for non-public) and the included fields. However, the lack of any parameter guidance and no mention of the response shape leaves a notable gap, even though the tool is simple and the annotations cover safety.

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

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

Schema coverage is 0% and the description does not mention either parameter (company_slug or id) at all. Since the description is the only source of guidance for parameters, its complete omission is a significant gap. The schema only gives types, so the agent has to infer the meaning from the names.

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 a resource ('public job'), and explicitly names the returned fields (salary, education, experience levels). It also distinguishes itself from sibling hires_get_job by adding the 'public' qualifier and the 404 behavior for non-public jobs, making its purpose unmistakable.

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

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

The description implies this is for public jobs but does not explicitly say when to use it versus alternatives like hires_get_job or hires_list_career_jobs. It lacks a clear 'when not to use' or a pointer to sibling tools, so the agent must infer the distinction from the term 'public'.

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, destructiveHint=false, openWorldHint=false, so the safety profile is set. The description adds valuable behavioral semantics: null defaults to en-US and a job may override this language. This helps the agent understand what the returned 'language' means and that it is not always the effective language for a given job, which is useful beyond the schema.

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

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

The description is an idea of length: one opening statement and one clarifying clause about the language field. No filler words, fully front-loaded. It says the data is trimmed exactly to what matters, making it an especially lean definition.

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

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

For a read-only tool with one optional parameter and no output schema, the description covers the primary purpose and the only critical nuance (language default and override). An agent could invoke this correctly and understand the returned data's semantics without needing to see additional documentation. It is comprehensive for the tool's simplicity.

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 sole parameter company_id already has a clear description: 'Omit for the API key's own company.' The field description adds no new information about this parameter. The description's value is about the return value, not the input, so it does not elevate the parameter scoring.

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

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

The description states a specific verb and resource: 'Get career site settings'. It then clarifies the meaning of the language field ('the locale the public site renders in') which is distinct from other get tools like hires_get_career_job or hires_list_career_jobs. The null=en-US detail makes it unambiguous.

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

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

It provides clear context that the language is the default for career sites and that individual jobs may override it, which tells the agent when this tool alone is sufficient versus needing job-specific language. However, it does not explicitly name alternatives like hires_update_career_site_settings or list jobs, so it falls short of the highest bar.

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 and destructiveHint=false, so the safety profile is covered. The description adds that the response includes owner details, which is useful, but it does not disclose response shape, error behavior, or authorization requirements.

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

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

The description is a single front-loaded sentence with no filler or repetition. Every part contributes information about the operation or its 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 simple, single-parameter read operation with safety annotations, the description is nearly sufficient. It tells the agent what it will receive, and the only meaningful gap is the lack of usage guidance already scored separately.

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

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

With 0% schema description coverage, the description carries the burden of explaining the 'id' parameter, but it does not. The parameter's meaning is recoverable from the tool name and required id, but the description adds no explicit clarification.

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

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

The description uses a specific verb and resource: 'Get a company profile', and adds the meaningful scope 'with owner details'. It is clearly distinguishable from sibling get tools and from list/create/update/delete company operations.

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 does not state when to use this tool versus alternatives, nor does it provide any exclusion or alternative guidance. The intended use is only implied by the tool name and generic wording.

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

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

With annotations providing readOnlyHint=true and destructiveHint=false, the description only needs to add extra behavioral context. It mentions the return includes subject and body, which is useful. However, it doesn't add details like error behavior for non-existent IDs, or any special fields. Given annotations cover safety, a 3 is appropriate.

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

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

The description is a single sentence with no wasted words. It states the core action and the key output (subject and body) efficiently. It is appropriately concise for a simple getter tool.

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

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

The tool is simple (one parameter, no output schema), and annotations cover read-only nature. The description is sufficient for basic invocation. However, it could have mentioned that the returned template might have other fields beyond subject and body, or noted common use cases. Sibling tools like 'hires_prepare_template_placeholders' suggest templates have placeholders, but this isn't mentioned. Still, for a basic getter, it's reasonably 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 has one parameter 'id' at 0% description coverage. The description doesn't explain what 'id' refers to (template ID) or that it is required. Since there is only one parameter, the name 'id' is somewhat self-explanatory, but the description could have clarified it is the email template ID. Baseline 3 is fair.

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

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

The description clearly states the verb 'Get' and the resource 'email template', and specifies it returns subject and body. It distinguishes from siblings like 'hires_list_email_templates' (which lists templates) and 'hires_create_email_template' (which creates). However, it doesn't explicitly mention that it's a single-template retrieval by ID, which is obvious from the name but not fully articulated.

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

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

There is no guidance on when to use this tool versus alternatives. It doesn't mention that for a list of templates you should use 'hires_list_email_templates', or for creating a template use 'hires_create_email_template'. The description assumes the agent knows to use this for getting a single template by ID, but does not state that explicitly.

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 and destructiveHint=false, so the safety profile is covered. The description adds useful context about what the response contains (evaluator, summary score/text, answers) but says nothing about auth, errors, or missing-evaluation behavior. The added content detail justifies a moderate score.

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

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

One compact, front-loaded sentence with no filler. The main payload fields are listed efficiently after the colon, making the description easy to scan.

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

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

This is a simple get-by-id tool with annotations covering the safety profile, and the description usefully outlines the return contents. However, with no output schema, it omits any explanation of what 'id' refers to, how to obtain it, or the exact response shape, leaving a few gaps for an agent invoking 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 description coverage is 0%, so the description must compensate for the undocumented 'id' parameter, but it never clarifies that 'id' refers to the evaluation ID or how to obtain it. The parameter is inferable from the resource name, but the description adds no semantic value beyond the schema's bare field name.

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

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

The description names a specific verb ('Get'), a clear resource ('filled evaluation form'), and enumerates the returned contents (evaluator, summary score and text, answers). It is clearly a read operation, though it does not explicitly distinguish itself from the sibling list_application_evaluations.

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 provides no guidance on when to use this tool versus the singular/listing alternatives such as hires_list_application_evaluations or hires_submit_feedback. The singular phrasing implies retrieving one evaluation, but no conditions, alternatives, or exclusions are stated.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the return includes questions and statuses, which is useful, but it does not disclose any other behaviors such as error cases or required permissions.

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

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

The description is a single, direct sentence with no filler. It front-loads the core purpose and is highly efficient.

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

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

With no output schema, the description carries the burden of return expectations. It states that questions and statuses are included, but leaves the exact structure and semantics of 'statuses' undefined. For a simple get operation, this is adequate but not fully comprehensive.

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 schema has 0% description coverage for the single 'id' parameter, and the description does not explicitly explain that 'id' refers to the form identifier. The phrasing 'a form' implies it, but the description does not compensate for the schema's lack of detail.

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

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

The description clearly states the action (Get) and resource (a form), and adds that it includes questions and their statuses. This distinguishes it from list_forms (plural) and get_question (single question), though it does not explicitly name 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 description provides no guidance on when to use this tool versus siblings like list_forms or get_question. It implies a single-form fetch but does not state conditions or exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered by structured data. The description's 'Get' operation is consistent with these hints and adds nothing contradicting or beyond them, so a baseline score of 3 is appropriate.

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

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

The description consists of a single six-word sentence that leads with the core action and object. There is no filler, redundant wording, or episodic content, achieving maximum informational density.

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 straightforward get-by-id tool with annotations covering the read-only safety profile, the description is minimally sufficient to allow invocation. However, it does not elaborate on the expected response shape, possible error conditions, or the behavior of the 'include' parameter, which leaves the agent partially reliant on external knowledge.

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

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

With schema description coverage at 50%, the description compensates somewhat by clarifying that 'id' is the identifier used to fetch the interview. The 'include' parameter already has a schema description ('Embed: candidate, application, job'), so the description provides minimal but sufficient added meaning for the undocumented id field.

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

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

The description explicitly states the action ('Get') and the resource ('interview'), plus the selection mechanism ('by id'). It is not a tautology and provides a clear, specific purpose, though it does not explicitly distinguish itself from sibling tools like hires_list_interviews or hires_list_candidate_interviews beyond the implied single-item vs. list difference.

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 provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, when to prefer listing interviews instead, or any contextual hint beyond the basic 'Get by id' operation, leaving the agent to infer usage on its own.

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

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

The annotations already declare readOnlyHint=true and destructiveHint=false, and the description 'Get a job by id or alias' is consistent with these, showing no contradiction. However, the description adds no extra behavioral context beyond the annotations (e.g., whether includes expand the response or if authorization is needed), so the burden is satisfied but only at a baseline level.

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

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

The description is a single sentence 'Get a job by id or alias.' with zero redundancy. It is front-loaded with the core action and the lookup key. There is no filler or ambiguity.

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 GET tool with annotations already covering read-only safety and a fully documented schema, the description is sufficiently complete. The omission of explicit return-value details is minor, but the tool information is complete enough for an agent to invoke it correctly, though it could mention that the response is the job object or that the 'include' param controls embedded data.

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 parameters are already fully described by the schema ('id: Job id or alias'; 'include: Embed: workflow, hiring_team, pipeline_stages'). The description adds no extra parameter semantics, but because the schema carries the full load, the baseline score of 3 is appropriate.

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

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

The description states a specific verb 'Get' and resource 'job' with lookup identifier 'id or alias'. It is clear and unambiguous, but does not explicitly differentiate from similar siblings like hires_get_career_job or hires_list_jobs, so it loses some points for lack of sibling distinction.

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

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

The description gives no guidance on when to use this tool versus alternatives. It does not mention 'use list_jobs to find multiple jobs' or name a specific alternate, and there is no mention of exclusions or preconditions. The use case is merely implied by the phrase 'by id or alias'.

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 and destructiveHint=false, so the description does not need to repeat safety. It adds value by disclosing that the response includes sender account, schedule timestamps, and cancelability, which gives context about the return data. No contradictions.

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

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

A single sentence that is concise, front-loaded with the action, and includes the key return fields. No wasted words.

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 get operation with one parameter and no output schema, the description covers the return content but omits any explanation of the input parameter ('id'). It also does not mention potential error cases or the meaning of cancelability, though these are not critical. The missing parameter description is a notable gap.

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

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

The schema has 0% description coverage, so the description must compensate, but it does not mention the 'id' parameter at all. It does not explain that the tool retrieves a message by ID, leaving the agent without semantic context for the single required input.

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 ('scheduled message'), and it differentiates from siblings like hires_get_notification_message by specifying 'scheduled' and listing the return fields (sender account, schedule timestamps, cancelability). This is clear and distinguishable.

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

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

The description implies this tool is for fetching a single scheduled message, contrasting with list tools, but it does not explicitly say when to use it instead of other get tools (e.g., hires_get_notification_message) or provide any exclusion conditions. Guidance is implicit 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 and destructiveHint=false, so the safety profile is covered. The description adds modest value by indicating the note has author and visibility fields, but it does not explain conditional embedding via the include parameter, error behavior, or what happens when include is omitted.

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 or repetition. Every word contributes to the meaning, and the core operation is immediately clear.

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

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

For a simple read-only tool with annotations covering safety, the definition is minimally adequate. However, with no output schema, the description gives only a partial picture of the return value, and it does not explain how include affects the response or how this tool relates to hires_list_notes. These are clear but not severe gaps.

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

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

Schema description coverage is only 50%, and the description adds no parameter-specific meaning. The id parameter is undocumented in both the schema and the description, and the include parameter's semantics are already fully covered by the schema description, so the description does not compensate for the gap.

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?

Description states a clear verb and resource ('Get a note') and names the main returned aspects ('author and visibility'). It is easily distinguishable from the sibling list tool by its singular focus, though it does not explicitly say 'single note by ID' or contrast with hires_list_notes.

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 guidance is given about when to use this tool instead of hires_list_notes or how to obtain the required note id. There are no contextual conditions, exclusions, or mention of prerequisites.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds value by listing the returned fields (subject, body, sender, recipient, schedule), which goes beyond what annotations provide. It doesn't describe any side effects, but for a read-only operation with no output schema, this is adequate and does not contradict 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?

The description is a single, front-loaded sentence that immediately states the tool's purpose, lists the returned fields, and provides the ID source. There is zero redundancy or fluff; every clause contributes useful information. It is efficiently structured for an agent to parse quickly.

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

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

Given the tool's simplicity (one integer parameter, no output schema) and the annotations covering read-only behavior, the description provides the essential context: what is returned and where to obtain the ID. It does not mention response format or pagination, but those are not necessary for a single-object retrieval. The description is sufficiently complete for correct invocation.

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 schema has a single integer parameter 'id' with no description, and schema coverage is 0%. The description compensates by indicating that IDs come from hires_list_candidate_messages, which gives the agent a source for the value. However, it does not explicitly explain that the ID represents a notification message identifier or its format. The guidance is helpful but not fully complete, so a 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 clearly states it retrieves a notification email and enumerates the specific fields returned (subject, body, sender, recipient, schedule). It also explicitly references the source of IDs (hires_list_candidate_messages), which distinguishes this tool from other 'get' tools like hires_get_message or hires_get_application. The verb 'Get' plus the resource 'notification email' and the detail make the purpose unambiguous.

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

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

The description provides a clear usage signal by stating that IDs come from hires_list_candidate_messages, which tells the agent exactly where to obtain the required input. While it doesn't explicitly mention alternatives or when not to use this tool, the reference to the list function implies the proper workflow. This is sufficient guidance for a simple retrieval tool.

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?

The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is established. The description adds a useful behavioral detail by saying the result includes 'all steps and schedule settings,' but it does not go further into response shape, pagination, or error behavior.

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

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

The description is a single sentence with no filler. It front-loads the action and resource, then adds the most important detail about what is returned, which makes it easy to scan.

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

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

For a simple one-parameter read-only tool, the description covers the essential information: which resource is fetched and what is included. There is no output schema, but the phrase 'all steps and schedule settings' partially describes the return content. It leaves out error/not-found behavior, but that is a minor gap for a context of this complexity.

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

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

The single required 'id' parameter has no schema description, and the description doesn't explicitly document it. The tool name and the phrase 'a nurture campaign' make it inferable that id identifies the campaign, but the description itself adds little direct parameter-level meaning.

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

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

The description clearly states the action: 'Get a nurture campaign' with the specific resource, and even narrows the return content to 'all steps and schedule settings.' It distinguishes itself from the list sibling (hires_list_nurture_campaigns) by emphasizing a single campaign with full detail.

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

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

The description implies this is for fetching one specific nurture campaign by id, which is reasonably clear from the singular 'a nurture campaign.' However, it never explicitly names an alternative like hires_list_nurture_campaigns for listing many campaigns, nor does it state when not to use this tool.

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 and destructiveHint=false, so the safety profile is established. The description adds the output context of 'type and options', which is mildly useful, but it does not disclose behavioral details such as error handling, required permissions, or response structure.

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

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

The description is a single eight-word sentence with no filler. It front-loads the action and resource, and every word contributes meaning.

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

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

For a simple read-only getter with one required parameter, the description is mostly adequate, and the mention of 'type and options' helps without an output schema. However, it leaves usage guidance and parameter semantics to inference, and says nothing about the response shape beyond those two fields.

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 0% and the description does not explicitly explain the 'id' parameter. The meaning is inferable from the tool name and resource, but the description does not compensate for the schema gap by clarifying what id refers to, its format, or how to obtain it.

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

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

The description states a clear verb and resource: 'Get a question' also names two key fields returned ('type and options'). It does not explicitly differentiate from sibling tools like hires_list_questions or hires_get_form, but the singular phrasing and resource name make the primary purpose unmistakable.

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 guidance is given about when to use this tool versus alternatives such as hires_list_questions or hires_update_question. The intended use is strongly implied by the name and description, but there are no explicit conditions, exclusions, or alternatives mentioned.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds a useful domain detail about the user object's default_mail_account_id, but it does not disclose other behavioral traits such as exact return shape, error behavior, or whether non-default fields are populated.

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

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

The description is two short, purposeful sentences. The core action is front-loaded, and the second sentence earns its place by adding a practical downstream use that is not present in the schema or annotations.

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

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

For a simple one-parameter read-only getter, the description is largely complete: it names the target resource and highlights a relevant field for downstream email operations. It does not spell out the full return object, but 'Get a user' plus the specific field mention makes the expected output reasonably inferable.

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

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

With schema description coverage at 0%, the description needed to compensate for the id parameter, but 'by id' only restates what the schema already signals. It adds no format, constraints, or clarification beyond the obvious meaning of the required number id.

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

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

The description clearly states a verb and resource: 'Get a user by id.' It is immediately distinguishable from the sibling list tool (hires_list_users) because it targets a single user and adds the unique default_mail_account_id detail that no other getter mentions.

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 provides a concrete use case: the returned user's default_mail_account_id can serve as from_account_id when sending emails. This gives the agent clear contextual guidance for why or when to call this tool, though it does not explicitly mention exclusions or alternative tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds no behavioral context beyond the basic 'get' operation—no mention of ordering, return format, workflow-to-job scope, or any edge conditions.

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

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

The description is a single, immediately readable sentence with no filler or repetition. It front-loads the verb and object, and every word contributes to the core meaning.

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

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

For a simple read-only getter, the description is minimally adequate: annotations cover the safety profile and the schema documents the required id. However, it leaves company_id unexplained and does not clarify how this differs from the workflow-stage listing sibling, so there are identifiable gaps.

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

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

Schema coverage is only 50%: 'id' is described as 'Workflow id', but 'company_id' has no description. The tool description does not compensate by explaining either parameter or the role of company_id, so an agent receives no additional semantic clarity.

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

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

The description states a clear verb ('Get') and resource ('stages of one workflow'), and the singular 'one workflow' helps distinguish it from sibling tools like hires_list_workflow_stages. It is not as explicit as naming the alternative, but the scope is understandable.

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 explicit guidance is given about when to use this tool versus alternatives. The singular phrasing implies a single-workflow use case, but the description does not mention the more comprehensive list_workflow_stages or explain when one should be preferred over the other.

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?

The description discloses the concrete state change (status becomes hired, hired_at is set), which is consistent with the destructiveHint annotation. It adds detail beyond the annotation about what gets modified, and no contradiction exists. It does not mention potential side effects like notifications, but the destructiveHint already signals mutation, so the added specificity is sufficient.

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

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

The description is a single, front-loaded sentence that states the core action and effect without extra words. It is appropriately sized and avoids redundancy, making it efficient for an agent to parse.

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

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

The tool is a simple mutation with two parameters and no output schema. The description covers the primary effect but omits context such as whether any preconditions exist (e.g., application stage), what the response contains, or how it differs from similar actions like advance_application. Given the destructive nature and sibling variety, a bit more context would help, but it is not severely lacking.

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 50% (only 'include' is described). The description does not clarify the 'id' parameter, which is required but undocumented in the schema. It adds no parameter semantics, failing to compensate for the gap, though the tool name suggests id is an application identifier.

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

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

The description clearly states the action: marking an application as hired, and specifies the effect (status becomes hired, hired_at is set). It distinguishes this from siblings like reject_application or advance_application by naming the exact state change. The verb 'mark' and resource 'application' are 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?

The description provides no guidance on when to use this tool versus alternatives such as update_application, advance_application, or reject_application. It does not state prerequisites or when hiring is appropriate, leaving the agent to infer usage from the name and effect.

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 and destructiveHint=false, so safety is covered. The description adds that it returns file metadata and download URLs, which is useful context beyond the annotations. However, it does not mention pagination, error behavior, or any edge cases, so it adds moderate value relative to the annotation baseline.

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

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

The description is a single, front-loaded sentence with no filler. It efficiently communicates the verb, resource, and output contents, making it easy to parse quickly.

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

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

For a simple list tool with one parameter and no output schema, the description is mostly complete: it states what is returned (metadata and download URLs). However, it omits details like whether the list is paginated or if all attachments are returned at once. Given the annotations cover safety, this is adequate but not thorough.

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?