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

No annotations are provided, so the description carries the full behavioral burden. It implies a mutation (adding a note) but says nothing about whether notes are appended vs. overwritten, whether the job must already exist, permission requirements, or error behavior. For a write tool with zero annotation coverage this is a significant gap.

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

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

Two short sentences, front-loaded with the action and followed by the usage trigger. No filler or redundancy; every sentence earns its place.

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

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

The tool is simple (2 documented params, no output schema, no annotations), and the description covers purpose and trigger. It omits how the new note relates to existing notes and the sibling update_job_note/delete_job_note, which is the main remaining gap for an agent choosing between them.

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

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

Schema description coverage is 100%, so both job_id and content are already documented in the schema; baseline is 3. The description's examples (interviewer name, follow-up date, salary info) add mild color about suitable content but no format or constraint detail beyond the schema.

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

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

States a specific verb+resource: 'Add a note to a job application.' An agent immediately knows what is created and against which entity. It does not, however, differentiate itself from the sibling tools update_job_note and delete_job_note, so it falls short of a 5.

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

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

Gives a concrete trigger condition ("Use this when the user wants to record information about a job") plus illustrative examples of the kind of content intended. It does not mention when NOT to use it or point to update_job_note for modifying existing notes, so no explicit alternatives routing.

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

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

With no annotations, the description carries the full behavioral burden, yet it does not disclose that 'delete' is irreversible, whether 'reject' or 'proceed' can be undone, what permissions are required, or how partial failures across the job_ids array are handled. For a destructive bulk mutation this is a meaningful omission.

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 tight sentence, front-loaded with the verb and resource, with operations listed after the colon. Nothing is wasted, though it is arguably too short given the destructive operations it wraps.

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?

A bulk, partly destructive mutation invoked across many job IDs with no annotations and no output schema should explain irreversibility, permissions, and partial-failure semantics. None of that is present, so the agent lacks what it needs to call this safely.

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

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

Schema coverage is 100% and the action enum values are fully documented in the schema itself; the description merely restates 'delete, reject, or advance to next stage'. No additional syntax, ID format, or batching-limit detail is added, so baseline 3 applies.

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

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

States a specific verb (bulk update) and resource (jobs) and enumerates the three supported operations, so the agent knows exactly what it does. It does not distinguish itself from the single-job siblings (delete_job, update_job_status), leaving the agent to infer that this is the batch variant.

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 delete_job, update_job_status, or reject flows. The word 'bulk' implies multi-job use, but there is no explicit when/when-not or mention of prerequisites such as job ownership or state restrictions.

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

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

No annotations are provided, so the description carries the full behavioral burden. It says nothing about whether the chat is stateful, how conversation_id affects context, credit/rate-limit costs, latency, or what the caller gets back. For a conversational tool with zero annotation coverage this is a substantial gap.

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

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

A single front-loaded sentence with the action and resource first and the qualifying topic list second; there is no filler. It is appropriately sized, though it trades brevity for the absence of the behavioral detail noted above.

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 only two parameters, no annotations, and no output schema, the description is only minimally complete. It omits how the reply is returned and whether context persists across calls, information an agent needs to chain a multi-turn conversation 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 both message and conversation_id are already documented in the schema. The description adds no extra semantics beyond what the schema provides (e.g., how conversation_id should be obtained or what happens if it is omitted), so the baseline 3 applies.

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

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

States a specific verb (Send) and resource (message to the JobJourney AI chatbot) plus the scope of topics it covers (career advice, job search tips, general help). It is clear on its own, but it does not distinguish itself from the many chat-sounding siblings such as send_coffee_chat_message or send_coffee_chat_request, so an agent has no explicit signal for when this AI chatbot differs from those.

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 topic list (career advice, job search tips, general help) implies when the tool is appropriate, but there is no explicit when-to-use/when-not guidance and no named alternative among the sibling tools. Usage must be inferred from the subject matter rather than stated.

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

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

No annotations are provided, so the description carries the full disclosure burden. It implies a read-only check and notes the decision is subscription-based, but says nothing about required authentication, whether it can fail on unknown features, or the shape of the result.

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

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

A single front-loaded sentence with no filler. The core purpose is stated immediately and nothing is wasted.

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

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

For a one-parameter read tool this covers the essentials, but with no output schema the description should state what is returned (a boolean, an entitlement object?) so the agent knows how to consume the result. It leaves the return contract implicit.

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

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

Schema description coverage is 100% and the single parameter is fully enumerated, so the schema already documents the feature_name value set. The description adds no format or constraint detail beyond the schema, making the baseline 3 appropriate.

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

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

States a specific verb (check) and resource (access to a specific AI feature), with the gating factor (subscription) named. It is distinguishable from most siblings, though it does not explicitly differentiate from get_subscription_status, which addresses the same subscription domain.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of the related get_subscription_status or get_subscription_plans tools. The agent must infer that this is a pre-flight gate before generating features.

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

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

With no annotations, the description carries the full burden. It discloses that the check compares a local plugin against a published version and returns an update command, implying a read-only network operation that does not mutate anything. It does not state network reachability requirements, behavior when already up to date, or whether anything is cached.

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

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

A single efficient sentence with no filler, front-loading the operation and then the returned artifact. Every clause earns its place.

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

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

For a zero-param, read-only diagnostic with no output schema, the description covers what it does and what it returns (the update command). Minor gaps remain around the not-up-to-date case and environment requirements, but nothing essential for invocation is missing.

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

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

The tool takes zero parameters and the schema is empty, so there are no parameter semantics to document. The baseline of 4 applies since nothing needs clarifying.

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 resource (published version of the local JobJourney plugin) plus an outcome (show the update command). It is clearly distinguishable from all siblings, none of which deal with plugin versioning or updates.

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 intent is self-evident for a version-check utility, so usage is implied rather than stated. There is no explicit guidance on when to call it (e.g., on startup, before an upgrade) and no alternatives are referenced, but none are needed here.

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

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

With no annotations, the description carries the full burden. It does disclose the return content (which sites have saved sessions), implying a read-only operation, but says nothing about permissions, rate limits, or how session expiry is represented.

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 what it checks and followed by what it returns. The second sentence adds return-value detail rather than repeating the first, so nothing is wasted.

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

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

For a parameterless, annotation-free status check with no output schema, the description covers what the tool inspects and what it reports. The only gap is not linking the outcome to a follow-up action such as login_jobsite.

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 the baseline of 4 applies; there is nothing for the description to disambiguate beyond the schema.

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

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

States a specific verb+resource: checks cookie/login status for job sites and reports which sites have saved sessions. It is distinguishable from most siblings, though it doesn't name its closest relative, login_jobsite, which performs the complementary action.

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 check before scraping or before calling login_jobsite, but the description never says when to use it, when not to, or what to do if a site shows no session.

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

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

No annotations provided, so the description carries full behavioral burden. It mentions that it returns whether the URL changed or new content appeared, but does not disclose typical side effects, potential navigation away, or required page state. The click action's destructive/irreversible nature is not addressed.

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

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

Two sentences, front-loaded with the core action and examples, no wasted words. The return behavior is stated in a second brief 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 tool with no annotations and no output schema, the description is minimal. It covers the basic action and return hint, but misses prerequisites (e.g., page must be loaded), error conditions (e.g., element not found), and any timing/waiting behavior. Adequate but 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 coverage is 100%, so parameters are fully documented in the schema. The description adds no additional parameter semantics, but baseline for full coverage is 4. However, the description does not clarify how the 'description' parameter should be used beyond what the schema says.

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 (Click) and resource (button or link on the current page) with concrete examples (Next, Submit, Continue). It also mentions the return value (URL change or content appearance).

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

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

Implies usage context (clicking on current page) but does not explicitly state when to use this versus alternatives like fill_form_field or open_application_page. 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?

No annotations are provided, so the description carries the full behavioral burden. 'Clean up resources' gestures at side effects but never specifies what is destroyed (cookies, session tokens, in-progress state), whether the call is idempotent, or what happens if no browser session is open.

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 short sentence with the action front-loaded and no filler. It is exactly as long as the content justifies.

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-argument teardown with no output schema, little is strictly required, and the description covers the core action. It still omits lifecycle context an agent would want: whether a session must be open, whether failure is possible, and whether the operation is safe to repeat.

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; the schema is trivially complete. Baseline 4 applies for a no-parameter tool.

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 ('Close the browser session') plus a second clause about resource cleanup, so an agent immediately knows what happens. It does not, however, differentiate itself from the sibling browser-automation tools (open_application_page, click_element, take_page_screenshot) or clarify that this is the teardown counterpart to those.

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

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

Usage is only implied: the naming and lifecycle nature of 'close the browser session' make it obvious this is a terminal step after browser automation. There is no explicit when-to-use trigger, no statement about prerequisites (an open session), and no note about what to do instead if no session 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. While 'AI-powered mock interview' implies an interactive simulation, it doesn't explain what happens during the interview, whether it's time-limited, what input is expected, or whether it's stateful. The phrase 'Simulates a real interview experience' is marketing filler rather than actionable behavioral detail.

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

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

Two short sentences with zero waste, front-loading the core action. Nothing extraneous.

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 tool with no annotations, no output schema, and an interactive simulation purpose, the description is incomplete. It doesn't say what to expect after calling (e.g., an interview session starts, questions are generated, results are stored), nor does it address state management or follow-up steps like retrieving a report. An agent would need to guess about the tool's lifecycle.

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

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

Schema description coverage is 100%, so both parameters (job_id and interview_type with its enum) are fully documented in the schema. The description adds no parameter details beyond stating 'for a specific job,' so it adds little value. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific verb+resource: 'Conduct an AI-powered mock interview for a specific job.' This distinguishes it from the related generate_interview_questions and get_mock_interview_report siblings, making the purpose clear. However, it doesn't explicitly name or differentiate itself against those siblings within the 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 offers no guidance on when to use this tool versus alternatives like generate_interview_questions or get_mock_interview_report. It implies a simulation context but provides no explicit when-to-use or when-not-to-use conditions.

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

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

No annotations are provided, so the description carries full burden for behavioral disclosure. 'Post' implies a write operation, but there is no information about permissions, moderation, side effects, or what happens to the data afterward.

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 single sentence is front-loaded with the core action and wastes no words. It could be slightly more informative without losing conciseness, but it is well-structured for a simple tool.

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

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

The tool is simple with only two parameters and full schema coverage, and no output schema exists. However, the description omits that the tool can be used to reply to comments (via parent_id) and provides no behavioral context, leaving some gaps for an agent.

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

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

Schema description coverage is 100%, so both parameters are already fully documented in the schema. The description adds no parameter-level meaning beyond what is already provided, which meets the baseline for high 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 states a specific verb ('post') and resource ('comment') with a clear scope ('in the community'). It does not, however, distinguish this from sibling tools like update_comment or delete_comment, nor does it mention that it can post replies.

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, nor are there any prerequisites or exclusions. The implied usage is simply to add a comment, but the description provides no explicit context or comparison to siblings.

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

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

No annotations are provided, so the description carries full burden. It does disclose the key trait that the action is permanent and affects ALL schedules, which is meaningful. However, it omits confirmability, reversibility, auth requirements, and any return/error behavior for a mass-destructive 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, front-loaded with the action and scope, followed by a caution. No filler.

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

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

For a bulk destructive tool with no annotations and no output schema, the description covers the fundamental facts (permanent, deletes all) but lacks safety framing such as confirmation expectations or permission requirements. Adequate but thin given the destructive nature.

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 nothing to document; baseline 4 applies. The description correctly implies no filtering or scoping arguments.

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 ('delete') and resource ('ALL scheduled job discovery cron jobs') with an explicit 'ALL' scope. It is distinguishable from the sibling 'delete_schedule' (singular) by the 'ALL' qualifier, 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?

Provides only 'Use with caution' as guidance, with no when-to-use condition, no mention of when to prefer the singular 'delete_schedule', and no prerequisites. The agent must infer everything about routing.

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

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

With no annotations provided, the description carries the full burden and does disclose the key behavioral consequence: removal from the networking pool. However, it does not state whether deletion is reversible, whether confirmation is required, what happens to existing coffee chat connections or messages, or what the response returns, so significant behavioral gaps remain.

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

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

A single efficient sentence with the core action front-loaded. It is appropriately sized for a simple delete tool, though it stops just short of adding the risk/confirmation context that would make it fully useful.

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 zero-parameter tool with no annotations and no output schema, the description is minimal but on-topic. It omits reversibility, confirmation behavior, side effects on related coffee chat data, and error/absence handling, so it is only adequately complete.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify and no schema gap to compensate for. This meets the baseline of 4 for a zero-parameter tool.

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 (Delete) and resource (the user's coffee chat profile), and adds the consequence that the user is removed from the networking pool. It is clearly distinguishable from siblings like update_coffee_profile or get_my_coffee_profile.

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 a destructive removal from the networking pool but gives no explicit when-to-use or when-not-to-use guidance, no alternatives such as deactivating versus deleting, and no prerequisites. Usage is only implied by the verb.

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

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

No annotations are provided, so the description carries the full burden and fails to disclose whether deletion is permanent, requires ownership/permission, cascades to replies, or is reversible. 'Delete' signals a mutation but nothing about its consequences.

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 short, front-loaded sentence with zero waste. It is appropriately sized, though the terseness borders on under-specification rather than genuine conciseness.

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

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

For a 1-parameter mutation with no annotations and no output schema, an agent still needs to know effects and permissions. The description is complete only about the target of deletion, not the operation's behavior or result.

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 there is a single required comment_id already documented in the schema. The description adds no format, source, or origin detail, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Delete a comment'), which is unambiguous on its own. However, it does nothing to distinguish itself from the sibling mutations create_comment and update_comment, so the agent gains no differentiation beyond the 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?

No guidance on when to use this versus update_comment (e.g., soft-delete vs. edit) or what preconditions must hold. The agent must infer the use case entirely from the name.

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

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

With no annotations provided, the description carries the full behavioral burden, yet it only says 'Delete'. It does not disclose that the operation is destructive/irreversible, whether deletion cascades, what permissions are required, or what the caller gets back. For a destructive tool this is a substantial gap.

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

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

A single short sentence with no filler, and the verb-resource pairing is front-loaded. It is arguably too terse for a destructive operation, but it is not padded or wasteful.

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?

A destructive, no-annotation, no-output-schema tool with two required parameters deserves at least a note on irreversibility or side effects; the description supplies none. What exists is accurate but insufficient for an agent to call this safely.

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

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

Schema description coverage is 100%, so both document_id and type are documented in the schema, including the cv/cover-letter enum. The description's parenthetical restates that enum rather than adding format, ID-source, or validation detail, so it does not exceed the baseline.

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

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

States a specific verb (Delete) and resource (document), and scopes it to the two document kinds, CV or cover letter. It is distinguishable from the many other delete_* siblings (delete_job, delete_comment, delete_notification) by resource, but it does not explicitly differentiate itself from get_documents/get_document/rename_document in the same document family.

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 indication of when to use this versus siblings like rename_document or get_document, no prerequisites such as ownership, and no mention of whether the deletion is reversible or confirmable. The agent must infer everything about usage 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?

With no annotations provided, the description carries the full behavioral burden for a destructive operation, and it does not say whether the deletion is permanent or reversible, whether confirmation is required, or what happens to associated notes, evaluations, and cover letters tied to the job. It discloses none of the side effects an agent needs to warn the user about.

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, purpose front-loaded before the usage clause, with no filler. It is tight, though the second sentence is generic enough that it borders on restating the obvious.

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, unannotated, single-parameter tool with no output schema, the description omits the information that matters most: irreversibility, what related data is affected, and confirmation behavior. The basic "what" is covered but the risk profile is not.

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

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

Schema description coverage is 100% and the single job_id parameter is documented in the schema, so the description need not repeat it. It adds no syntax, format, or identifier-sourcing guidance beyond the schema, which is the baseline-3 case.

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

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

States a specific verb and resource ("Delete a saved job") and the qualifier "saved" distinguishes it from neighboring deletion tools like delete_schedule, delete_document, and delete_job_note. However, it does not explicitly contrast itself with the closest sibling delete_job_note or bulk deletion paths, so it stops short of full sibling differentiation.

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

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

"Use this when the user wants to remove a job from their list" gives an implied trigger condition, which is more than nothing. But it offers no exclusions or alternatives — e.g. when to prefer delete_job_note, delete_all_schedules, or bulk operations — leaving the agent to infer 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?

No annotations are provided, so the description carries the full behavioral burden, but it only says 'delete.' It does not disclose whether deletion is permanent or reversible, whether it requires ownership or special permissions, or what happens to the parent job record, which are the traits an agent needs before invoking a destructive 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?

It is a single, front-loaded sentence with zero padding, which is efficient. The brevity borders on under-specification for a destructive tool, but nothing in the text is wasted or redundant.

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

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

For a destructive tool with no annotations and no output schema, the description is too thin: it omits irreversibility, permission requirements, and error behavior. The input schema fully covers the two parameters, but the behavioral side is left entirely undisclosed.

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

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

Schema description coverage is 100%, with both job_id and note_id clearly documented, so the schema does the heavy lifting. The description adds no meaning about identifier format, sourcing, or relationships beyond what the schema already provides, making the baseline 3 appropriate.

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

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

The description states a specific verb (delete) and resource (a note from a job application), so an agent knows exactly what the tool operates on. It does not, however, distinguish itself from the closely related add_job_note and update_job_note siblings beyond the verb itself.

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

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

There is no guidance on when to use this tool versus add_job_note, update_job_note, or delete_job, nor any precondition such as ownership of the note. Usage must be inferred entirely from the name and one-line 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?

No annotations are provided, so the description carries the full behavioral burden. It does not state that the operation is irreversible/destructive, whether the notification must belong to the caller, or what happens on an invalid ID. Only the implicit mutation nature of 'Delete' is conveyed.

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 short sentence with no filler and the action front-loaded. It is appropriately sized for a trivial single-parameter tool, though it is so terse that it omits any useful clause.

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

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

For a one-parameter tool with full schema coverage and no output schema, the description covers the essential mechanics. It falls short only on the destructive-action warning that a delete tool with no annotations arguably warrants.

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

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

There is a single parameter with 100% schema description coverage ('The notification ID to delete'), so the schema already documents it fully. The description adds no format, ownership, or sourcing detail beyond the schema, making the baseline 3 correct.

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

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

States a specific verb ('Delete') and resource ('a notification'), so the operation is unambiguous. However, it offers no differentiation from closely related siblings such as mark_notification_read, delete_all_schedules-style bulk deletes, or get_notifications, leaving the agent to infer boundaries.

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 delete versus mark as read (mark_notification_read / mark_notifications_read), nor any prerequisites or exclusions. Usage is only implied by 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?

With no annotations, the description carries the full behavioral burden, and it does disclose the key trait that the deletion is permanent/irreversible. It says nothing about permissions required, behavior on an unknown ID, or whether a running job is stopped, which leaves meaningful gaps for a destructive 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 zero padding, and the permanence warning plus the ID-sourcing hint are both 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 single-parameter destructive tool with no annotations or output schema, the description covers the essential facts: what is deleted, that it is permanent, and where to get the ID. Only edge-case behavior (invalid ID, running job) is unaddressed.

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

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

Schema coverage is 100% with a single documented parameter, so the schema already defines 'id' fully. The description reinforces that the ID comes from list_schedules, adding mild value but no syntax or format detail beyond the schema.

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

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

States a specific verb (delete) and resource (scheduled job discovery cron job), plus the identifier used to target it. An agent can distinguish it from delete_all_schedules and toggle_schedule 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 points the agent to list_schedules to obtain valid IDs, which is a genuine usage prerequisite. It does not state when to prefer this over delete_all_schedules or what happens if the schedule is currently active, so it stops short of full when/when-not guidance.

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

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

With no annotations, the description carries the full burden, and it does disclose real side effects: it scrapes live sites, enriches with ATS detection, expands career pages, stores results locally, and opens the web app. It stops short of stating auth/login requirements or that it is slow/network-dependent beyond the career_discovery note in the schema.

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

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

Three sentences, front-loaded with purpose and the primary-tool routing statement. The final sentence listing the pipeline is a bit dense but each clause conveys a distinct behavior, so little is wasted.

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

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

No output schema and no annotations, so the description must convey behavior, which it does for the scraping/enrichment/store/open pipeline. What is missing for a tool that hits external job sites is any note on runtime, failure modes, or prerequisites, though the schema's career_discovery note partially covers timeouts.

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

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

Schema description coverage is 100% and the schema itself is unusually rich (page limit, source defaults, timeout rationale for career_discovery, plus an imperative to ask about page count). The description adds no parameter-level detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Find jobs ... by scraping live listings from job sites') and names example sources (LinkedIn, SEEK, Jora). It is clearly distinguishable from siblings like get_jobs (retrieval of stored jobs) and schedule_jobs (scheduling recurring runs).

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 'This is the primary tool for job searching — always use this when the user wants to find, search, or look for jobs,' giving clear usage context. It does not, however, name or exclude the nearby alternatives (schedule_jobs for recurring discovery, get_jobs for already-stored results), which would complete the routing picture.

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

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

No annotations are provided, so the description carries the full burden. It discloses that an AI performs the evaluation and that a score plus analysis is returned, but says nothing about whether the result is persisted (get_job_evaluation implies it may be), latency/cost of an AI call, 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?

Two tight sentences with the action front-loaded and the return value last. No wasted words, though it is quite terse given the tool's complexity.

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

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

With no output schema, no annotations, and five parameters, the description should do more. The one-line note about the fit score partially covers the return value, but persistence behavior, profile prerequisites, and the job_id-vs-manual-input relationship are left unexplained.

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

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

Schema description coverage is 100% across all five parameters, so the baseline is 3. The description adds only the notion that evaluation works against the user's profile/resume, without clarifying how job_id vs. job_title/description inputs interact (e.g., whether job_id makes the other fields optional).

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: 'evaluate how well the user's profile/resume matches a specific job', plus the return shape (fit score + analysis). However, it never distinguishes itself from the closely-named sibling get_job_evaluation, leaving the agent to guess which one retrieves vs. generates an evaluation.

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 — evaluate a job against the user's profile — but there is no explicit when-to-use, no prerequisite (e.g., an existing profile), and no mention of alternatives like get_job_evaluation or save_job. The agent must infer the routing.

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

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

With no annotations, the description carries the full burden, and it does disclose the shape of the return (label, type, options, CSS selector for filling) and the scoping constraint that only visible fields are returned. It is implicitly a read-only operation with no mutation risk, but it does not describe behavior when the page has no forms or is not yet loaded.

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, each earning its place: purpose, return shape, prerequisite. The prerequisite is placed last as a call-to-action, and nothing is redundant.

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

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

There is no output schema, so the description correctly compensates by naming the returned fields, and it supplies the required setup step. It falls just short of complete by not covering the empty-page or unopened-page failure modes an agent might encounter.

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 document and the baseline of 4 applies. No semantic gap exists to compensate for.

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 ('Extract') and resource ('all visible form fields from the current page'), with the scope qualifier 'visible' and 'current page' narrowing it precisely. The verb is clearly distinct from the mutation siblings fill_form_field and select_form_option, so an agent can pick it 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?

Gives an explicit prerequisite: 'Call open_application_page first,' which establishes the ordering relative to a named sibling. It does not state exclusions or alternatives (e.g., when to prefer fill_form_field next), so it stops short of full when/when-not guidance.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: not what happens if the selector matches nothing, whether existing field content is overwritten or appended, whether input/change events are dispatched, or whether a live browser session/page must already be open. For a page-mutating automation tool this leaves significant gaps.

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

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

Two short sentences, zero filler, with the core action front-loaded and the prerequisite trailing. Every clause earns its place.

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

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

With no annotations and no output schema, the description is the only source of behavioral context, and it omits failure behavior, event semantics, and session prerequisites. It is adequate for a two-parameter tool whose schema is complete, but thin for a browser-mutating operation.

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

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

Schema coverage is 100% so the baseline is 3, but the description adds real meaning by specifying that the selector should originate from extract_form_fields, which is workflow information the schema's 'CSS selector for the field' does not convey. The value parameter remains fully schema-documented only.

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 (Fill) and resource (a single text input or textarea field), and scopes it to exactly one field on the current page. That scope distinguishes it from broader form tools, though it never names the closest sibling (select_form_option) for non-text form controls.

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 an explicit prerequisite/source for its input: 'Use the selector from extract_form_fields,' which tells the agent it must run extraction first. It stops short of stating when-not to use it (e.g., dropdowns/checkboxes belong to select_form_option), so no explicit 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?

No annotations are provided, so the description carries the full behavioral burden. It implies a safe read/search operation but says nothing about permissions, result shape, pagination, or ranking of 'available' contacts — a significant gap given zero annotation coverage.

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 front-loaded sentences with no padding; the purpose comes first and the use-case follows. The second sentence is mildly redundant with the first ('networking' / 'connect') but still earns its place as usage guidance.

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 discovery tool with no output schema and no annotations, the description is adequate but thin: it never explains what a returned 'contact' includes or how results are ordered/limited. It is minimally viable rather than complete.

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

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

Schema description coverage is 100%, so all four parameters (limit, search, industry, help_topics) are already documented in the schema. The description only loosely echoes the industry use case and adds no syntax or default detail beyond it, so baseline 3 applies.

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

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

States a specific verb and resource: 'Find people available for coffee chats / networking.' An agent can tell it is a people-discovery tool, distinct from siblings like send_coffee_chat_request or get_coffee_chat_requests, though it doesn't name those siblings 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?

Provides clear trigger context: use when the user wants to connect with professionals, find mentors, or network in a specific industry. It does not state exclusions or point to alternative tools for related needs (e.g., messaging an existing contact), so it falls short of a 5.

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

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

No annotations are provided, so the description carries the full burden. It reveals that a document is created and saved, which is useful, but omits critical behavior: whether it overwrites existing documents, what permissions are needed, whether generation can fail, and what the return value contains. For a mutation tool with zero annotation coverage, this is a significant gap.

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

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

A single, well-formed sentence with no wasted words. It front-loads the generation action and the storage outcome.

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 four optional parameters, no annotations, and no output schema, the description is too thin. It does not clarify which parameters are required (none are, per schema), how tailoring parameters affect the output, or what the stored document looks like. An agent would need to guess or inspect the schema closely.

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

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

Schema description coverage is 100%, so all four parameters (name, template, job_title, job_description) are already documented in the schema. The description adds no additional parameter meaning, so the baseline of 3 applies.

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

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

The description states a specific double verb+resource: generate a CV and store it in the user's documents. It is clearly distinguishable from the sibling generate_cv (generation only) by emphasizing persistence. It lacks detail on what the CV contains or where exactly it is saved, but the purpose 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 generate_cv, or when persistence is appropriate. An agent cannot infer whether to call this or the sibling based on the description alone.

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

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

No annotations are provided, so the description carries the full burden. 'Use AI to generate' hints that output is model-generated and personalized, but nothing says whether anything is persisted, whether it consumes quota/credits, how long it takes, or how many suggestions come back.

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

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

A single tight sentence with the key qualifiers (AI, personalized, chat introduction messages) front-loaded. Nothing wasted, though it is arguably terse given the missing behavioral 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 one-parameter generation tool this is minimally adequate, but with no output schema the agent has no idea what the return value looks like (a list of message texts? a single draft?) and no annotations to fall back on. The generation/non-persistence semantics are left unspecified.

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

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

Only one parameter and schema description coverage is 100%, so the schema already explains receiver_id. The phrase 'based on a person's profile' adds a small amount of meaning about how the ID is used, but no format or lookup guidance beyond the schema.

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

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

States a specific verb ('generate') and resource ('coffee chat introduction messages') with the AI and personalization angle made explicit. It is distinguishable from send_coffee_chat_request/send_coffee_chat_message by the word 'suggestions', but the description never names or contrasts those 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?

No when-to-use guidance, no prerequisites, and no mention of how this fits with send_coffee_chat_request, which is the obvious next step after receiving suggestions. The agent must infer the workflow entirely.

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

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

No annotations are provided, so the description carries the full burden. It does disclose that this is an AI/LLM generation (non-deterministic, potentially slow), but says nothing about persistence, cost/quotas, auth requirements, or whether the result is returned or saved. That silence is a real gap for a generation tool.

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

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

A single front-loaded sentence with no filler; the purpose is immediately visible. It is efficient, though it could have spent one more clause on behavior without becoming bloated.

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 no annotations, and the description never states what comes back (generated text vs. a stored document reference) or how the optional job_id changes that behavior. For a 5-parameter generation tool with zero structured behavioral coverage, this leaves the agent under-informed.

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

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

Schema description coverage is 100%, so every parameter is already documented there, establishing the baseline of 3. The description adds only one piece of context beyond the schema — that output is tailored using the user's profile/resume — which is profile-state context rather than parameter 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?

States a specific verb (generate) and resource (tailored cover letter) scoped to a specific job and grounded in the user's profile/resume. The generate-vs-get distinction against the sibling get_job_cover_letter is inferable but never named 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?

Implies when to use it (when the user wants a new cover letter for a job) but gives no explicit conditions, prerequisites, or alternatives. Nothing says whether the user must already have a profile/resume populated, nor when to prefer generate_cv instead.

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

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

No annotations are provided, so the description carries the full burden. It discloses the output format (PDF) and the input source (user profile), but says nothing about whether the generated file is stored or returned, whether profile data must exist first, or any permissions required.

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

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

A single efficient sentence with no filler and the core action front-loaded. It is arguably under-specified for a tool with three tailoring parameters, but there is no wasted language.

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, no annotations, and three optional parameters, the description should explain what is returned (a file, a URL, a document record) and how it relates to generate_and_store_cv. Neither is addressed, leaving key gaps for an agent.

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 template, job_title, and job_description are already documented. The description adds no syntax or behavioral detail about how tailoring works, so the baseline 3 applies.

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

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

States a specific verb and resource ('Generate a CV/resume as PDF using AI') with the input basis ('based on the user's profile'). However, it fails to distinguish itself from the sibling generate_and_store_cv, leaving the agent unsure which to pick.

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

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

No when-to-use guidance, no prerequisites, and no mention of the near-identical sibling generate_and_store_cv. The agent must infer from the name alone that this one does not persist the result.

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

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

No annotations are provided, so the description carries the full behavioral burden. It says the tool uses AI, but it does not disclose whether questions are stored, whether the call is read-only, latency or cost implications, or what the output looks like.

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 repetition or filler. The core action and the main option are 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 generation tool with no output schema and no annotations, the description is minimally adequate: it explains what is generated and the type option, but it does not describe the return shape, quantity of questions, or any behavioral caveats.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters and the interview_type enum. The description reinforces the choice between technical and behavioral but adds no syntax, defaults, or constraints beyond the schema.

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

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

The description states a clear verb and resource: generate practice interview questions for a specific job, with an option for technical or behavioral. It does not distinguish the tool from the sibling conduct_mock_interview, which is a related interview-preparation 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?

It implies usage for interview preparation and tells the agent to choose technical or behavioral, but it gives no explicit when-to-use guidance, prerequisites, or alternatives such as conduct_mock_interview.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, yet says nothing about ordering, pagination, read/unread side effects, or required permissions beyond what 'Get' implies. A read-only getter is a modest case, but the disclosure is still thin.

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 short sentence that is front-loaded with the verb and resource and contains no filler. It is efficient, though correspondingly terse.

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, no annotations, and no mention of return shape, message ordering, or pagination, the definition is too sparse for an agent to know what the response will look like or how to handle large conversations.

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

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

There is a single parameter (request_id) with 100% schema description coverage, so the schema already fully documents it. The description adds no format, sourcing, or example detail beyond the schema, which is the baseline-3 case.

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

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

The description states a specific verb ('Get') and resource ('messages in a coffee chat conversation'), which cleanly separates it from the write sibling send_coffee_chat_message. It does not, however, explicitly distinguish itself from get_coffee_chat_requests, leaving the agent to infer the conversation-vs-message-list distinction from the names 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 statement of when to use this tool versus alternatives such as get_coffee_chat_requests (list conversations) or respond_coffee_chat. Any usage guidance is left entirely to inference 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?

No annotations are provided, so the description carries the full behavioral burden, yet it discloses nothing beyond the basic read intent. It omits whether results are paginated, sorted, filtered by auth scope, or what the response contains.

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 redundancy. It is efficient, though it is arguably too terse to carry the missing usage and behavioral 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 single-parameter read tool with no output schema, the description is minimally sufficient. However, with no annotations and multiple coffee-chat siblings, it should say more about scope and how it differs from related read 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 100%, so the direction parameter, its enum, and default are already fully documented in the schema. The description merely restates the same 'sent or received' choice, adding no syntax or behavioral detail beyond 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 specific verb (Get) and resource (the user's coffee chat requests) and clarifies the scope with 'either sent or received'. It is clear on its own, but it does not distinguish itself from related siblings such as get_coffee_chat_messages, get_coffee_chat_stats, or generate_coffee_chat_suggestions.

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 retrieval framing, but there is no explicit when-to-use guidance and no mention of alternatives. With several coffee-chat siblings, an agent gets no help deciding between this tool, get_coffee_chat_messages, and get_coffee_chat_stats.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not state that this is a read-only operation, whether the counts are scoped to the current user or a time window, or anything about aggregation behavior — significant gaps for a stats tool with zero annotation coverage.

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

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

A single compact sentence with the resource front-loaded and the metric list in a parenthetical. No wasted text, though the trailing 'etc.' leaves the return shape vague rather than tight.

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 (no params, no annotations), but with no output schema the description is the only place the return shape could be defined, and it only gestures at it with 'etc.' without stating the time range or whether counts are user-scoped. Adequate but leaves real 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 tool takes no parameters and schema coverage is 100%, so there is nothing for the description to compensate for. Baseline 4 applies.

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

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

States a specific verb+resource ('Get coffee chat statistics') and enumerates the metrics returned (requests sent, received, accepted), which lets an agent distinguish it from mutation siblings like send_coffee_chat_request. It does not, however, differentiate itself from other stats readers such as get_dashboard_stats or get_scraping_stats.

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 name and metric list: an agent can infer this is the read-only aggregate view of coffee chat activity. There is no explicit statement of when to prefer this over get_coffee_chat_requests (raw list) or the other *stats tools, and no preconditions 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?

No annotations are provided, so the description carries full behavioral burden. "View" implies read-only access, but the description does not state permission requirements, pagination behavior, reply nesting, or error behavior for missing comments.

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 redundant or wasted wording. It is appropriately concise for a simple read tool.

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

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

For a one-parameter read tool with full schema coverage, the description states the return concept (comment and replies) adequately. However, it omits usage context, sibling differentiation, and behavioral details such as read-only safety or pagination, leaving it only minimally complete.

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

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

Schema description coverage is 100% for the single comment_id parameter, and the schema already explains it as the comment ID to view the thread for. The description adds no parameter meaning beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb ("View") and resource ("a comment and its replies"), making the core purpose clear. However, it does not distinguish this tool from sibling comment-related tools such as get_community_comments or create_comment.

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

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

Provides no when-to-use guidance, prerequisites, or alternative-tool comparisons. An agent must infer usage entirely from the name and schema.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it only says 'browse'. It doesn't disclose that this is a read-only paginated listing, the ordering of results, authentication requirements, or that page/limit control paging.

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 short sentence with no padding and the verb front-loaded. It is efficient, though it errs toward under-specification rather than excess.

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

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

With no annotations and no output schema, the description must convey the return shape and safety profile, and it does neither. For a listing tool whose parameters imply pagination, an agent cannot tell what a page contains or in what order.

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

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

Schema description coverage is 100% with only two optional, self-explanatory parameters (page, limit), so the schema already does the work. The description adds nothing about paging behavior, which would have been the useful addition.

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?

It states a verb ('browse') and resources ('community posts and comments'), but 'browse' is vague about what is actually returned, and the tool name promises only comments while the description adds 'posts'. No sibling differentiation against get_comment_thread, get_coffee_chat_messages, or the other comment-related 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?

No when-to-use guidance, no exclusions, and no pointer to alternatives such as get_comment_thread for a specific thread. In a sibling set crowded with comment and chat tools, the agent gets no routing signal.

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

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

No annotations are provided, so the description carries the full burden. 'Get' plus the enumerated read-only content makes the non-mutating nature clear, but it says nothing about data scope (whose data), freshness/caching, or permissions. Adequate for a pure read, but thin given zero annotation coverage.

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

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

Two sentences, front-loaded with the resource and followed by the use case. Every clause earns its place — the enumeration is what makes the aggregate verifiable and the second sentence is a genuine routing hint.

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

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

With no output schema and no annotations, the description compensates by enumerating the return categories, which is most of what an agent needs to decide whether to call it. Minor gaps remain on data scope and freshness, but nothing essential is missing for a zero-arg read 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 and the schema has no properties, so there is nothing to disambiguate; the baseline of 4 applies.

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

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

States a specific verb and resource ('overview of the user's job search progress') and enumerates the content categories returned: job counts by status, scraping metrics, document counts, feature usage. It is clearly an aggregate/summary tool, which sets it apart contextually from narrower siblings like get_scraping_stats, but it never names those siblings to make the distinction explicit.

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

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

Gives a concrete usage scenario — 'Great for answering how is my job search going?' — which tells the agent when a summary is the right call. It stops short of stating when to use a narrower alternative (e.g. get_scraping_stats) or any exclusions, so it lacks the explicit routing of a 5.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Get details' implies a read, but it discloses nothing about permissions/ownership scoping, whether it errors or returns empty for missing IDs, or any rate limits. For a zero-annotation tool this is a substantial gap.

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

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

One short sentence with the resource and lookup key front-loaded and zero padding. It is efficient, though its brevity reflects under-specification captured in other dimensions.

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 single-parameter read tool, so a minimal description is defensible, and no output schema exists to omit. Still, with no annotations and no return-shape hint, the agent lacks any signal about what 'details' contains or how failures surface.

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

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

Schema description coverage is 100%, so the single document_id parameter is already documented in the schema. The description's 'by ID' phrasing adds no format, source, or constraint details beyond that baseline.

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

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

States a specific verb (Get) and resource (details of a document) scoped by ID, which is clear enough to act on. However, it gives no differentiation from the sibling get_documents (list) or the other document tools rename_document/delete_document, leaving the agent to infer the distinction 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 when-to-use guidance, no mention of the alternative get_documents for listing, and no prerequisites or error conditions (e.g., what happens for an unknown or unauthorized ID). The agent must infer usage entirely from the name.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only retrieval operation ("List") and scopes the result to the user's own documents, which is minimally sufficient, but says nothing about pagination, ordering, empty states, or auth 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?

One sentence, front-loaded with verb and resource, no filler. The parenthetical expands the resource without 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?

Adequate for a simple single-optional-parameter list tool. However, with no annotations, no output schema, and no guidance on the singular sibling get_document, the definition stops at minimum viable.

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

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

Schema coverage is 100%, so the schema already documents the single 'type' filter with its enum and default. The description adds no syntax or semantics beyond implying documents are CVs and cover letters, so baseline 3 applies.

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

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

States a specific verb (List) and resource (user documents), with a parenthetical clarifier of what 'documents' means (CVs and cover letters). Siblings include get_document (singular) and get_profile, so the resource is reasonably distinguishable, though it does not explicitly contrast with get_document.

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

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

No when-to-use or when-not-to-use guidance. It doesn't mention that get_document should be used for a single document or that get_document is the singular counterpart. Nothing routes the agent between this tool and its closest siblings.

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

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

No annotations are provided, so the description carries the full burden. 'Get' implies a safe read, but the description says nothing about what happens when no cover letter has been saved for the job (empty result, error, or null), nor any permission or storage-location 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 short sentence with the scope qualifier ('for a specific job') front-loaded after the core verb-resource phrase. No filler, though it is arguably too terse to be maximally useful.

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 itself is simple (one required param, no output schema, no nested objects), so little is strictly required. However, for a 'get saved X' tool the missing edge-case behavior (no saved letter) is the one piece of context an agent would actually need.

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

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

Only one parameter (job_id) and schema description coverage is 100%, so the schema already documents it fully. The description adds nothing beyond what the schema states, which is the expected baseline for a fully-covered single parameter.

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 (get) plus resource (saved cover letter) scoped to a specific job. The word 'saved' implicitly separates this from the sibling generate_cover_letter, but the distinction is never made explicit.

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

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

No guidance on when to use this versus generate_cover_letter, nor any mention of prerequisites (e.g., that a cover letter must already have been generated and stored). The agent must infer the retrieval-vs-generation distinction from 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?

With no annotations, the description carries the full burden. It does disclose the shape of the return payload (description, skills, notes, evaluation data), which is genuinely useful since no output schema exists, but it says nothing about permissions, whether the ID must belong to the caller, or behavior on a missing/invalid ID.

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 sentence, front-loaded with the action and scope, with the enumerated return fields appended compactly. 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 read-only, single-parameter lookup with no output schema, the description covers the purpose, the key, and the notable contents of the result. It falls short only on error/permission behavior, which for this tool class 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 description coverage is 100% for the single job_id parameter, so the schema already documents it. The description only restates 'by ID' and adds no format, source, or validity guidance beyond the schema. Baseline 3 applies.

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

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

States a specific verb (get) and resource (job details) scoped to a single job by ID, which cleanly separates it from the bulk list tool get_jobs and the narrower get_job_evaluation. It does not explicitly name a sibling, but the scope 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?

Usage is implied: fetch full details for one known job ID. There is no explicit when-to-use guidance, no statement of when to prefer get_jobs, get_job_evaluation, or get_job_cover_letter instead, and no prerequisites mentioned.

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

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

No annotations are provided, so the description carries the full behavioral burden and does not meet it. It says nothing about what happens when no evaluation has been saved (error vs. empty), whether the evaluation is user-scoped, or any auth/rate-limit considerations for a retrieval tool.

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

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

One sentence, front-loaded with the verb and resource, and no filler. Nothing could be trimmed without losing the scope qualifier.

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

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

For a single-parameter read tool with no output schema, the description is minimally adequate: the agent knows what it fetches. It leaves open the return shape (what fields an evaluation has) and the no-evaluation-exists case, which matters given zero 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 coverage is 100% and there is only one parameter, whose schema description ('The job ID to get evaluation for') matches the description's phrasing. The description adds no format, ownership, or sourcing detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (Get) and resource (the saved CV/resume evaluation) scoped to a job. The word 'saved' implicitly distinguishes it from generation-side siblings like evaluate_job_fit or generate_and_store_cv, but it never names that sibling explicitly.

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

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

Usage is only implied: 'saved' suggests an evaluation must already exist, and 'for a specific job' implies the job_id must reference a job the user owns. There is no explicit when-to-use, prerequisite, or routing versus evaluate_job_fit.

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

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

No annotations are provided, so the description carries the full burden, yet it discloses little beyond the obvious read nature. It says nothing about pagination behavior (the limit default is only in the schema), auth requirements, or what the returned records contain.

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

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

Two short sentences, front-loaded with the core purpose and with zero filler. The second sentence is partly a restatement of the first, which keeps it just short of ideal.

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, fully-described, non-destructive list tool with no output schema, the description covers what an agent needs to invoke it. Return-shape and pagination details are the only real omissions.

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 limit, search, status, and starred_only are already fully documented in the schema and enum. The description adds no extra meaning, making the baseline 3 correct.

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

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

States a specific verb (Get) and resource (user's saved jobs) plus the salient attribute (current status). It implicitly distinguishes the saved-jobs collection from siblings like discover_jobs and get_job_details, though it never names them.

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

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

"Use this to check job application status, list all jobs, or find specific jobs" gives usable contexts, but it offers no when-not guidance and doesn't route the agent to alternatives such as get_job_details for a single job or discover_jobs for new jobs.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the summary includes but does not explicitly say whether the operation is read-only, safe, or requires any permissions. 'Show' implies a read, but the absence of explicit safety or side-effect information is a gap for a zero-annotation tool.

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

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

The description is a single, front-loaded sentence that conveys the essential purpose and contents without any wasted words. It is appropriately sized for a simple tool.

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

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

Given the low complexity (no parameters, no output schema), the description is adequate but not complete. It explains what the report contains, but it omits usage context (when to call it) and explicit safety information. For a read-only tool with no annotations, more guidance would be beneficial.

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, and the schema is empty. Per the rubric, with 0 parameters the baseline is 4. The description correctly does not need to explain parameter semantics, and it adds no misleading parameter information.

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 specifies a clear verb ('Show') and resource ('summary of the most recent discovery run'), and names the summary contents. It does not explicitly differentiate itself from siblings like discover_jobs or get_jobs, though the scope ('latest discovery run') implies the difference. An agent can infer the purpose without opening the schema.

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

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

The description gives no indication of when to use this tool versus alternatives. There is no mention of prerequisites, timing, or scenarios (e.g., after a discovery run). The agent is left to infer usage from the name and description alone.

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

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

No annotations are supplied, so the description carries the full behavioral burden. 'Get' implies a read, but the description never states whether the call is safe/non-mutating, whether it fails when no interview exists, or what the report contains. For a zero-annotation tool this is a real gap.

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

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

A single tight sentence with the resource and scope front-loaded and no wasted words. It is efficient, though its brevity is partly under-specification rather than pure concision.

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 one parameter, full schema coverage, and no output schema, the structural fields cover most of the calling surface. Still missing is any statement of the prerequisite interview or the report's contents, which matters for a retrievable artifact keyed on a job.

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

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

Schema coverage is 100% with a single 'job_id' parameter already documented in the schema. The description adds no format, sourcing, or lookup semantics beyond the parameter name, so the baseline 3 applies.

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

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

The description states a specific verb ('Get') and resource ('mock interview report') scoped to a job, which is unambiguous on its own. However, it does nothing to distinguish itself from the closely related sibling 'conduct_mock_interview', so an agent must infer that this retrieves rather than runs an interview.

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

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

There is no guidance on when to call this tool versus alternatives, and no mention of the obvious prerequisite that a mock interview must already have been conducted. The agent must guess whether a report exists and what happens if none does.

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

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

No annotations are provided, so the description carries the full burden. 'Get' implies a read-only lookup, but nothing is said about authentication requirements, what happens if no profile exists, or what the response contains.

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. It is appropriately sized for a zero-argument tool, though it is almost too terse to be maximally useful.

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 zero-param read tool with no output schema, the description covers the minimum. However, it never hints at what a 'coffee chat profile' includes or how it differs from the main profile, leaving a gap an agent would want filled.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify; baseline for a no-parameter tool is 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?

States a specific verb ('Get') and resource ('the user's own coffee chat profile'), which distinguishes it from the general get_profile and the mutating update_coffee_profile. It is clear what the tool retrieves, though it does not explicitly name 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?

No indication of when to call this versus get_profile or get_coffee_chat_stats, and no prerequisites or context. The agent must infer usage entirely from the name.

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

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

No annotations are provided, so the description carries the full burden. It does not disclose whether read and unread notifications are both returned, ordering, pagination behavior beyond the limit parameter, or any auth requirement — a meaningful gap for a no-annotation read tool.

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

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

Two short sentences, front-loaded with the action and followed by the triggering condition. No filler and nothing to trim.

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, no-annotation, no-output-schema read tool with one optional param, the description is adequate but leaves the read/unread scope ambiguous — especially relevant given the sibling get_unread_notification_count exists and implies this tool may return something broader.

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 optional parameter has a full schema description including its default (10), so the schema does the heavy lifting. The description adds no parameter meaning beyond that, which is the expected baseline when schema coverage is 100%.

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

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

States a clear verb+resource (get notifications) and the surrounding sentence frames the resource as the user's own notifications. It does not explicitly differentiate from close siblings like get_unread_notification_count or mark_notifications_read, so it stops short of a 5.

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

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

Gives a trigger condition ('user asks about updates, alerts, or what's new'), which is useful usage context. However, it names no alternative and gives no exclusions, so an agent cannot tell from this text why it should call this instead of get_unread_notification_count.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'View' weakly implies a read-only operation, but nothing is said about authentication requirements, pagination, result ordering, or what period the history covers, which matters for a billing-related read.

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

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

A single short sentence that is front-loaded and wastes no words. It is efficient, though the brevity is partly the result of under-specification rather than disciplined editing.

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, no-output-schema tool the description is minimally viable: purpose is clear and read-only intent is implied. But with no annotations to cover the safety and scoping profile, an agent gets no information about history range, ordering, or pagination.

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 adds no param meaning but none is needed.

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 (view) and resource (the user's payment history), which is distinct from neighbouring billing siblings like get_subscription_status and get_subscription_plans. It does not, however, explicitly differentiate itself from those siblings, so it stops short of a 5.

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

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

No guidance on when to call this versus get_subscription_status or get_subscription_plans, no stated prerequisites, and no indication of the time window or scope of history returned. The agent must infer usage entirely.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read operation via 'Get' but discloses nothing about authentication requirements, rate limits, data freshness, or what the analytics include. This is a significant gap for a tool with zero structured behavioral 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 wasted words. It is appropriately sized for a simple getter, though its sparseness borders on under-specification rather than true conciseness.

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

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

With no output schema and no annotations, the description should compensate by explaining at least the shape or content of the returned analytics. Instead it only restates the tool name, leaving the agent without enough context to understand the response or any behavioral constraints.

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

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

Schema description coverage is 100% and the single parameter (report_slug) is fully documented in the schema as the portfolio slug. The description adds no additional meaning beyond the schema, which is the expected baseline when the schema does the heavy lifting.

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

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

States a clear verb (Get) and resource (detailed analytics) scoped to a portfolio page, so the agent knows the general operation. However, it does not differentiate from sibling tools like get_portfolio_visits or get_public_portfolio, which overlap in domain and could cause selection 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 gives no guidance on when to use this tool versus alternatives, no prerequisites, and no conditions or exclusions. The agent is left to infer usage entirely from the name and siblings.

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

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

No annotations are supplied, so the description carries the full behavioral burden. 'Get the user's ...' implies the result is scoped to the authenticated caller, which is a useful hint, but nothing is said about authorization requirements, whether the portfolio must be public, or whether the count is all-time or windowed.

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 short sentence with no filler, and the resource is front-loaded. It is efficient, though not so information-dense that it earns top marks.

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

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

With no output schema and no annotations, the description should at least pin down what is returned and its scope. It does convey that the result is a visit count for the caller's portfolio, which is the essential fact, but leaves the metric's definition (time range, uniqueness, public vs. authenticated views) unstated.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify about inputs; the baseline for a parameterless tool applies.

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

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

The description states a specific verb ('Get') and resource ('portfolio visit count'), so an agent can immediately tell it retrieves a metric rather than a document or profile. It does not, however, distinguish itself from nearby siblings like get_portfolio_analytics or get_public_portfolio, leaving some ambiguity about which portfolio-metric tool to pick.

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

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

There is no statement of when to use this tool versus alternatives, no prerequisites, and no mention of related tools such as get_portfolio_analytics. The agent must infer the intended context entirely.

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

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

With no annotations provided, the description carries the full disclosure burden. 'Get' makes the read-only nature self-evident and 'the user's' implies an authenticated own-profile scope, but nothing is said about auth requirements, error behavior for incomplete profiles, or whether any data is redacted.

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

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

A single front-loaded sentence with no filler; the enumeration of returned fields is the most useful part and appears immediately. Nothing is wasted, though nothing is prioritized over anything else.

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-param read tool with no output schema and no annotations, the description does cover what comes back, which is the main thing an agent needs. It remains incomplete on sibling disambiguation and on the authenticated-scope assumption in a tool list crowded with other 'profile' 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 tool takes zero parameters, which is the baseline-4 case per the rubric. The schema is trivially complete and no parameter meaning is 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 ('Get') and resource ('the user's profile information') and enumerates the returned sections (skills, experience, education, projects). It does not distinguish itself from close siblings such as get_my_coffee_profile or get_public_portfolio, so an agent could pick the wrong profile 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?

No guidance on when to call this versus get_my_coffee_profile, get_public_portfolio, or the granular update_profile_* equivalents. The agent must infer from the name alone that this is the full own-profile read.

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

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

No annotations are provided, so the description carries the full burden. 'View' and 'public' imply a read-only operation on publicly accessible data, which is useful behavioral context, but the description does not confirm authentication requirements, error behavior, 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?

A single, front-loaded sentence with no filler. Every word earns its place, and the key action and input are 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 one-parameter read tool, the description covers the essential purpose and input. However, with no annotations and no output schema, it could be more complete by clarifying that no authentication is needed for public portfolios or by hinting at what portfolio data is returned.

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

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

Schema description coverage is 100%, so the single identifier parameter is already well documented. The description mirrors the schema's 'username or slug' detail but adds no further meaning or syntax guidance beyond what the schema provides; baseline 3 is appropriate.

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

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

The description states a specific verb ('View'), resource ('someone's public portfolio'), and input mechanism ('by their identifier'). The 'someone's public' phrasing implicitly distinguishes this from tools like get_profile that likely return the caller's own profile, but it does not explicitly name any sibling alternative.

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

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

There is no explicit when-to-use or when-not-to-use guidance, nor any mention of alternative tools such as get_profile or get_portfolio_analytics. The context is implied only by the word 'someone's', which is insufficient to route the agent confidently.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'View' implies a read-only operation, but nothing is said about required auth, whether stats come from a live browser session, how fresh the data is, or what happens if the extension is disconnected.

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 redundancy. It is appropriately terse, though its brevity reflects under-specification rather than disciplined 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?

There is no output schema and no annotations, so the description alone must convey what the agent gets back. It never indicates which statistics are returned, their time scope, or their format, leaving a significant gap for a reporting 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 and the schema is empty with 100% coverage, so there is nothing for the description to clarify. Baseline 4 applies for a parameterless tool.

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 ('view') and resource ('job scraping statistics') plus a data source ('from the browser extension'), so the agent knows what it retrieves. However, it does not distinguish itself from the close sibling get_scraping_stats_aggregated, leaving ambiguity about whether this is raw or summary data.

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 get_scraping_stats_aggregated or the other analytics tools (get_dashboard_stats, get_portfolio_analytics). No prerequisites, timing, or exclusions are stated; the agent must infer usage entirely.

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

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

No annotations are provided, so the description carries the full burden. It implies a read-only view but says nothing about permissions, rate limits, freshness of the statistics, or what 'aggregated' covers — meaningful gaps for a statistics 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?

One front-loaded sentence with no filler. Efficient, though very short for an analytics tool with no other documentation.

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, no annotations, and no parameters, the description is the only documentation and it only sketches the shape of the result. It does not explain what dimensions or granularity of aggregation are returned, nor how it relates to the sibling get_scraping_stats.

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 compensate for; the baseline for a no-param tool applies.

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

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

States a verb ('View') and resource ('aggregated scraping statistics') and adds scope ('breakdowns by website and time period'). However, the sibling get_scraping_stats exists and the description does nothing to distinguish this aggregated variant from it, leaving the agent to guess which to call.

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

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

The mention of breakdowns hints at the kind of output, but there is no explicit when-to-use guidance and no routing to or away from the sibling get_scraping_stats. The agent must infer 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?

No annotations are provided, so the description carries the full behavioral burden. 'View' implies a safe read, but it omits whether authentication is required, whether pricing is localized/user-specific, and what the response shape looks like.

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. 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 trivial zero-param read tool the description is nearly adequate, but with no annotations and no output schema it says nothing about access requirements or return content, leaving minor 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 tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies.

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

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

States a specific verb ('View') and resource ('subscription plans and pricing'), so the agent knows exactly what comes back. It does not explicitly differentiate itself from the sibling get_subscription_status, leaving the plans-vs-current-status distinction to inference.

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

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

No indication of when to call this versus get_subscription_status or check_feature_access, and no prerequisites or auth notes. The agent must infer usage purely from the name.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Check' and the get_ naming imply a safe user-scoped read, and it lightly signals the return content (status plus plan details), but it says nothing about auth requirements or what happens when the user has no subscription.

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

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

A single front-loaded sentence with no filler; the essential action and object come first. It is appropriately sized, though it could have used the remaining space for the sibling routing that is missing.

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 read with no output schema, the description covers the essentials by naming what is returned (status and plan details). The one real gap is disambiguation from the sibling plan-listing and feature-access 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?

The tool takes zero parameters, so there is no parameter semantics to document. The baseline for a parameterless tool is 4, and nothing in the description misrepresents the empty schema.

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

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

States a specific verb-and-resource pair: checking the user's subscription status and plan details. It is clear stand-alone, but it never distinguishes itself from the close sibling get_subscription_plans or from check_feature_access, so an agent must guess which subscription-related tool to pick.

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

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

There is no guidance on when to use this rather than get_subscription_plans, check_feature_access, or get_payment_history, all of which live in the same subscription/payment cluster. The description only implies usage through its 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?

Annotations are absent, so the description carries the full disclosure burden. It confirms the read is scoped to unread items but says nothing about whether the count is per-user, whether it is cached/eventually consistent, or what value is returned for zero notifications. For a trivial read the risk is low, but the disclosure is still thin.

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. It is appropriately sized for the operation, though so terse that it borders on under-specification rather than earn-its-place concision.

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 read with no output schema, the description states what is being counted (unread notifications), which is the essential information. Nothing required to invoke it correctly is absent.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify. Baseline 4 applies; no schema semantics are 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 ('Get') and resource ('count of unread notifications'), which is unambiguous against siblings like get_notifications (full list) and mark_notifications_read (mutation). It does not explicitly name those siblings, but the resource itself is distinctive enough that an agent can route correctly.

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

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

No when-to-use or when-not-to-use guidance. It doesn't say to prefer this over get_notifications when only a count is needed, nor does it mention any prerequisites. Usage is only inferable 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?

With no annotations provided, the description carries the full behavioral burden. It does disclose that disabled schedules are included and enumerates the returned fields (ID, keyword, location, sources, cron expression, enabled status, last run time), which is meaningful behavioral context given there is no output schema. It omits read-only/safety framing, permissions, and pagination or ordering behavior.

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

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

Two sentences, zero filler. The core action and scope ('all scheduled job discovery cron jobs, including disabled ones') come first, followed by the return-field list. Every clause earns its place.

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

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

For a parameterless, read-only listing with no output schema and no annotations, the description covers the essential behavior and the shape of the results. It is nearly complete; only ordering/pagination and access requirements are absent, which are minor for a listing 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 per the rubric the baseline is 4. The description correctly implies there is nothing to supply and instead describes what comes back, adding no misleading parameter expectations.

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

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

The description gives a specific verb ('List') and a clearly bounded resource ('scheduled job discovery cron jobs'), plus the notable scope qualifier 'including disabled ones'. It is unambiguous what the tool returns, but it never names or contrasts itself with the closest siblings (schedule_jobs, toggle_schedule, delete_schedule, get_latest_discovery_report).

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

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

Usage is only implied: the tool is for viewing schedules, and the 'including disabled ones' clause hints it is the comprehensive view rather than a filtered subset. There is no explicit when-to-use guidance, no mention of when to use get_latest_discovery_report or toggle_schedule instead, and no prerequisites stated.

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

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

With no annotations, the description carries the full behavioral burden and discloses key traits: it opens a browser for user interaction, saves cookies, and enables future scrapes to access full job details. It also notes the once-per-site usage pattern. It does not cover what happens if already logged in, browser blocking behavior, or error cases, but it provides substantial behavioral context.

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

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

Three sentences, each earning its place: purpose first, then the side effect and benefit, then the usage instruction. It is front-loaded and free of redundant detail.

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 schema, no annotations, and no output schema, the description covers purpose, key side effect, and usage timing well. An agent can determine when and how to call it. Some minor gaps remain around return behavior and edge cases, but no structured field is left unexplained.

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

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

Schema description coverage is 100%, and the schema itself documents the single 'site' parameter with allowed values 'seek' or 'linkedin'. The description mentions SEEK or LinkedIn but adds no syntax, format, or meaning beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description states a specific verb and resource: 'Open a browser window for the user to log in to a job site (SEEK or LinkedIn).' It names the supported sites and clearly distinguishes this login action from sibling tools like check_login_status, which checks status rather than performing login.

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 a clear timing instruction: 'Run this once per site before scraping.' This tells the agent when to invoke the tool. However, it does not explicitly state when not to use it or name an alternative for checking existing login state.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure and delivers almost nothing: no statement about idempotency, error behavior for an unknown ID, permission requirements, or whether the change is reversible. Only the basic mutation intent is conveyed by the verb.

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 short sentence with the action front-loaded and zero filler. It is efficient, though its brevity is achieved partly by omitting information that would be useful.

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, has one fully documented required parameter, and needs no output schema, so the description is minimally sufficient for invocation. It falls short on the one thing that matters here: disambiguating from the sibling bulk-mark tool.

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

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

Schema description coverage is 100% and the single parameter (notification_id) is fully documented in the schema, so the description adds no parameter detail beyond it. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb (mark) and resource (a single notification, as read), so the action is unambiguous. However, it does nothing to distinguish itself from the sibling mark_notifications_read, which performs the same action in bulk — the singular/plural distinction is left for the agent to infer.

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

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

There is no when-to-use guidance at all: nothing says to use this for one notification and mark_notifications_read for several, nor what happens if the ID is already read. The presence of a near-identical sibling makes this omission consequential.

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

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

With no annotations provided, the description carries the full burden, and it discloses only that the operation is a bulk state change. It says nothing about whether the change is reversible, whether it requires authentication, whether already-read notifications are affected, or what (if anything) 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?

One short sentence with no waste and the scope qualifier front and center. It is appropriately sized for the operation, though the terseness contributes little beyond the minimum.

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

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

For a no-param mutation with no annotations and no output schema, the description is minimally viable but incomplete: it omits scoping (all notifications, all users?), reversibility, and the sibling distinction. An agent could invoke it correctly, but only by guessing at the behavioral edges.

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 the schema has nothing to document and there is nothing for the description to clarify. Baseline 4 applies for a parameterless tool.

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

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

The description gives a specific verb ('mark') plus resource ('notifications') and scope ('all'), so an agent can tell it apart from the singular sibling mark_notification_read by the word 'all'. It stops short of naming that sibling explicitly, but the scope word does the differentiating work.

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

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

There is no guidance on when to use this versus mark_notification_read (single) or whether it is intended as a bulk operation for a specific notification set. The agent must infer the alternative from the sibling list 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?

With no annotations, the description carries the full burden, and it usefully discloses two nontrivial traits: the passed URL may be rewritten (aggregator resolution) and the browser session persists for later calls. However, it omits authentication preconditions (siblings include login_jobsite/check_login_status) and any error or failure behavior, leaving meaningful gaps for a stateful browser tool.

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

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

Three tight sentences, front-loaded with the core action, then side-effect behavior, then workflow constraint. No filler; each sentence adds a distinct fact.

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 tool with no output schema, the description covers purpose, URL-rewriting behavior, and session persistence adequately. The main omissions are auth preconditions and failure handling, which matter given the surrounding login and browser-automation siblings.

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

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

Schema coverage is 100% and the single 'url' parameter is fully documented in the schema, so the description adds no syntax or format detail beyond it. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific verb and resource ('Open a job application page in the browser') and adds distinguishing behavior (aggregator detection and URL resolution) that separates it from siblings like login_jobsite or click_element. An agent can identify the tool's job 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?

'Keeps the browser open for subsequent form-filling tool calls' establishes sequencing context, signalling this is a prerequisite for fill_form_field/upload_resume/click_element. It gives clear workflow context but names no explicit exclusions or alternatives for opening pages.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about whether the rename is reversible, whether it requires ownership/permissions, whether name collisions are handled, or what errors can occur. For a mutation tool with zero annotation coverage this is a significant gap.

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

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

A single short sentence with zero waste and the action front-loaded. It is efficient, though brevity here reflects under-specification rather than disciplined trimming.

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 mutation tool with no annotations and no output schema, the description is too thin. It omits permission requirements, side effects, reversibility, and any indication of return behavior, leaving the agent with gaps before invoking it.

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

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

Schema description coverage is 100%, so both parameters (document_id, name) are already documented in the schema. The description adds no extra meaning such as format constraints, uniqueness requirements, or naming rules, so baseline 3 applies.

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

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

States a specific verb (rename) and resource (document), which is unambiguous and distinct from the sibling read/delete document tools. It does not explicitly contrast itself with get_document, delete_document, or get_documents, so it falls short of full sibling differentiation.

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

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

The description gives no when-to-use guidance, prerequisites, or alternatives. There is nothing telling an agent under what circumstances renaming is appropriate versus other document operations.

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

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

No annotations are provided, so the description carries the full behavioral burden. For a mutation tool it omits whether the action is reversible, whether the sender is notified, and what accepting actually triggers (e.g., opening a chat thread).

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

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

A single efficient sentence with the action front-loaded and zero filler. It is well-sized but leaves no room for the context a mutation tool 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?

With no annotations, no output schema, and a destructive-ish state change (accepting/declining a request), the description should say what happens after the call and what constraints apply. It leaves the agent guessing about side effects.

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

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

Schema coverage is 100% with both parameters documented, and the action enum values are mirrored in the schema description. The description adds no format or constraint details beyond what the schema already provides, so baseline 3 applies.

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

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

States a specific verb pair (accept/decline) and an unambiguous resource (a received coffee chat request). It is clear what the tool does, though it does not explicitly differentiate itself from siblings like send_coffee_chat_request beyond the word 'received'.

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 word 'received' implies this applies to incoming requests rather than sending one, but there is no explicit when-to-use guidance, no prerequisites (e.g., must be the recipient), and no named alternative 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?

With no annotations provided, the description carries the full behavioral burden. It says 'save' but doesn't disclose permissions, whether it's a write/mutation, what happens on duplicate entries, return values, or any side effects. This is a significant gap for a write 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 succinct sentences with no waste; the purpose is front-loaded and the usage condition follows immediately.

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 tool with 8 parameters, no output schema, and no annotations, the description is adequate on purpose and usage but leaves behavioral aspects (permissions, side effects, error handling) and any return value information unaddressed.

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

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

Schema description coverage is 100%, so all 8 parameters are already documented in the schema. The description adds no parameter-level detail beyond what the schema provides, so baseline 3 applies.

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

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

The description states a specific verb and resource ('Save a new job application to track') and distinguishes itself from siblings like update_job_status, delete_job, and discover_jobs by emphasizing creation of a new tracked 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?

It clearly explains when to use it ('when the user wants to save or add a job they're interested in or have applied to'), giving good context, but doesn't explicitly name alternative tools or when not to use it (e.g., use update_job_status for existing jobs).

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