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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true. The description adds genuinely new and important context beyond that: the note is confidential and never visible to the candidate, which materially affects content the agent writes. It stops short of covering permission requirements or whether notes can later be edited.

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

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

A single front-loaded sentence with the key constraint in parentheses and no wasted words. The visibility caveat arrives before the agent starts composing note text, which is the right order.

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

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

No output schema and no annotations cover the parameters, so the description is the only explanatory layer for a 4-parameter write tool. Without any explanation of what 'post' is or why 'page_hint' exists, an agent cannot reliably populate the arguments.

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% across 4 parameters, so the description must compensate and largely fails. 'Applicant' and 'note' map loosely to applicant_id and text, but 'post' and 'page_hint' are never mentioned and remain completely opaque in both schema and 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?

States a specific verb and resource ('Add a confidential team note to an applicant'), which is unambiguous about the operation. It does not name a sibling or clarify its relationship to delete_note/list_applicants, so an agent must infer the workflow boundary from the name alone.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no alternative is named despite delete_note being a sibling. The confidentiality clause implies an internal-notes workflow but does not state prerequisites 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 non-readonly, idempotent, non-destructive, open-world behavior. The description adds useful detail beyond annotations by stating that it returns the id and that an exact-title duplicate yields the existing folder rather than an error.

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

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

Two short sentences with no waste. The primary action and return value are front-loaded, followed immediately by the important duplicate-handling rule.

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 create tool with no output schema, the description covers the action, return value, and duplicate behavior. It could still say more about title requirements or authorization, but the essential calling information is present.

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 parameter has 0% schema description coverage, so the description must carry meaning. It does clarify that the title is matched exactly for duplicate detection, but it does not explain title constraints, formatting, or validation rules.

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

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

Specific verb and resource: 'Create a new resume folder' plus the return value ('return its id'). It also distinguishes behavior from siblings that list or assign folders by explaining duplicate-title handling.

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 create intent is clear, and the duplicate-title rule implies when reuse occurs. However, it does not explicitly say when to call this versus list_folders or set_applicant_folders, nor does it state any 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 destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds that deletion is scoped to a single note and limited to deletable ones, but omits critical behavior for a substring-matched deletion: what happens if several notes contain the text, if none do, or whether the match is case-sensitive. No contradiction 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 short sentences, front-loaded with the operation and target, with the matching predicate and scope limit following immediately. Nothing is wasted.

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

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

This is a destructive, non-idempotent mutation with no output schema, and the description does not say what is returned, how ambiguity (multiple or zero matches) is handled, or what `page_hint` does. For a delete tool, those omissions are significant.

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 carries the full burden, yet it only explains `text_contains` (substring match). `post`, `applicant_id`, and especially `page_hint` — which likely determines which page of notes is searched and thus whether the call succeeds — are left entirely undefined in both schema and 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?

States a specific verb and resource ('Delete one team note') and narrows the target via a matching predicate (`text_contains`), which clearly separates it from the additive sibling add_note. It does not explicitly name the sibling, but the destructive verb makes the distinction obvious.

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 parenthetical 'e.g. to fix a mistaken note' gives one concrete use case, and 'Only notes you can delete in the panel' implies a permission/scope limit. There is no guidance on when not to use it, how to discover the right note first (e.g. via list/get tools), or what to do if multiple notes match.

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 says the tool downloads a file and returns a local path, defaulting to JOBINJA_DOWNLOAD_DIR/<post>/. That implies creating or writing a file on the local filesystem, which contradicts the readOnlyHint=true annotation stating the tool does not modify its environment.

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

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

Two short sentences front-load the action and result, then immediately state the default folder. There is no unnecessary text, and the key scoping detail appears early.

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

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

For a four-parameter download tool with no output schema, the description covers the return path and default folder but omits important details: what dest_dir does, when page_hint matters, overwrite behavior, and error handling when no resume exists. It is not complete enough for reliable 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?

Schema description coverage is 0%, so the description must compensate. It partially clarifies 'post' through the default folder path and implies 'applicant_id' via 'an applicant's attached resume,' but says nothing about 'dest_dir' or 'page_hint,' leaving half the parameters undocumented.

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 ('Download an applicant's attached resume file') and names the return value ('local path'). It is clear what the tool does, though it does not explicitly distinguish itself from the sibling download_resumes or get_resume_text.

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

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

Usage is only implied by the singular 'an applicant's attached resume.' The description provides no explicit when-to-use guidance, no when-not-to-use conditions, and no reference to alternatives such as download_resumes for multiple resumes or get_resume_text for extracted text.

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

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

Adds real behavior beyond the annotations: writes at most `limit` files into JOBINJA_DOWNLOAD_DIR/<post>/ (or dest_dir), returns newest first, and — critically — discloses that viewing pending applicants marks them as seen. That side-effect disclosure is exactly the kind of context annotations don't carry. There is mild tension with readOnlyHint=true, but the description tells the truth rather than misleading, so it is disclosure, not 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?

Three short lines, purpose front-loaded, then destination/limit mechanics, then the side-effect warning. Every sentence adds information; nothing restates the title or 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 5-parameter side-effecting tool with no output schema, it covers destination, ordering, cap, and the seen-marking side effect. It could still say what is returned (file paths?) or what happens when existing files are present, but an agent can call it correctly as written.

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 has to carry the burden, and it mostly does: `limit` is an upper bound on files, `post` determines the subdirectory, `dest_dir` overrides the default location, and status/starred are filters (deferred to list_applicants). It omits the default values (limit=25, starred=false) and the allowed status values, so not a 5.

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

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

States a specific verb and resource with scope: 'Bulk-download resumes for a job ad, newest first'. The word 'Bulk' plus the job-ad scoping distinguishes it in practice from the sibling download_resume, though it never names that sibling explicitly.

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

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

It implies usage (bulk fetch with optional status/starred filters) and routes the reader to list_applicants for filter semantics, but never states when to prefer this over download_resume (single file) or when not to use it. 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?

The description discloses that "viewing an unreviewed (pending) applicant marks it as seen" — a persisted state change — while annotations declare readOnlyHint=true. That is a direct conflict on the exact property the readOnly hint is meant to guarantee, and an agent relying on the annotation could call this as a harmless peek and silently mutate applicant state. The description itself is honest; the mismatch is what forces the low 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?

Front-loaded with the payload contents, then parameter provenance, then the side-effect warning — a sensible ordering with no filler. The telegraphic, fragment style is dense but every clause carries information; minor deduction only for the slightly clipped phrasing that makes the side-effect note easy to skim past.

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

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

With no output schema, the description does a good job enumerating return fields, and it flags the seen-marking side effect. But for a 3-parameter record fetch with a state-changing side effect, it leaves the required `post` parameter undefined and says nothing about behavior for a nonexistent applicant or invalid page_hint.

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 carry the load. It explains applicant_id's source and page_hint's meaning ("the list page it was on"), which is real added value, but the required `post` parameter is never mentioned at all and no formats are given (string id shape, how post interacts with the applicant lookup).

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

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

States a specific verb and resource ("Get one applicant") and enumerates exactly what is returned: contact info, profile fields, Jobinja profile text, star, team notes, decision, rejection reason. This is clearly a single-record fetch, distinguishable from list_applicants and from the resume/download siblings without opening any schema.

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

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

Explicitly routes the agent: applicant_id "comes from list_applicants," and page_hint is described as an optional accelerator ("makes lookup faster"), so the agent knows how to obtain inputs and when the optional param is worth supplying. It does not, however, say when to prefer a sibling such as get_resume_text over this tool for resume content.

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 openWorldHint=true, and the description adds genuinely useful context beyond that: output is truncated to max_chars, it is cheap in tokens relative to the PDF, and scanned PDFs degrade to little or no text. It doesn't say what happens at the truncation boundary or whether page_hint changes the extraction window.

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

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

Three short sentences, front-loaded with what the tool returns, then the cost rationale, then the failure mode and escape hatch. Every sentence carries information an agent needs.

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

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

For a read-only extraction tool with no output schema, the description covers the return shape, truncation, and the scanned-PDF failure mode well. However, with 0% schema coverage across four parameters, the unexplained page_hint and the underspecified post/applicant_id identifiers leave the invocation contract incomplete.

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

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

Schema description coverage is 0%, so the description must carry the parameter meaning, and it only explains max_chars (via the truncation clause). post and applicant_id are only indirectly gestured at, and page_hint is entirely undocumented in both the schema and the description, leaving a required identifier and an optional hint unexplained.

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

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

States a specific verb and resource ('Extracted plain text of an applicant's PDF resume') plus the truncation behavior, so the agent knows exactly what it gets back. It also implicitly distinguishes itself from download_resume by naming that sibling as the alternative for scanned PDFs.

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

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

Explicitly names the condition that selects the alternative: image-only PDFs should go to download_resume, and the token-cost note explains why this tool is preferred otherwise. It does not cover other contextual decisions, such as when to prefer get_applicant or how page_hint should influence the choice.

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, openWorldHint=true and idempotentHint=false, so the safety profile is covered. The description adds that the session is 'saved' (persisted state), but it doesn't say what a negative result looks like or whether the check touches the network, which matters given the non-idempotent and open-world hints.

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, and the two key outcomes (logged in / which company panel) are stated up front.

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

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

With no parameters and no output schema, the description should hint at the return shape; 'which company panel it uses' partially does, but an agent still doesn't know the exact response fields or failure signal. Otherwise complete for a trivial status-check 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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No parameter-level claims are needed or missing.

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

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

States a specific verb ('Check') and a specific resource ('saved Jobinja session'), plus two concrete facts it resolves: login state and the company panel in use. This is clearly distinct from sibling tools like open_login_window or the applicant-listing 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?

Usage is only implied: an agent can infer this is a pre-flight session check, but the description never says when to call it versus open_login_window, nor what to do when the session is expired. No explicit when/when-not guidance is provided.

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 openWorldHint=true, so the safety profile is covered. The description adds real context beyond that: 25 records per page, newest-first default ordering, and the shape of each returned row including applicant_id for follow-up tools.

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

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

Front-loaded with the core action and page size, then parameter semantics in tight label-colon lines. No filler, and each line carries distinct information.

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

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

For a six-parameter read-only list tool with no output schema, it covers paging, ordering, filtering, and the returned fields. It stops short only of clarifying the boundary against the folder-scoped sibling.

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 carry the load, and it does: it defines `post` with its source and an example, enumerates every `status` value and `sort` value with meaning, and explains the starred/has_notes filters. Only `page` is left unstated beyond the implied 25-per-page paging.

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

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

The description states a specific verb (list) and resource (applicants), scoped to a job ad, plus paging behavior. It does not distinguish itself from the sibling list_folder_applicants, which an agent could reasonably confuse it with.

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

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

It implies usage by explaining that `post` comes from list_posts and by defining filters, but it never states when to prefer this over list_folder_applicants or screen_applicants. The routing decision is left to inference.

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

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

Annotations already declare this is a read-only operation, and the description adds useful behavioral detail beyond them: 25 results per page and that each row includes its `post`. It still omits ordering, error behavior, and whether additional pagination metadata is returned.

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

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

Two short sentences, front-loaded with the core operation and followed by pagination and row-content details. There is no redundant or filler text.

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, two-parameter listing tool without an output schema, the description covers the essential call behavior: folder scope, page size, and a notable returned field. It could be more complete about result shape and pagination limits, but the core invocation context is present.

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 carry parameter meaning. It partially does: it explains that results are 25 per page, clarifying the `page` parameter, and frames `folder_id` as a resume folder, but it does not explain how to obtain the folder ID or how page numbering works.

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: list applicants saved in a resume folder. It does not distinguish this from the sibling `list_applicants`, so sibling routing is left implicit.

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

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

The folder-scoped wording implies this is for listing applicants within one folder, but the description never says when to use it instead of `list_applicants` or other applicant-listing tools. No exclusions or prerequisites are given.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=false, so the safety profile is mostly covered. The description adds scope ('company's') and mentions the returned fields, but it does not elaborate on behavior beyond annotations such as whether folders are shared globally or edge cases.

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 wasted words. It states the resource and the key returned information 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?

Given zero parameters, rich annotations, and an output schema, the description is nearly complete for invocation purposes. It could mention how folders relate to folder-scoped siblings like list_folder_applicants, but nothing essential is missing.

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

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

The tool has zero parameters, so there is no parameter semantics burden; baseline is 4. The description does not need to explain inputs beyond noting the listing scope.

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 ('List the company's resume folders') and adds useful return detail ('with their ids and per-stage counts'). It is clear what the tool does, but it does not explicitly differentiate itself from sibling list_folder_applicants or explain folder-related context.

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 guidance on when to use this tool, when not to use it, or which sibling to choose for related tasks. The listing intent is obvious from the name and description, but no usage conditions or alternatives are provided.

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 openWorldHint=true, so the safety profile is covered. The description adds genuine behavioral context beyond that: the six possible status values, the fact that results carry per-stage applicant counts, and the cross-tool key (`post` short id) an agent needs to chain into other calls. It does not mention pagination or result limits, which matters for a list endpoint.

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

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

Front-loaded with the core action and scope, then a compact status list, then the result shape. No filler, though the final item-shape sentence partly duplicates the existing output schema and is the least load-bearing line.

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?

An output schema exists, so the return-value explanation is optional reinforcement rather than a gap-filler. With safety covered by annotations and the only parameter fully enumerated, the remaining shortfall is workflow guidance — which sibling to use for applicant-level queries — for an agent operating among 18 related tools.

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

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

Schema description coverage is 0% and the single `status` parameter has no enum in the schema, so the description carries the full burden — and it does, enumerating all six accepted values with `all` as the implied default. What it lacks is any hint about how filtering interacts with counts or what an unknown status does.

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

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

States a specific verb and resource ("List the company's job ads with applicant counts"), which is clearly distinct from the applicant-oriented siblings like list_applicants and get_applicant. It does not explicitly name an alternative, so the differentiation comes from the resource noun rather than an explicit contrast.

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

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

Usage is implied by the status vocabulary, but there is no explicit statement of when to call this versus list_applicants or list_folder_applicants, and no prerequisites or exclusions. The note that `post` is the short id "used by the other tools" hints at workflow ordering but never spells it out.

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

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

It adds vital information not in the structured data—the mapping between rejection code and the human-readable panel label. This is more informative than simply stating the data exists.

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

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

The definition is extremely tight and focused, providing the critical functional definition in a single, highly efficient statement.

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

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

For a zero-parameter lookup function, the description is highly complete. It tells the agent exactly what the tool provides so it can be invoked safely and 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?

Since the tool accepts zero parameters and schema coverage is 100%, the baseline score of 4 applies. The description does not need to compensate for schema gaps.

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 defines the resource (rejection reasons), the context (accepted by reject_applicant), and the specific format of the data provided (code to panel label).

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 offers no guidance on when to use this specific list tool versus other similar functions in the extensive list of siblings. It is purely descriptive of function.

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

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

Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint=false), it discloses that the user supplies credentials themselves — no credential passing by the agent — and that the call blocks for up to 10 minutes. What is missing is what happens at timeout (failure vs. pending) and whether the tool can be re-invoked safely given idempotentHint=false.

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

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

Two sentences, no waste, with the purpose front-loaded and the trigger condition following. The parenthetical timeout detail earns its place.

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

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

With no parameters, no output schema, and annotations covering the safety profile, the description covers nearly everything an agent needs. The remaining gap is post-call behavior — what a returned result or timeout means for retry — which matters because the call is interactive and non-idempotent.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description's mention of the 10-minute wait is useful context about invocation behavior rather than parameters.

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

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

States a concrete verb and resource — opening a browser window on the user's screen for signing in to the Jobinja employer panel — which no sibling tool does. It also names the related status tool, so an agent can place it in the workflow immediately.

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

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

Gives explicit trigger conditions: 'first use, or when jobinja_status reports the session expired', naming the sibling whose output selects this tool. Nothing about when to call it is left to inference.

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

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

Annotations already flag destructive/openWorld/non-idempotent, but the description adds the crucial consequence the annotations cannot express: Jobinja notifies the candidate, so this is externally visible and irreversible in a human sense. It further discloses that dry_run populates the form without submitting, which is meaningful behavioral context beyond the hints.

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

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

Three short sentences, front-loaded with the action and reason-code source, followed by the side effect and the dry-run option. No filler, and the parenthetical Persian term aids matching against the UI.

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

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

With no output schema and six parameters, the description covers the risky and ambiguous parts (notification side effect, message semantics, dry_run) well. It stops short of explaining `page_hint` or what a successful call returns/changes, leaving a small but real gap for a destructive 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 0%, so the description must carry all parameter meaning. It does well for `reason`, `message` and `dry_run`, but says nothing about `post`, `applicant_id`, or `page_hint` (the last being especially opaque — likely a pagination/retry aid). Half the parameters remain undefined in both schema and prose.

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

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

States a specific verb and resource ('Mark an applicant as rejected') and immediately pins down the mechanism ('with a reason code from list_rejection_reasons'), which names a sibling tool and disambiguates the input source. An agent can distinguish this from restore_applicant or add_note without opening the schema.

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

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

Explicitly routes the agent: reason codes come from list_rejection_reasons, and internal commentary belongs in add_note rather than `message` ('not an internal note: use add_note for that'). It also explains when to use dry_run, giving a clear non-destructive trial path.

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 disclose destructiveHint=true, idempotentHint=false, and openWorldHint=true. The description adds meaningful context beyond that: it names the exact state the applicant returns to and discloses the candidate-notification side effect of the operation.

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

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

Two short sentences, with the core action ('Undo a decision') front-loaded and no filler. Every clause adds information an agent can use.

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, non-idempotent mutation with no output schema, the description covers the state transition and the notification side effect, which is the most important behavioral context. It is still incomplete on permissions/requirements and on any of the three parameters.

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 carry parameter meaning, but it never mentions post, applicant_id, or page_hint. The applicant_id is inferable from 'an applicant,' yet page_hint is completely unexplained, leaving a real 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?

States a specific verb and resource ('Undo a decision: move an applicant back to awaiting decision') with the exact target state, which lets an agent distinguish it from the sibling reject_applicant. It does not name the sibling explicitly, 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?

'Undo a decision' implies the usage context, and the existence of reject_applicant makes the reverse relationship inferable. However, there are no explicit when-to-use/when-not conditions or named alternatives, so guidance is only implied.

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

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

The description is unusually informative about behavior: it discloses field inclusion/exclusion, token-cost tradeoffs, per-page latency, and the side effect that 'opening pending applicants marks them as seen'. However, that side effect conflicts with the declared readOnlyHint=true annotation, so an agent relying on the annotation's safety guarantee would be misled. Content is rich but the safety-relevant inconsistency with structured metadata caps the 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?

Front-loaded with the purpose and scope, then the returned fields, then the routing advice. Dense but each sentence carries information; only the bilingual coda about usage is redundant with the earlier routing 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?

There is no output schema, and the description does a good job describing the digest contents and omissions, so the return shape is covered. But with 0% schema coverage and 5 parameters, key inputs (required `post`, `status`, `profile_chars`) remain unexplained, leaving an agent guessing how to scope the screening 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 0%, so the description must carry the burden, and it only partially does: it explains resume_chars ('first `resume_chars` characters of the PDF resume text') and page size ('up to 25'), and gestures at profile_chars via 'key profile fields', but says nothing about the required `post` parameter or the `status` filter. The two most decision-relevant parameters are left undefined.

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

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

States a specific verb and resource ('Compact screening digest of one page (up to 25) of applicants') plus the exact field set returned, so an agent can distinguish it from get_applicant and get_resume_text immediately. The stated intent, fast low-token shortlisting, frames the resource precisely.

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

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

Explicitly says to read digests first and to call get_resume_text / get_applicant only for promising applicants, naming the alternatives and the condition that selects them. It also gives a cost expectation ('about a minute per page') that supports the bulk-vs-single decision.

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

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

Annotations already declare the mutation profile (non-read-only, destructive, idempotent, open-world), so the description does not need to repeat that. It adds useful behavioral context by saying add/remove accept folder ids or exact titles and that the tool returns the applicant's folders afterwards.

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 short, front-loaded with the core operation, and each sentence adds useful information. The parenthetical prerequisites are compact and relevant.

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 5-parameter mutation tool with no output schema and 0% schema description coverage, the description covers the core operation, lookup/creation prerequisites, and return behavior. However, it does not explain the required post parameter or the page_hint parameter, leaving meaningful 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 0%, so the description must carry parameter meaning. It explains add/remove accept folder ids or exact titles, but it leaves post, applicant_id, and page_hint unexplained; post is required and opaque.

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 pair and resource: add/remove an applicant from resume folders. It also distinguishes this tool from folder-management siblings by pointing to list_folders and create_folder for related 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?

It gives clear context for use and prerequisites, telling the agent to look up folders via list_folders and to use create_folder first for new folders. It does not explicitly state when not to use the tool, but the intended usage is 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=false, idempotentHint=true, and destructiveHint=false, so the mutation profile is covered. The description adds a genuinely useful, non-redundant fact — stars are internal to the company (visibility scope) — but says nothing about permissions, whether unstarring destroys prior state, or rate limits.

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

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

Two short sentences, the primary action and its parameter mapping front-loaded, with the visibility caveat as trailing context. 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?

No output schema and no annotation gaps on safety, so the description mainly needs to cover the four undocumented parameters. It handles 'starred' well but leaves 'post' (required) and 'page_hint' undefined, so an agent must guess at part of the 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?

With 0% schema description coverage, the description must compensate, and it does for the key ambiguity: it explains that starred=true stars and starred=false unstars, resolving the boolean default of true. However, the required 'post' parameter and the 'page_hint' parameter are left entirely unexplained, so the compensation is only partial.

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

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

Names a specific verb pair (star/unstar) and the exact resource (an applicant), so the agent knows precisely what changes. It is clearly distinct from siblings like set_applicant_folders, reject_applicant, or add_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?

Usage is implied by the boolean toggle, but the description never states when to star versus when another tool (e.g., set_applicant_folders or add_note) is the better choice, nor any preconditions. Minimum viable guidance only.

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