JobGPT

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 the action ('Add') but omits critical behavioral details: whether the operation is idempotent, what happens if the job is already in applications, whether it creates a new database record, or what the response indicates.

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

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

Two sentences with zero waste: the first states the function, the second states the usage condition. Information is front-loaded and appropriately sized for the tool's simplicity.

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

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

Given the simple 2-parameter schema and lack of output schema, the description covers the essential purpose and usage. However, for a mutation tool with zero annotations, it is minimally viable—it lacks behavioral guarantees, error conditions, or return value description that would make it fully complete.

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

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

Schema description coverage is 100%, establishing a baseline of 3. The description adds semantic context that the jobId comes 'from search results,' which helps the agent understand parameter provenance, but does not elaborate on the jobHuntId parameter or provide format details 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 uses a specific verb ('Add') with clear resource ('job') and destination ('applications'), and adds context ('from search results'). It implicitly distinguishes from 'apply_to_job' by emphasizing 'save/track' rather than submitting, but does not explicitly name the sibling to clarify the distinction.

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

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

Provides clear positive guidance ('Use this when a user wants to save/track a job they found'). However, it lacks explicit negative guidance or named alternatives (e.g., 'do not use this to submit an application, use apply_to_job 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 of behavioral disclosure. While it states the tool 'submits' the form (indicating a write operation), it fails to disclose critical behavioral traits for an irreversible action: whether submission is final, if it consumes credits (relevant given the get_credits sibling), error handling, or side effects like confirmation emails.

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

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

The description consists of three well-structured sentences with zero redundancy. It front-loads the core action (trigger auto-apply), explains the mechanism (fill and submit), and ends with the optional parameter note. 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?

Given the high-stakes nature of job application submission (irreversible, potentially credit-consuming) and the absence of annotations or output schema, the description provides minimum viable context but has clear gaps. It does not explain the workflow relationship to add_job_to_applications, success/failure indicators, or cost implications that would be necessary for safe agent 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?

With 100% schema description coverage, the schema already comprehensively documents both the required 'id' parameter and optional 'resumeUri' parameter. The description references both ('application ID', 'specific resume') but adds no semantic meaning beyond what the schema provides, meeting the baseline for high-coverage schemas.

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

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

The description clearly states the tool 'Trigger[s] auto-apply for a job application' and specifies it 'automatically fill and submit the job application form.' This provides a specific verb+resource combination that clearly distinguishes it from sibling tools like add_job_to_applications (tracking) or update_application (modification).

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

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

The description implies usage by noting the optional resume parameter ('You can optionally specify a specific resume'), but provides no explicit guidance on when to use this tool versus alternatives like add_job_to_applications, or prerequisites such as whether the application must exist first. No exclusions or error conditions are 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?

With no annotations provided, the description carries the burden of behavioral disclosure, explaining the conceptual model that a job hunt 'defines what jobs you want to find based on titles, locations, skills, salary, etc.' It does not, however, disclose operational details such as whether creation consumes credits, if there are limits on the number of hunts, or what happens to existing hunts when creating a new one.

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

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

The description consists of three well-structured sentences that front-load the core action and progressively add context about the domain model and dependencies. Every sentence earns its place, with no redundant phrases or unnecessary elaboration, efficiently conveying the essential information within a compact space.

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

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

Given the complex nested configuration object and lack of output schema or annotations, the description adequately explains the domain concept and critical prerequisites for using sibling tools. It could be improved by mentioning operational constraints such as credit consumption for auto-applications or limits on concurrent job hunts, but it sufficiently covers the core functionality.

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

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

The input schema has 100% description coverage, documenting all filter parameters like 'titles,' 'locations,' and 'skills' in detail. The description provides high-level categorization of these parameters but does not add syntax details, format specifications, or semantic clarifications beyond what the schema already provides, meeting the baseline for high-coverage schemas.

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 provides a specific verb ('Create') and resource ('job hunt') and clarifies the purpose ('to start tracking and applying to jobs'). It effectively distinguishes this tool from siblings by establishing the prerequisite relationship: 'You need at least one job hunt to use match_jobs or add_job_to_applications,' which clarifies this is an initialization step before other operations.

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

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

The description provides clear context about when to use the tool by stating it is required before using 'match_jobs' or 'add_job_to_applications,' establishing workflow dependencies. However, it lacks explicit guidance on when NOT to use it (e.g., if a job hunt already exists) or direct references to 'update_job_hunt' as an alternative for existing hunts.

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 disclosure burden. It successfully documents the primary/alternate business logic constraint but omits critical behavioral details: whether deletion is permanent, what error response occurs if attempting to delete a primary resume, and whether this affects linked job applications.

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

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

Two sentences with zero waste: first states purpose, second states critical constraint. Information is front-loaded and 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?

For a single-parameter deletion tool without output schema, the description adequately covers the operation and key business rule. Minor gap regarding error handling behavior when constraints are violated, but sufficient 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% ('The resume ID (URI) to delete'), so the schema fully documents the single parameter. The description adds no additional parameter context, meeting the baseline expectation for well-documented schemas.

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 specific verb ('Delete'), resource ('uploaded resume'), and scope ('from your profile'). The additional constraint about primary vs. alternate resumes effectively distinguishes this from sibling operations like upload_resume_from_url or generate_resume_for_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?

Explicitly states the constraint 'You cannot delete your primary resume, only alternate resumes,' providing clear when-not-to-use guidance. However, it does not specify what alternative action to take if the user needs to remove their primary resume (e.g., uploading a replacement first).

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. It states the return format ('JSON resume data') and AI optimization behavior, but fails to clarify persistence (whether generated resumes are saved for later listing via list_generated_resumes), idempotency, or the conditional return behavior when generatePdf=true (which per schema returns a URL, not JSON).

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 with zero waste. Front-loaded with the core action (Generate AI-optimized resume), followed by mechanism (creates customized version), and output (Returns JSON). Every sentence earns its place without redundancy.

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

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

Adequate for a 5-parameter tool with no output schema: it discloses the return type (JSON). However, given the sibling ecosystem (list_generated_resumes, get_generated_resume), the description should clarify whether this tool persists generated resumes to the system or only returns ephemeral data. It also omits the dual-mode return behavior (JSON vs PDF URL).

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%, establishing a baseline of 3. The description adds minimal semantic value beyond the schema, though it loosely maps 'highlighting relevant skills' to the keywords/sections parameters and 'specific job application' to applicationId. No parameter syntax or format details are added.

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

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

Description provides specific verb ('Generate'), resource ('resume'), and scope ('tailored for a specific job application'). The 'AI-optimized' qualifier distinguishes it from sibling tools like upload_resume_from_url or get_resume, clearly positioning it as an intelligent generation tool rather than a simple CRUD operation.

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 by mentioning 'specific job application' (suggesting an applicationId is required), but lacks explicit when-to-use guidance. Does not clarify workflow relationship with add_job_to_applications (prerequisite) or contrast with get_generated_resume (retrieval of previously generated resumes).

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 description carries full disclosure burden. It explains the optional inclusion behavior (job listing details) but fails to mention error handling (e.g., invalid ID), caching behavior, or authorization scope (can any application ID be accessed?).

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 primary action. No redundant or filler text. The parenthetical '(description, salary, skills, etc.)' efficiently clarifies the optional parameter's impact without verbosity.

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 retrieval tool with complete input schema: describes the core operation and optional expansion. However, gaps remain regarding error behaviors, ownership constraints, and return structure (no output schema provided to compensate).

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

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

With 100% schema description coverage, the schema already fully documents both parameters. The description restates the ID requirement and optional flag without adding syntax details, validation rules, or examples beyond the schema. Baseline score appropriate for high-coverage schemas.

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 specific verb (Get) + resource (job application) + scope (by ID). Implicitly distinguishes from sibling 'list_applications' (single vs. list) and 'get_job' (application vs. job listing) through precise resource naming.

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 guidance on when to use this versus 'list_applications' (for bulk retrieval) or 'get_job' (for job details without application context). No prerequisites or error conditions 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 provided, so description carries full burden. Mentions return value ('contact info for reaching out') but omits safety profile (read-only vs destructive), error conditions, or rate limits. 'Get' implies safe read operation, but explicit confirmation would help 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 with zero waste. Front-loaded with core action and scope constraint, followed by return value description. 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 single-parameter getter tool with no output schema, the description adequately covers purpose, return content, and domain constraints (saved applications). Lacks only edge case handling and explicit safety guarantees.

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

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

Schema has 100% coverage with basic description 'The job application ID'. Description adds semantic context that this must be 'a job application you have saved', implying domain constraints and workflow state not explicit in the schema. Elevates above baseline 3.

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

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

Description uses specific verb 'Get' with resource 'recruiters' and qualifies scope with 'job application you have saved'. This clearly distinguishes from sibling get_job_recruiters (which targets jobs, not saved applications) and get_application_referrers (different contact type).

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 prerequisite that the application must be 'saved' (created/tracked), but does not explicitly state when to use this versus get_job_recruiters or get_application_referrers. No explicit when-not-to-use guidance provided.

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

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

With no annotations provided, the description carries the full burden and discloses that the tool 'Returns people at the company,' adding context about the return value. However, it omits other behavioral details like the hard limit of 2 results, error handling, or whether these are existing contacts or suggested strangers.

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

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

Two sentences with zero waste: the first states the action, the second states the return value. Every word earns its place and the description is appropriately front-loaded with the core verb.

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?

While the description covers the basic purpose and return type, the absence of an output schema and annotations means it should ideally provide more detail about the return structure (e.g., what fields are returned for these 'people') and behavioral constraints like the max 2 referrers limit.

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 fully documents both applicationId and limit parameters. The description does not add parameter-specific semantics (like explaining the limit's default/max of 2 or applicationId format), meeting the baseline expectation when schema coverage is high.

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

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

The description uses a specific verb ('Find') and resource ('referrers') and explicitly scopes it to 'a job application,' clearly distinguishing it from sibling tools like get_job_referrers (which operates on jobs) and get_application_recruiters (which finds recruiters rather than referrers).

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

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

The description provides implied usage context through the applicationId parameter and the phrase 'for a job application,' but lacks explicit guidance on when to use this versus get_job_referrers or prerequisites like having an existing application.

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 description carries full burden. Adds valuable performance context ('Much faster than paginating') and describes return data shape (counts by status, auto-apply metrics). However, lacks explicit safety confirmation (read-only), side effects, or rate limit disclosures expected for unannotated tools.

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

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

Two sentences, zero waste. First sentence defines purpose and return data; second provides explicit usage guidance. Efficiently front-loaded with critical selection criteria (aggregation vs. pagination).

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 2-parameter tool with no output schema, the description adequately explains what metrics are returned (counts by status, auto-apply metrics). Both parameters are optional (0 required) and well-documented in schema. Minor gap: could note that filters are optional, though this is discoverable in schema.

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 clear descriptions for both jobHuntId and dateOffset. Description mentions 'job applications' implying context but does not add syntax, format details, or parameter-specific guidance beyond what the schema already provides. Baseline 3 appropriate 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?

Specific verb (Get) + resource (aggregated stats for job applications) + detailed scope (total counts by status and auto-apply metrics). Explicitly distinguishes from sibling list_applications by contrasting aggregation vs. pagination.

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

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

Explicitly names alternative tool (list_applications) and explains when to use this instead (when you need aggregated stats rather than paginating individual records). Clear performance-based guidance ('Much faster').

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 it implies a read-only operation through the verb 'Get', it fails to specify whether data is real-time or cached, what specific usage metrics are included, or whether the operation is idempotent.

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

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

The description consists of a single, efficient sentence with no redundant words. The most critical information (balance and usage data) is presented immediately without 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?

Given the absence of an output schema, the description partially compensates by mentioning both 'balance' and 'usage information,' hinting at the return structure. However, for a financial/account tool with no annotations, it should specify what usage details are included (e.g., history, projections, limits) to be fully complete.

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

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

The input schema contains zero parameters, establishing a baseline score of 4. The description correctly implies no filtering or input is required to retrieve one's own credit information, which aligns with 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?

The description uses a clear verb ('Get') and identifies the specific resource ('credit balance and usage information'). It effectively distinguishes this tool from job-hunting siblings (like apply_to_job, get_application) by focusing on account/billing data rather than job search entities.

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

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

The description provides no guidance on when to invoke this tool (e.g., before submitting applications to check remaining credits) or prerequisites. It does not mention alternative ways to retrieve credit information or warn about potential rate limits.

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 description carries full burden. It compensates by disclosing return fields (codes, symbols, units) since no output schema exists. Implies read-only via 'Get' but doesn't explicitly state safety/idempotency characteristics.

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 total. First defines function, second defines usage context. Zero waste, perfectly 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 zero-parameter lookup tool without output schema, description adequately describes return structure and links to relevant sibling workflow (update_salary). Complete for its complexity level.

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?

Zero parameters present. Per scoring rules, 0 params = baseline 4. Description correctly requires no additional parameter explanation.

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

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

Description uses specific verb 'Get' with resource 'supported currencies' and details what data is returned (codes, symbols, units). Clearly distinguishes from job/resume 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?

Explicitly states when to use: 'before updating salary' which directly references the update_salary sibling tool, providing clear workflow 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 burden. It adds valuable context by disclosing the 'download URL' return value (critical since no output schema exists), but omits safety traits (read-only status), error behaviors (404 handling), or URL expiration details.

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

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

Single sentence, front-loaded with action verb, zero redundancy. Every word earns its place—'AI-generated' distinguishes from siblings, 'download URL' previews the payload.

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 single-parameter tool. Compensates for missing output schema by mentioning the download URL. Could improve by noting error cases (invalid ID) or that the ID typically comes from 'list_generated_resumes', but sufficient for 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 coverage is 100% with 'id' described as 'The generated resume ID'. The description implies the ID through 'specific' but adds no format details, examples, or constraints beyond the schema. Baseline 3 is appropriate 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?

Excellent specificity: uses 'Get details' (verb), identifies 'AI-generated resume' (distinguishing it from sibling 'get_resume'), and highlights a key return field 'download URL'. Clearly scopes the tool to retrieval of a specific resource type.

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

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

No explicit guidance on when to use versus siblings like 'list_generated_resumes' (list vs. get) or 'generate_resume_for_job' (create vs. retrieve). Lacks prerequisites (e.g., 'use after generating a resume').

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 description carries full burden. It discloses that the tool returns valid industry values (read operation), but lacks details on return format (array vs object), caching behavior, or freshness guarantees. Adequate but minimal for a read-only lookup 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 with zero waste: first states purpose, second provides usage context. Front-loaded with essential information and appropriately sized for a simple lookup 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 parameter-less lookup tool without output schema, description adequately explains what is returned and its intended use. Minor gap regarding return data structure (e.g., string array vs objects), but sufficient for an agent to invoke 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?

Input schema has zero parameters (empty properties object). Per rubric, 0 params equals baseline score of 4. No parameters require semantic elaboration.

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

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

Description uses specific verb 'Get' with clear resource 'list of valid company industries'. Explicitly distinguishes from sibling tools by clarifying this provides filter values for search_jobs, create_job_hunt, and update_job_hunt, establishing its lookup utility role.

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 explicit when-to-use guidance: 'Use these values for the "industries" filter in search_jobs, create_job_hunt, or update_job_hunt'. Names specific sibling tools where the output is consumed, creating clear operational 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 burden. It discloses what data is returned ('description, salary, skills, and company info') and clarifies the ID type constraint. Could explicitly state read-only/safety properties, but 'Get' and 'view' strongly imply non-destructive 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?

Three sentences with zero waste: sentence 1 defines core function and ID constraint, sentence 2 lists return fields, sentence 3 directs to alternative. Front-loaded with the essential action and resource identification.

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 single-parameter input and lack of output schema, the description fully compensates by enumerating the specific fields returned (description, salary, skills, company info) and clarifying the tool's scope relative to siblings. Complete for this complexity level.

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?

While schema has 100% coverage with 'The job ID', the description adds crucial semantic context that this is specifically a 'job listing ID (not application ID)', preventing confusion with the application ID parameter used in sibling tools like get_application.

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 specific action ('Get detailed information') and resource ('job listing/posting'). Explicitly distinguishes from sibling 'get_application' by noting 'not application ID', clarifying the domain boundary between job listings and applications.

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 explicit when-to-use guidance by specifying 'job listing ID (not application ID)'. Names the direct alternative 'get_application' for the contrasting use case of fetching application details rather than job posting details.

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 but merely states it retrieves details. It omits critical information such as error handling for invalid IDs, authentication requirements, or the structure and content of the returned details.

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

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

The description consists of a single nine-word sentence that is front-loaded with the action verb 'Get' and contains no redundant or extraneous information. However, it borders on under-specification given the lack of supporting annotations or output schema.

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

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

For a simple single-parameter retrieval tool, the description adequately identifies the core function. However, given the absence of annotations and output schema, it remains incomplete regarding return value structure, error states, and the specific attributes that constitute a 'job hunt'.

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?

Input schema has 100% description coverage with the 'id' parameter documented as 'The job hunt ID'. The description mentions 'by ID' but adds no additional semantic context, format constraints, or usage examples beyond what the schema already provides.

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

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

The description uses the specific verb 'Get' and identifies the resource as 'details of a specific job hunt', clearly indicating a retrieval operation. However, it does not explicitly differentiate from the sibling tool 'list_job_hunts' beyond implying a singular versus plural scope.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'list_job_hunts' or 'create_job_hunt'. It also fails to specify prerequisites, such as obtaining the job hunt ID from a prior list operation.

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 description carries full burden. It successfully discloses return content ('contact info including email and LinkedIn'), which compensates for the missing output schema. Implicitly indicates read-only behavior via 'Get', though lacks explicit safety markers or error conditions.

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

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

Two sentences with zero waste: first establishes purpose, second discloses return values. Perfectly front-loaded and appropriately sized for 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?

For a single-parameter read operation, the description is sufficiently complete. It compensates for the lack of output schema by specifying return fields (email, LinkedIn). Could be improved by mentioning read-only safety or error cases, but adequate for tool complexity.

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

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

Schema coverage is 100% (jobId fully documented), establishing baseline 3. Description references 'a specific job' which implicitly maps to the jobId parameter, but does not add syntax details or usage examples beyond what the schema provides.

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

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

Specific verb (Get) + resource (recruiters) + scope (who posted or are associated with a specific job). The phrase 'specific job' distinguishes this from application-scoped siblings like get_application_recruiters, and 'recruiters' distinguishes it from get_job_referrers.

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 implied usage context through 'specific job' phrasing, clarifying this operates on job entities rather than applications. However, it does not explicitly name sibling alternatives (e.g., get_application_recruiters) or state when to use this versus get_job_referrers.

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. It discloses that the tool accesses 'your network' to find matches and returns 'people,' indicating data access and return type. However, it omits critical behavioral constraints like the hard maximum of 2 results, what happens when no referrers are found, or whether this operation is read-only.

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

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

The description consists of two efficient sentences with zero waste. It is front-loaded with the core action ('Find potential referrers') and immediately follows with the return value and logic ('Returns people...').

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 lack of output schema, the description partially compensates by stating it 'Returns people.' However, it fails to describe the structure of those people objects or distinguish this tool from similar sibling tools. For a tool with no annotations, it should provide more behavioral context.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add semantic detail beyond the schema (e.g., it doesn't explain that jobId should come from search_jobs, or clarify the strict limit=2 constraint mentioned in the schema description).

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

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

The description clearly states the action ('Find potential referrers') and scope ('at a company for a specific job'). It distinguishes the resource (referrers vs recruiters) but does not explicitly differentiate from the sibling tool 'get_application_referrers', which could cause confusion about whether to use this pre-application or post-application.

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

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

The phrase 'for a specific job' implies usage when a job ID is known, hinting at the distinction from application-based referrer lookups. However, there is no explicit guidance on when to use this versus 'get_application_referrers' or prerequisites like requiring an imported job or existing profile.

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. It adds valuable context about the return payload structure (listing specific fields like skills and work history), but omits safety characteristics, caching behavior, or error conditions (e.g., unauthenticated access).

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

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

Single sentence with zero waste. Front-loaded with action verb and resource, followed by specific payload contents. Every word earns its place; no redundancy or filler.

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

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

For a zero-parameter read operation without output schema, the description adequately compensates by detailing the returned data categories. It misses only edge case handling or authentication requirements that would make it fully complete for a profile access 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 input schema contains zero parameters. Per calibration guidelines, 0 params establishes a baseline of 4. The description appropriately does not invent parameter semantics where none exist, focusing instead on the return value 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?

The description uses specific verb 'Get' with clear resource 'your user profile' and enumerates specific data categories returned (personal info, skills, experience, work history). It effectively distinguishes from sibling 'update_profile' through the read-only verb and from 'get_resume' by emphasizing profile/user data rather than documents.

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

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

The description implies usage context by specifying what data is retrieved, but lacks explicit when-to-use guidance or contrast with alternatives like 'update_profile'. No mention of prerequisites or conditions where this should be preferred over other data sources.

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. It adds value by specifying the inclusion of a 'download URL' in the response, but fails to indicate the read-only nature of the operation, potential expiration of URLs, or the effect of the includeRawTxt parameter.

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

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

The description is a single, efficient sentence that front-loads the action ('Get details') and immediately specifies the resource and key output. Every word serves a purpose with no redundancy or waste.

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

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

Given the tool's low complexity (two simple parameters, no nested objects) and absence of an output schema, the description adequately covers the essential return value (download URL). However, it could improve by briefly noting what 'details' entails or confirming this is a safe read 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?

With 100% schema description coverage, the baseline score applies. The schema fully documents both the required 'id' parameter and optional 'includeRawTxt' flag, so the description does not need to compensate. The description implies the ID requirement through 'specific' but adds no additional parameter 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?

The description clearly states the tool retrieves details of a specific uploaded resume and explicitly mentions the download URL output. The term 'uploaded' effectively distinguishes it from the sibling 'get_generated_resume', and 'specific' implies singular retrieval versus 'list_resumes', though it does not explicitly name these siblings.

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

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

The word 'specific' implies this tool requires a resume ID and is used for targeted retrieval rather than browsing (list_resumes), providing implicit usage context. However, there is no explicit guidance on when to choose this over get_generated_resume or error handling when the ID doesn't exist.

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 description carries full burden. Excellently discloses critical data interpretation behavior: INR values are in lakhs while others are in thousands. This prevents misinterpretation of magnitude (e.g., 20 vs 20,00,000). Implies read-only nature via 'Get', though could explicitly state it returns the authenticated user's data.

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

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

Two sentences with zero waste. First sentence establishes purpose and return structure. Second sentence front-loads 'IMPORTANT' to highlight critical unit conversion logic. 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?

Highly complete for a parameter-less read operation. Compensates for missing output schema by listing returned fields (base, stocks, bonus, total) and crucial unit semantics. Minor gap: could explicitly confirm it returns the calling user's own salary rather than arbitrary user data.

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

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

Zero parameters per schema (baseline 4). Description appropriately does not invent parameters, confirming this is a simple retrieval requiring no filters or IDs, likely operating on implicit authenticated user context.

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

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

Specific verb 'Get' + resource 'salary/compensation details' with clear scope (base, stocks, bonus, total). Clearly distinguishes from sibling 'update_salary' through the verb 'Get' and word 'current', indicating a read-only retrieval versus modification.

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

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

No explicit when-to-use guidance or named alternatives (e.g., doesn't mention when to use vs 'update_salary'). Usage is implied through the action verb and 'current' keyword, but lacks explicit workflow guidance or exclusion criteria.

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 description carries full burden. Discloses important side effect ('Optionally trigger auto-apply immediately') and scope (adds to applications). However, lacks disclosure of error handling, idempotency behavior, or what the tool returns on success.

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 well-structured sentences with zero waste. First sentence front-loads core functionality, supported platforms, and key optional behavior. Second sentence provides usage trigger. Every word earns its place.

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

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

Given 3 parameters with 100% schema coverage and no output schema, the description adequately covers the tool's purpose and side effects. Minor gap in not describing return values, but the core behavioral contract (import + optional auto-apply) is sufficiently complete for agent decision-making.

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%, establishing a baseline of 3. Description adds workflow context by mapping parameters to actions: connecting 'autoApply' to 'trigger auto-apply immediately' and 'jobHuntId' to 'add it to your applications,' enhancing understanding beyond raw schema definitions.

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?

Excellent specificity with 'Import a job from a URL' plus concrete platform examples (LinkedIn, Greenhouse, Lever, Workday). Clearly distinguishes from sibling 'add_job_to_applications' by emphasizing the URL-based import mechanism versus manual entry.

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 states 'Use this when a user has a direct link to a job posting,' providing clear activation context. However, it doesn't explicitly name the alternative (add_job_to_applications) for manual entry scenarios or mention when not to use it.

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

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

No annotations provided, so description carries full disclosure burden. Fails to mention pagination behavior despite page/limit parameters existing, return format, or sort order. 'Optionally filtered' is the only behavioral hint.

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

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

Single 9-word sentence efficiently front-loaded with action and resource. No redundant text. However, extreme brevity leaves gaps given lack of annotations and output 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?

Inadequate for a 4-parameter filtering/pagination tool with no output schema. Description omits pagination entirely, optional nature of all parameters, and relationship to jobHuntId sibling operations (create_job_hunt, get_job_hunt).

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

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

Schema has 100% description coverage, establishing baseline 3. Description mentions filtering by 'job hunt or status' conceptually, but adds no syntax details, format constraints, or semantic meaning beyond what parameter descriptions already provide.

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 specific verb (List) and resource (job applications) clearly. Plural form distinguishes from sibling get_application (singular), though explicit differentiation would strengthen it further.

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?

Mentions optional filtering capabilities but provides no guidance on when to use this versus get_application (single retrieval) or search_jobs (discovery). No prerequisites or exclusion criteria 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 provided, the description carries the full burden of behavioral disclosure. It successfully explains the domain concept (AI-generated, job-specific tailoring) but omits safety declarations (read-only status), pagination behavior, or return value structure that would be essential for a tool without 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?

The description consists of two efficient sentences with zero redundancy. The first sentence front-loads the action and resource, while the second provides necessary domain context. 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?

Given the tool's simplicity (2 optional parameters, no nested objects, no output schema), the description adequately covers the core concept. It could be improved by noting that parameters are optional filters or describing the return format, but it is sufficient for an agent to invoke the tool correctly.

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

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

The input schema has 100% description coverage for both parameters (manualTrigger and jobApplicationId). The description does not add parameter-specific guidance, but with complete schema documentation, it meets the baseline expectation without penalty.

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

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

The description uses the specific verb 'List' with the clear resource 'AI-generated custom resumes.' It effectively distinguishes from sibling tools like `list_resumes` (non-AI resumes) and `get_generated_resume` (single retrieval) by emphasizing the AI-generated nature and plural '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?

The description defines what generated resumes are ('automatically tailored for specific job applications'), providing implicit context for when to use this tool. However, it lacks explicit guidance on when to choose this over `list_resumes` or whether it should be used before/after `generate_resume_for_job`.

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 valuable behavioral context about data provenance ('detected from email confirmations') and explains the upcoming filter logic. However, with no annotations provided, it fails to disclose safety profile (read-only vs destructive), pagination behavior, or rate limiting.

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 well-structured sentences with zero waste. Front-loaded with purpose, followed by specific parameter hints. 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?

Adequate for a 5-parameter filtering tool with no output schema. Covers core functionality and data source, but missing safety assertions and return value description that would complete the picture given lack of 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%, establishing baseline 3. The description repeats schema information about upcoming/status filters without adding significant semantic depth (e.g., no format guidance for jobApplicationId or pagination strategy for page/limit).

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?

Clearly states the action ('List') and resource ('job interviews') with specific scope ('actively tracked by JobGPT', 'detected from email confirmations'). However, it does not explicitly differentiate from sibling tools like list_applications despite clear distinction in resource type.

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 implicit usage guidance through parameter examples ('Use upcoming=true', 'filter by application ID'), but lacks explicit guidance on when to select this tool versus alternatives or workflow prerequisites.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable context by noting the side effect of returning 'current credits balance' alongside the job hunts, which is not obvious from the tool name. However, it lacks details on pagination behavior, result ordering, or what occurs when no hunts exist.

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

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

The description consists of two efficient sentences with zero waste. The primary function is front-loaded in the first sentence, while the second sentence adds the secondary behavioral detail about credits. Every word earns its place.

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

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

Given the lack of output schema and annotations, the description should ideally sketch the return structure or list fields included in the job hunt objects. While it mentions the credits balance return, it leaves the agent uncertain about what properties each job hunt contains, creating a gap for a tool with no output schema documentation.

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

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

The input schema has 100% description coverage for both 'page' and 'limit' parameters. Since the schema fully documents the pagination mechanics, the description does not need to repeat this information. It meets the baseline expectation for high-coverage schemas.

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

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

The description states a specific action ('List') and resource ('your saved job hunts'), with a helpful parenthetical clarifying 'job searches'. The plural 'hunts' clearly distinguishes this from the singular sibling 'get_job_hunt', indicating this retrieves a collection rather than a single entity.

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?

While the plural form implies this is for retrieving multiple/all hunts versus the singular 'get_job_hunt', there are no explicit guidelines on when to use pagination, when to prefer this over 'search_jobs', or how to handle large result sets. The usage is implied but not 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 burden of behavioral disclosure. It fails to state that this is a read-only operation, lacks details on pagination behavior (despite page/limit parameters), and doesn't describe what the return payload contains or error conditions.

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

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

The description is a single, efficient sentence with no redundant words. It leads with the action verb and immediately clarifies the resource and scope, making it appropriately front-loaded.

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

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

For a simple listing tool with three optional parameters and no output schema, the description provides minimum viable context. However, given the absence of annotations and output schema, it should ideally mention the read-only nature or expected return format to be fully complete.

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

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

With 100% schema description coverage, the schema adequately documents all three parameters (page, limit, jobApplicationId). The description adds no parameter-specific context, but given the high schema coverage, the baseline score of 3 is appropriate.

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

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

The description provides a clear verb ('List') and resource ('outreach emails'), with specific scope ('sent to recruiters and referrers'). The past tense 'have been sent' effectively distinguishes this from the sibling tool 'send_outreach', though it doesn't explicitly name the 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?

The description offers no explicit guidance on when to use this tool versus alternatives like 'send_outreach' or 'get_application_recruiters'. While the past tense 'have been sent' implies this is for viewing history rather than sending new emails, it lacks explicit 'when-to-use' or 'when-not-to-use' instructions.

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 description carries full burden. It clarifies what data is returned (all uploaded resumes including primary and alternate versions), but omits behavioral details like pagination, rate limits, or response structure.

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

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

Two sentences with zero waste. Front-loaded with the action ('List your uploaded resumes') followed by scope clarification. 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?

Adequate for a simple read operation with one optional parameter and no output schema. The description explains the return value conceptually (all resumes including primary/alternate), though specific field details are absent.

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

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

Input schema has 100% description coverage for the single 'includeRawTxt' parameter. The description adds no supplementary parameter guidance, but baseline 3 is appropriate since the schema fully documents the optional boolean flag.

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 ('List') + resource ('uploaded resumes') clearly stated. Distinguishes from sibling 'get_resume' (singular vs plural) and 'list_generated_resumes' (uploaded vs generated) by specifying 'uploaded to your profile' and 'primary resume and any alternate versions'.

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 scope ('Returns all resumes') which implies when to use (when you need the complete set), but does not explicitly name alternative tools like 'get_resume' for single-record retrieval or contrast with 'list_generated_resumes'.

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 successfully discloses the critical deduplication logic ('only returns jobs you have not already seen, applied to, or rejected'). Minor deduction for not mentioning return format or idempotency characteristics.

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 well-structured sentences with zero waste: sentence 1 establishes purpose, sentence 2 details behavioral constraints (deduplication), and sentence 3 provides usage guidance. Information is appropriately front-loaded.

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

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

Given the absence of annotations and output schema, the description adequately covers the key business logic (deduplication) and workflow constraints. It appropriately omits return value details (per guidelines), though it could briefly mention that results are paginated.

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 conceptual context by linking jobHuntId to the 'saved job hunt configuration' mentioned in the first sentence, but does not need to elaborate further given the schema's completeness.

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 the specific action 'Get new job matches' and the resource 'saved job hunt configuration,' clearly distinguishing it from sibling tool search_jobs (which lacks the saved configuration constraint) and identifying the exact filtering mechanism used.

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 states the workflow prerequisite 'To change filters, use update_job_hunt first,' providing clear guidance on when NOT to use this tool and naming the exact alternative tool for filter modification, which prevents incorrect invocations.

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 but only states that it 'Returns a list'. It omits critical behavioral details: pagination limits, whether all filters are AND-based, response format/structure, rate limits, or caching behavior despite having 16 parameters.

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

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

The description consists of exactly two efficient sentences with zero redundancy. The first sentence establishes purpose and capability; the second establishes the return value. 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 complex 16-parameter search tool with no output schema and no annotations, the description is inadequate. It fails to describe the structure or content of the returned job postings, explain pagination behavior, or provide usage examples that would help an agent construct valid queries.

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%, establishing a baseline of 3. The description enumerates filter categories (titles, locations, etc.) that map to parameters, but adds no semantic depth beyond what the schema already provides (e.g., no guidance on filter precedence or optimal combinations).

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

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

The description clearly states the verb ('Search') and resource ('jobs'), listing specific filter categories available. However, it fails to explicitly distinguish this from sibling tool 'match_jobs', which likely uses different matching semantics (algorithmic vs. filter-based).

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?

While the description lists available filters, it provides no explicit guidance on when to use this tool versus alternatives like 'match_jobs' or 'get_job', nor does it mention prerequisites or when not to use it (e.g., when a job ID is already known).

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the email sends from 'configured email' (useful auth context), but fails to disclose critical mutation traits: that sending is irreversible, whether it creates a record viewable in list_outreaches, error handling behavior, or rate limits. For an email-sending operation, this is insufficient.

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

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

The description consists of exactly two sentences with zero waste: the first establishes purpose and scope, the second discloses sender configuration. Every word earns its place and critical 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?

Given this is a 4-parameter mutation tool with 100% schema coverage but no output schema, the description is minimally adequate. However, it omits important context about outcomes (success/failure indicators, whether an outreach record is created) that would help an agent understand the tool's effect on system state.

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 baseline is 3. The description adds minimal semantic value beyond the schema—it doesn't explain parameter relationships, formatting requirements for the body/subject, or provide examples. However, it doesn't need to compensate given the schema's completeness.

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

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

The description clearly states the specific action (send an outreach email), target audience (recruiter or referrer), and context (for a job application). It effectively distinguishes this from sibling tools like apply_to_job or get_application_recruiters by specifying this is the actual email sending 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?

The description implies usage context by mentioning recruiters/referrers, but provides no explicit workflow guidance such as when to use this versus other communication methods, or prerequisites like requiring contact IDs from get_application_recruiters. It remains functional but lacks strategic 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 provided, the description carries the full burden of behavioral disclosure but offers minimal details. It does not specify what the operation returns (success confirmation? updated object?), whether the update is atomic, if there are side effects, or whether changes are reversible. The term 'Update' implies mutation but lacks safety 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?

The description is a single, efficient sentence with no redundant words. However, given the lack of annotations and output schema, it may be overly terse—omitting critical behavioral details that would help an agent understand the full contract of the 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 mutation tool with no output schema and no annotations, the description is insufficient. It fails to disclose return values, error conditions (e.g., what happens if the ID doesn't exist), or whether partial updates are supported (can you update just status without notes?). The schema covers inputs well, but the description doesn't compensate for missing behavioral context.

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

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

With 100% schema description coverage, the baseline is appropriately 3. The description mentions 'status or notes' which aligns with the schema parameters, but adds no additional semantic context such as valid status transitions, formatting constraints for notes, or the fact that 'id' identifies the existing record to modify.

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

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

The description clearly states the action (Update) and target resource (job application) with specific fields (status or notes). It implicitly distinguishes from sibling read operations like get_application and creation operations like apply_to_job, though it could explicitly clarify this modifies existing records versus creating new ones.

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

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

No guidance is provided on when to use this tool versus alternatives like apply_to_job or add_job_to_applications. It fails to mention prerequisites (e.g., that an application must already exist, requiring the 'id' parameter) or when updates are appropriate versus other workflow actions.

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 description carries full burden. Critically discloses that config 'replaces the existing config (not a partial merge)'—essential behavioral trait for correct usage. Missing error handling or side effects on existing matches, but covers the primary 'gotcha' of this mutation 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?

Three sentences with zero waste: purpose statement, usage context, and critical WARNING about config replacement. Front-loaded with actionable information; 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?

Handles high complexity (8 params, deeply nested config object with 20+ fields) with no annotations. Covers the critical config replacement danger zone and read-before-write pattern. Absence of output schema means return values needn't be explained per rules.

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%, establishing baseline 3. Description adds crucial semantic meaning to 'config' parameter (full replacement vs merge) and contextualizes 'id' parameter via the prescribed get_job_hunt workflow. Elevates understanding beyond raw schema definitions.

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 specific verb 'Update' with clear resource 'job hunt settings and search filters'. Distinguishes from sibling 'create_job_hunt' by focusing on modification of existing hunts and 'change what jobs are matched'.

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 prescribes workflow: 'Use get_job_hunt first to see current config, then include all fields you want to keep.' Names specific sibling tool as prerequisite and clarifies the destructive replacement behavior vs. partial updates.

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 full burden for behavioral disclosure but fails to specify critical mutation semantics. Since all 5 parameters are optional, it doesn't clarify whether omitted fields are preserved (PATCH) or cleared (PUT), nor does it mention return values or side effects.

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

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

Extremely concise at only 4 words with no redundancy. However, brevity comes at the cost of insufficient detail for a mutation operation. Every word earns its place, but the sentence count is too low for 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?

For a mutation tool with 5 parameters, no annotations, and no output schema, the description is inadequate. It misses essential context: partial update semantics, what constitutes a valid profile update, and what feedback the user receives upon success or failure.

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

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

The schema has 100% description coverage (each of the 5 parameters is documented), establishing a baseline of 3. The description adds minimal value beyond the schema, merely noting 'fields' generically without explaining the optional nature of all parameters or their relationships.

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

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

The description states the basic action ('Update') and resource ('user profile fields') but remains generic. It distinguishes from 'get_profile' by verb choice, but 'fields' is vague given the schema contains 5 specific attributes, and it doesn't clarify scope versus siblings like 'update_application' or 'update_job_hunt'.

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 provided on when to use this versus alternatives. The sibling tool 'get_profile' exists for reading data, but the description doesn't mention when to update versus read, nor prerequisites like authentication requirements.

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. It successfully explains the critical domain logic of unit scaling (lakhs vs. thousands) which affects how all numeric parameters are interpreted, though it omits discussion of side effects or idempotency.

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 three-sentence structure is optimally front-loaded: purpose declaration, critical formatting warning with 'IMPORTANT' emphasis, and prerequisite tool reference. Every sentence earns its place with zero redundancy.

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

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

Given the 6 parameters and lack of annotations, the description successfully captures the essential domain complexity (currency unit handling). It appropriately references the lookup tool for the currency code parameter, though it could briefly acknowledge the update scope (e.g., 'your' profile).

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

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

The input schema has 100% description coverage, establishing a baseline of 3. While the description reinforces the unit conventions and references get_currencies, it largely synthesizes information already present in the schema fields rather than adding new semantic meaning.

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

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

The description clearly states the specific action ('Update') and resource ('salary/compensation details'), explicitly distinguishing this mutation tool from its sibling 'get_salary'.

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

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

The description provides explicit prerequisite guidance ('Use get_currencies to look up currency codes') and critical input formatting rules. However, it does not explicitly mention the read-only alternative (get_salary) or when not to use this tool.

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

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

With no annotations, the description carries the full burden. It discloses important side effects (profile sync by default) and constraints (5MB limit, PDF/DOC/DOCX only), but fails to mention the alternate resume behavior (isAltResume), return values, or error scenarios.

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 logically structured sentences cover purpose, technical constraints/examples, and default behavior/alternatives. Every sentence earns its place with zero redundancy.

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

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

Given the lack of annotations and output schema, the description adequately covers input requirements and side effects, but lacks details on return values or success/failure behavior that would make it fully complete.

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

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

While the schema has 100% coverage (baseline 3), the description adds valuable constraints not in the schema (5MB file size limit) and provides concrete URL examples (Google Drive, Dropbox, S3) that clarify the expected input format.

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

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

The description clearly states the specific action ('Upload a resume') and resource ('from a publicly accessible URL'), and distinguishes itself from direct profile uploads by mentioning the URL requirement and alternative path.

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

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

It provides clear guidance on when NOT to use the tool (if the user lacks a hosted URL) and directs to the profile upload alternative. However, it does not explicitly differentiate usage from sibling tools like generate_resume_for_job.

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