PM Career Desk

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

Goes well beyond the annotations: discloses an auth precondition (PM Career Desk account with an Interview Coach Pass), a data-handling side effect (contact details removed before recording), the return shape (compact verdict plus follow-up probe or next question), and the translation contract for non-English answers. These are exactly the traits annotations (readOnly=false, destructive=false) do not convey.

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

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

Front-loads the core action and the return value, then the skip, translation and auth caveats — a sensible order with no filler sentences. The parenthetical enumeration of probe types ('own action, a result in numbers, the figure before, one specific example') makes one sentence heavy, but each clause carries information.

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

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

With six parameters, no output schema and mutation-flavored annotations, the description covers the missing pieces: what comes back, what gets redacted, what identity is required, and how non-English input is handled. Nothing an agent needs to call it correctly and interpret the reply is absent.

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

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

Schema coverage is 100%, so every parameter is already documented in the input schema, including lang, skip, turn, answer and text_en. The description restates the skip and translation behavior and hints at the cross-parameter rule that a literal English translation travels with the original, but adds little syntax or constraint detail the schema lacks. 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?

Uses a specific verb pair (records the answer, checks its structure) on a specific resource (the current question of a mock interview session) and names the rule engine it delegates to (check_interview_answer). An agent can distinguish it from start_mock_interview, finish_mock_interview and check_interview_answer without reading the schema.

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

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

States the operating context (the current question or follow-up in an existing session) and the one branch condition that matters — 'skip moves on without an answer'. It does not explicitly say a session must exist first, though the session_id parameter description carries that. Clear context, but no explicit when-not/alternative routing beyond skip.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered; the description adds real value beyond that by stating the output is rule-based ('no model'), that contact details are stripped before checking, that the resume is not stored, and that an Interview Coach Pass is required. It stops short of describing failure modes or whether the open-questions list can be empty, which keeps it from a 5.

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

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

The core action and constraints are front-loaded in a single dense paragraph with no filler sentences. It is long, but each clause (output count, competencies, open questions, determinism, privacy, auth) carries distinct information; a short lead sentence or bullet structure would make it easier to scan.

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

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

There is no output schema, so the description must characterize the return value, and it does: the number of stories, their STAR structure, competency labels, and the open-questions list. Combined with annotations covering safety and the description covering auth and privacy, an agent has enough to call this correctly; return formatting and error cases remain 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?

Schema description coverage is 100%, so both parameters are already documented in the schema and the baseline is 3. The description reinforces that stories draw only on the resume's own lines and figures but adds no new syntax, format, or length guidance for resume_text or role beyond what the schema states.

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

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

The description opens with a concrete verb and artifact: builds 10–15 STAR interview stories from resume text, scoped to project/program/product managers. It is unmistakably distinct in content from siblings like review_resume or prepare_interview_questions, but it never names or explicitly contrasts an alternative, which keeps it at 4 rather than 5.

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

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

Usage is only implied: the agent can infer this belongs to interview-story preparation rather than resume critique, but there is no explicit 'use this when' statement or exclusion of sibling tools. The sign-in/Interview Coach Pass requirement is a useful prerequisite but is an access condition, not usage guidance.

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

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

Annotations only declare read-only/idempotent/non-destructive; the description adds real behavior: a 6000-character limit, contact details stripped before processing, nothing stored, figures unconfirmed when resume_text is absent, and what the result contains (rubric plus gaps). These are operational facts an agent could not infer from 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?

Front-loads purpose, then usage, then inputs, then limits and exclusions — a sensible order. The long enumeration of checked items is dense but each item is a distinct rule the agent benefits from knowing; only slight trimming would improve it.

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

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

With no output schema, the description does describe the return ('the rubric for the question type and what is missing') and covers limits, privacy handling, and non-persistence. The return shape is described only in one clause, so an agent knows roughly what comes back but not its structure — the main remaining gap.

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

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

Schema coverage is 100%, so the baseline is 3; the description still adds value by pairing question_id with its source tool and giving sample question_type values (conflict, failure, stakeholder, prioritization, measure) plus the conditional effect of resume_text. It mainly restates the schema's 'one of question_id and question_type is needed' rule, so it is not fully additive.

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 ('checks the structure of one practice answer') and enumerates exactly what is checked (situation, first-person action, result, figures, filler, we/I balance). This clearly separates it from siblings like answer_mock_question (which would evaluate content) and check_resume_line (which targets resumes).

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

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

Gives a clear trigger ('use it when the person writes or pastes an answer and wants feedback before the interview') plus explicit exclusions ('does not judge whether the story is true', 'does not write the answer'). It stops short of naming a sibling tool as the alternative path, which keeps it below a 5.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: the exact review criteria, the output shape (up to 10 findings ordered by risk, each with line, recruiter question and direction, plus per-section scores), the boundary 'It does not rewrite the text', and data-handling facts (English only, contact details stripped first, nothing stored). That is exactly the kind of disclosure structured fields cannot carry.

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

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

Front-loaded with purpose, then usage, then the criteria list, then return shape and limits, so the ordering is sound. The criteria sentence is a long comma-heavy enumeration that could be tightened, but every sentence carries information an agent would otherwise lack.

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 eight optional parameters and no output schema, the description must carry return-shape and constraint information, and it does: finding count, ordering, per-finding structure, per-section scores, language handling and privacy behavior. Nothing an agent needs in order to call it correctly is missing.

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

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

Schema description coverage is 100%, so the schema already explains lang, role, the _en translation fields and the 'at least headline or About' rule; the description adds no new syntax or format detail. Baseline 3 applies because 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 ('Checks the LinkedIn headline and About section'), plus an explicit scope (PM, TPM, PMO lead) and optional extension (top experience entry). That is clearly separable from siblings like review_resume, check_resume_line and check_interview_answer, which operate on different artifacts.

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: 'Use it when someone asks to review or improve their LinkedIn profile for recruiters.' This is enough to route the agent away from resume and interview tools. It stops short of naming those siblings or stating exclusions explicitly, so it is not a 5.

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

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

Annotations already cover read-only, idempotent, non-destructive and closed-world behavior, so the description adds genuine extra context: it returns one finding plus a likely hiring-manager question, removes contact details before analysis, stores nothing, and enforces a 5-word/500-character English input. It doesn't explain what happens on invalid or too-short input, which is the only notable 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?

Four tight sentences, front-loaded with purpose, then usage, then return value, then input/privacy constraints. No sentence is redundant, and nothing important is buried.

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

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

With no output schema, the description correctly explains what is returned ('one finding and the question a hiring manager may ask'). Combined with rich annotations and a fully documented schema, only edge-case behavior (invalid line length, non-English without text_en) is 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?

Schema coverage is 100% and all four parameters are documented in depth, so the schema does the heavy lifting. The description only restates the line constraints ('5 words to 500 characters, English') without adding meaning for lang, role or text_en; the 'contact details are removed first' note is input preprocessing rather than parameter guidance.

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 ('Checks') and a precisely scoped resource ('one resume bullet'), plus the audience (PM/TPM/PMO). The scope word 'one' implicitly separates it from the sibling review_resume, which handles whole resumes.

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

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

Gives a clear trigger: 'Use it when someone asks about a single line or wants to test a rewrite of it.' It stops short of naming an alternative (e.g. review_resume for the whole document) or stating when not to use it, so it falls just below the top score.

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

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

Adds substantial context beyond the annotations: 'Fixed rules, no model' explains why the operation is deterministic and idempotent, 'Contact details are removed before the check; the resume and the posting are not stored' discloses data handling, and the sign-in plus Interview Coach Pass requirement is an auth constraint the annotations do not carry. It also describes how output items are constructed and traced back to posting requirements and resume lines.

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?

Purpose and output shape are front-loaded, then constraints (determinism, privacy, auth) follow in a logical order with no repeated sentences. Some phrasing is dense and slightly awkward ('Fixed rules, no model', 'the check'), costing a point on clarity.

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

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

With no output schema, the description carries the burden of describing the return value, and it does so at a useful level of detail (three horizons, requirement traceability). Privacy, auth, and determinism are covered; what's missing is any sense of output size/format or failure behavior, a minor gap for a read-only generator.

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 earns more by explaining how the two required inputs are used — the plan is built from the posting's requirements and each item is paired with a matching resume line. The optional 'role' parameter is not addressed in the description, keeping it short of a 5.

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

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

States a specific verb and artifact ('Drafts a 30-60-90 day plan skeleton') scoped to one job posting, and enumerates the three horizons the output covers. This artifact is clearly distinct from the sibling set (prepare_interview_plan, match_resume_to_job, review_resume), so an agent can route without opening a schema.

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

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

Usage is implied by the required inputs (resume + full posting) and the stated sign-in/pass prerequisite, which tells the agent when the call will succeed. But it never names an alternative or exclusion — e.g. when to use prepare_interview_plan or match_resume_to_job instead — leaving the agent to infer selection.

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

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

Goes well beyond the annotations by disclosing the one-time download link, the 10-minute expiry, in-memory construction with no retained file, contact-detail scrubbing before the check, and the account/Pass requirement. These are exactly the operational traits an agent cannot infer from readOnlyHint=false and destructiveHint=false.

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

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

Front-loaded with what is produced, then the return value, then the constraints. Two dense sentences with little waste, though the parenthetical and the list of contents make the first sentence long enough to slow scanning.

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

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

With no output schema, the description still explains the return value (single-use expiring download link) and the artifact contents. Combined with the auth prerequisite and the seven optional/required parameters documented in the schema, an agent has everything needed to invoke it correctly.

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

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

Schema description coverage is 100%, so the schema already documents role, company, job_posting, job_requirements and resume_outline in detail. The description adds thematic context (the requirement map and gaps come from the posting; the answer texts come from save_practice) but does not add format or syntax detail 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 precise verb and artifact: builds the full interview plan as a Word .docx and returns a download link. It explicitly anchors the content to prepare_interview_plan and to save_practice answers, so an agent can distinguish it from the sibling that only prepares the plan.

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

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

Usage context is clear: this is the file-export counterpart of prepare_interview_plan, and it requires an Interview Coach Pass, which is a genuine gating condition. What is missing is an explicit statement of when to choose this over prepare_interview_plan (view plan in chat vs. download a document).

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?

Goes well beyond annotations: 180-day retention and deletion of saved progress, what exactly is persisted (question id, checks met, word count) versus the answer text only under keep_answer_text, encryption with the account key, English translation for non-English answers, and removal of answers from the session. The auth/pass requirement is also disclosed, which annotations cannot express.

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

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

Front-loaded with the outcome (scorecard contents) before the persistence rules, and every clause carries distinct information. It is dense and runs long as a single flowing block, which slightly hurts scanability, but there is essentially 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?

There is no output schema, and the description compensates by describing exactly what the scorecard contains and what persistence side effects occur. Auth requirements, idempotent re-finish behavior, and answer deletion are all covered, leaving no material gap for an agent to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: save_progress false saves 'nothing' and keep_answer_text controls whether text is stored encrypted with the account key, with a translation note for non-English answers. This explains consequences of the flags rather than restating their types.

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 ('Ends a mock interview') and immediately names what it returns — the scorecard with competency outcomes and three next-practice questions with ids. This clearly complements start_mock_interview and cannot be confused with siblings like check_interview_answer.

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 end-of-session context is clear and the description states the prerequisite (sign-in plus an Interview Coach Pass). It also tells the agent that re-finishing the same session is safe and returns the same scorecard, though it never explicitly contrasts with siblings such as check_interview_answer or save_practice.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is covered. The description adds behavior beyond that by describing the exact return shape (10 questions, six labeled options) and a scope limitation on how results should be interpreted, which is genuinely useful for a no-output-schema 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 sentences, zero waste. What the tool returns is front-loaded and the interpretation caveat follows immediately after, in the right order.

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

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

With no parameters and no output schema, the description carries the burden of telling the agent what comes back, and it does so (question count, option labels). It stops short of describing pagination/format or how to feed answers into score_pm_archetype, which would complete the picture.

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 is nothing for the description to disambiguate. Baseline 4 applies; the description correctly refrains from inventing parameter detail.

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

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

States a specific verb (Returns) and resource (the PM Archetype test), plus concrete content details: 10 questions, six options labelled A to F. It doesn't distinguish itself from the related sibling score_pm_archetype or get_pm_title_fit_questions, so an agent must infer the boundary from 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?

The caveat 'For reflection, not a psychometric or hiring assessment' tells the agent one context where the output shouldn't be used, which is real guidance. But there is no explicit when-to-use routing to the obvious companion tools (score_pm_archetype, get_pm_title_fit_questions), leaving the workflow position implied rather than stated.

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

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

Annotations already establish readOnly/idempotent/non-destructive, and the description adds real content detail: exactly 9 questions and a-to-d labelled options, which the agent needs to format an answer. It doesn't say whether the question set is static or personalized, but for a fixed read this is solid.

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

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

A single compact sentence that front-loads the return count and resource, then adds the two facts an agent needs (comparison scope, option labels). No filler.

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

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

With no output schema and no parameters, the description carries the return-shape burden and mostly does so (count, options a–d). It stops short of describing whether each question includes an id or prompt field, which would fully close the loop for an agent building answers.

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 and the schema is fully self-describing. 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 and resource ('Returns the 9 questions of the title fit check') and clarifies exactly what the check compares (PM vs program manager vs TPM) for the user's current work. This clearly separates it from siblings like match_pm_title and get_pm_archetype_test.

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

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

Usage is only implied: an agent can infer this is the retrieval step preceding a scoring step, but the description never names the sibling that consumes the answers (likely match_pm_title) nor states when to choose this over get_pm_archetype_test. No explicit when/when-not guidance is 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?

Beyond the readOnly and idempotent annotations, the description discloses ordering, a 50-result cap, per-question summary contents, and the conditional inclusion of answer text. It also states the authentication requirement, which is meaningful 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?

Two sentences are tightly packed with no wasted wording. The return scope and ordering are front-loaded before the conditional answer-text detail and authentication requirement.

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, but the description compensates by explaining what the result contains: attempts, best structure-check count, last date, and optional answer text. The pagination cap and auth prerequisite are also stated, leaving no major gaps for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description adds useful meaning for include_answer_text by clarifying that kept answer texts appear only when true, but it does not mention the optional question_id filter at all.

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

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

The description gives a specific verb and resource: it returns saved practice attempts for the signed-in account, with scope details such as newest first and up to 50 results. It also names the per-question summary fields, making it clearly distinguishable from siblings like save_practice.

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 states a clear prerequisite: sign-in with a PM Career Desk account that has an Interview Coach Pass. It does not explicitly compare when to use this versus siblings such as answer_mock_question or save_practice, but the retrieval context is clear.

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

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

Annotations already cover readOnly, idempotent, non-destructive and closed-world; the description adds the meaningful separate point that 'Nothing is stored', which clarifies persistence rather than mere read-safety. Because there is no output schema, the description also carries the return-value burden, and it does say what comes back. It doesn't cover edge cases such as invalid or incomplete answer sets.

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

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

One tightly packed sentence with the action, the input provenance, and the return contents front-loaded; every clause earns its place and nothing is repeated.

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

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

For a single-parameter, read-only tool with no output schema, the description supplies what the agent needs: input shape, upstream tool, return contents, and the no-storage guarantee. Minor gap on behavior with malformed answer sets.

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 schema parameter description already states '9 answer letters, a to d, one per question in the order of get_pm_title_fit_questions, as a list or as one string.' The tool description essentially restates this, adding the count and provenance but no new syntax or format details. 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 (scores) and resource (the 9 title fit answers), then names the exact output (closest title among PM, PgM, TPgM plus what hiring managers look for). It explicitly distinguishes itself from the sibling get_pm_title_fit_questions as the scoring counterpart to that 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?

The dependency is spelled out: answers must be 'as returned by get_pm_title_fit_questions', so an agent knows this is the second step after fetching the questions. No explicit exclusions or when-not-to-use guidance is given, but for a single-purpose scorer the context is clear.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description still adds real context: fixed rules with the same result for the same texts, resume capped at 30000 and posting at 15000 characters, contact details stripped before processing, and nothing stored. That covers determinism, limits, and privacy beyond what annotations say, though it doesn't say what happens when input exceeds those caps.

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?

Purpose and triggers come first, then output shape, then constraints, so it is well front-loaded. It is a single dense block and the audience list plus the years/budget rule add length, but each sentence carries usable information.

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

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

With no output schema, the description carries the return-value burden and does it: each requirement as covered/partial/gap/not checked, with supporting resume lines, plus how years and budget requirements are interpreted. Combined with limits and privacy behavior, an agent has enough to call it correctly and set expectations.

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 baseline is 3, but the description adds operational detail the schema lacks: the 30000/15000 character ceilings and the fact that outline/requirement lines must appear word for word in the source text or they are dropped and counted. It doesn't expand on the role enum values beyond what the schema already lists.

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 (matches) and both operands (job posting, resume), and scopes the audience (PM/TPM/PMO/BA), which distinguishes it from siblings like review_resume or match_pm_title. An agent can route to 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 trigger set — 'whether they fit a posting, what is missing, or how to tailor their resume' — which reads as concrete user intents. It stops short of naming when to prefer review_resume or match_pm_title instead, so sibling boundaries are left implicit.

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

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

Adds materially beyond the annotations: 'Fixed rules, no model' discloses deterministic behavior (consistent with openWorldHint=false), 'Contact details are removed before the check; the resume and the posting are not stored' discloses PII scrubbing and retention policy, and the Interview Coach Pass requirement discloses an auth gate. These are exactly the operational facts annotations cannot carry.

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

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

Front-loaded with the verb and resource, then the output inventory, then operational constraints. The long opening sentence is dense but each clause maps to a distinct output artifact; nothing is padding, though the four-part enumeration could be tightened slightly.

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

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

With no output schema, the description carries the return-value burden itself and does so by listing the four components of the plan. Combined with the auth prerequisite, PII handling, and no-storage guarantee, an agent has enough to decide and call correctly; only error/failure behavior is left unstated, which is minor.

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

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

Schema description coverage is 100%, so the schema already documents every parameter including the verbatim-matching rules for resume_outline and job_requirements and the 'adds questions written for that industry' behavior. The prose restates that resume text plus optional posting/company drive the plan but adds no new format or constraint detail, 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 ('Builds the full interview plan') and then enumerates the concrete artifacts produced: resume lines a hiring manager will press on, posting requirements matched, company questions with source pages, questions ordered by interview stage. It also explicitly separates itself from the sibling by noting 'Same inputs and question ids as prepare_interview_questions', so an agent can distinguish full plan vs. question list without opening either schema.

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

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

Gives a clear usage context (a PM/PgM/product manager or business analyst prep, driven by resume text plus optional posting and company) and states a hard prerequisite: sign-in with a PM Career Desk account holding an Interview Coach Pass. The alternative is implied through the prepare_interview_questions reference, but there is no explicit 'use the other tool when you only want the raw question list' exclusion.

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

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

Annotations already establish readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: contact details removed first, nothing stored, deterministic output ('the same result for the same text'), English findings regardless of the lang field, and that resume_outline/job_requirements lines not matching verbatim are dropped and counted. That last rule and the PII stripping are behavior an agent could not infer from structured fields.

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

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

Front-loaded with the purpose and trigger, then a single 'Returns:' block, then optional params, then fixed rules — a sensible ordering, and every element carries information. It is a dense, long paragraph with repeated 'Optional:' lead-ins and semicolon-chained clauses that make it slower to scan than it needs to be.

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

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

With 9 parameters, no output schema, and a nested ResumeOutline type, the description carries the necessary load: it enumerates the three output groups, explains the question-id linkage to check_interview_answer, states language and PII handling, and documents what the optional inputs change. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds effect-level meaning the schema lacks: company yields questions from what large US employers publish with source links, and interview_date yields days-left plus practice prioritization. It also explains the resume_outline/job_requirements verbatim-match constraint and its drop-and-count consequence, which is more precise than the schema wording.

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 artifact ('builds a job interview prep set') and scopes the target population (PM, program manager, TPM, PMO lead, business analyst) plus the inputs (resume text, optional posting). It also hands off to the sibling that consumes its output ('each question has an id to pass to check_interview_answer'), so it is clearly distinguishable from build_story_bank or start_mock_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?

Gives an explicit trigger: 'Use it when someone shares a resume (pasted or attached) before an interview, or asks what a hiring manager will ask them.' That covers the when. It does not name the nearest alternatives (prepare_interview_plan, match_resume_to_job, check_interview_answer) as when-not paths, so the agent must infer the boundary from sibling names 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?

The description adds substantial behavior beyond the annotations: it returns up to 12 risk-ordered lines, includes findings and likely hiring-manager questions, identifies missing role signals, does not rewrite lines, accepts English up to 30000 characters, strips contact details, and stores nothing. These details clarify output shape, limits, privacy handling, and non-mutating behavior.

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

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

The description is front-loaded with purpose and usage, then compactly covers output, scope limits, and privacy. Every sentence contributes useful selection or invocation context, with no redundant restatement of the schema.

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

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

Given there is no output schema, the description explains what the tool returns, how results are ordered, and what it will not do. With annotations covering safety and the schema covering parameters, the definition is complete enough for correct selection and invocation.

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

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

Schema description coverage is 100%, so both parameters are already well documented in the schema. The description adds the 30000-character limit and contact-detail removal, but it does not explain the optional role parameter, so the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: reviewing a whole resume line by line for PM/TPM/PMO/BA roles. It distinguishes itself from sibling tools like check_resume_line and match_resume_to_job by emphasizing whole-resume scope and risk-ordered findings.

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 usage trigger: when someone shares a resume and asks for review, feedback, or what to fix before applying. It does not explicitly name when to prefer sibling tools such as check_resume_line or match_resume_to_job, so it stops short of full 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?

Annotations only cover the safety profile (non-read-only, non-destructive, non-idempotent), and the description adds substantial behavior beyond that: minimal default payload, opt-in answer/question text, encryption with the account key, 180-day retention, PII stripping before the check, translation-based checking for non-English answers, and an explicit auth/Pass requirement. This is exactly the context annotations cannot supply.

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

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

Front-loaded with the action and the consent condition, then layers retention, encryption, and auth. Dense but mostly earning its place; the language/translation and PII sentences are close in spirit and could be merged, and the description runs long for a single-sentence-per-idea 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?

With no output schema and seven parameters, the description covers consent, default vs opt-in persistence, retention, encryption, and auth prerequisites. It does not describe what the call returns (beyond hints that 'the result names this language'), nor duplicate-submission behavior for a non-idempotent write, leaving a small gap.

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

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

Schema coverage is already 100%, so the baseline is 3; the description goes further by explaining that text_en drives the fixed rules for non-English answers, that keep_answer_text governs encryption-at-rest of the text, and that question_id and question_type are alternatives. It stops short of explaining lang's effect 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 and resource (saves one practice answer attempt to the signed-in account) plus the scope of what is persisted by default. It also distinguishes itself from check_interview_answer by noting that the same structure rules apply but that this tool persists progress, so an agent can separate the two without opening either schema.

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

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

Gives an explicit trigger — 'when the person asks to save it' — and clarifies the relationship to check_interview_answer. It does not spell out the inverse case (do not call without the person's request) or point at get_practice for retrieval, so the routing guidance is clear but not exhaustive.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the bar is lower; the description still adds meaningful context with 'Nothing is stored.' (confirming no persistence) and an enumeration of the return payload (primary archetype, secondary streak, strengths, blind spot, resume fix) that compensates for the absent output schema. It does not describe behavior on malformed or short answer strings, which keeps it from a 5.

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

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

Two sentences, tightly packed: input contract and provenance first, return payload and side-effect status second. No filler, no restatement of the title, and the most decision-relevant information is front-loaded.

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

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

For a single-parameter tool with no output schema, the description covers the input contract, prerequisite tool, output shape, and side-effect status — essentially everything needed to invoke it correctly. The only omission is failure behavior for invalid or partial answer sets, 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% and the schema already documents both the list form and the compact string form with a full example, so the baseline of 3 applies. The description only restates the 'A to F, in question order' constraint already present in the schema, adding no new syntax or validation semantics.

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 ('Scores') plus specific resource ('the PM Archetype test from 10 answer letters'), with the input shape and ordering constraint stated up front. It also names the sibling that produces the input (get_pm_archetype_test), so the agent can distinguish it from that tool without opening either schema.

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

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

The description establishes a clear precondition and sequencing: answers must come 'in question order, as returned by get_pm_archetype_test', which tells the agent to call that tool first. It does not state what to do if the user supplies fewer than 10 or invalid letters, nor name any alternative scoring path, 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?

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false): it discloses 24-hour session retention, account-key encryption, contact-detail stripping before processing, English-only question output, and the auth/pass requirement. These are exactly the operational facts an agent cannot get from structured fields.

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

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

One dense paragraph with the core action and role scope front-loaded, then generation logic, then return value, then constraints. It is long but nearly every clause carries information; only the question-composition sentence is somewhat sprawling.

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

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

With no output schema, the description carries the return burden and does so ('session id and the first question only'), plus retention, encryption, PII handling, language behavior and prerequisites. For a 9-parameter, non-idempotent creation tool this covers everything needed to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds cross-parameter behavior by stating that lang only names the person's language while questions remain English, and that length is clamped to 5-10. It does not elaborate on how job_posting and job_requirements interact beyond what the schema already 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?

Specific verb and resource: 'Starts a mock interview' for a named set of PM/BA roles, generated from resume text plus optional posting and company. It also scopes the output precisely ('Returns a session id and the first question only'), which clearly separates it from answer_mock_question and finish_mock_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?

Gives clear operating context: it is the session entry point, it needs a PM Career Desk account with an Interview Coach Pass, and it produces the session id that later steps consume. It never names a sibling such as prepare_interview_questions or prepare_interview_plan, so an agent must infer why one is preferred over the other.

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