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. It only says 'Add' and 'save/track', without revealing side effects (e.g., whether duplicates are created), prerequisites (e.g., existing jobHunt), or return behavior. This is minimal disclosure for a mutation tool.

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

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

The description is two sentences, with the core purpose front-loaded. Every word earns its place, and there is no redundant information.

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

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

The tool is simple (2 parameters, no output schema, no nested objects). The description covers purpose and usage, but given no annotations, it omits behavioral details like idempotency, failure conditions, or what happens if the job is already added. This is adequate but with clear gaps.

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

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

The input schema already describes both parameters with 100% coverage ('The job ID to add to applications' and 'The job hunt ID to add this job to'). The description adds no additional parameter semantics, so the baseline of 3 is appropriate.

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

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

The description clearly states 'Add a job from search results to your applications', which specifies the verb, resource, and context. It distinguishes from sibling apply_to_job by emphasizing 'save/track', making the purpose unambiguous.

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

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

It explicitly says 'Use this when a user wants to save/track a job they found', providing a clear condition for use. However, it does not mention alternatives or exclusions, so it stops short of full guidance.

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

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

No annotations are provided, so the description carries full behavioral burden. It discloses the core action (fill and submit) but omits important traits: this is a write action with external side effects, likely irreversible, may consume credits (given get_credits sibling), and could fail silently. No reversibility, permission, or failure information is given.

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

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

Two sentences, front-loaded with the main verb. It is concise but slightly redundant: 'Trigger auto-apply' and 'automatically fill and submit' say essentially the same thing. Still, no waste and easy to scan.

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

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

For a 2-param tool with no output schema or annotations, the description covers the main action and optional resume parameter. However, it lacks context on mutation consequences like finality, credit usage, or success/failure reporting. Adequate but with clear gaps for an action with external side effects.

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

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

Schema has 100% coverage, providing baseline 3. The description adds extra value beyond schema: it explains where to get resumeUri ('from list_resumes or upload_resume') and the default behavior when it's not provided ('the primary resume will be used'). This enriches parameter understanding.

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

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

Description clearly states the tool triggers auto-apply for a job application, explicitly saying it 'will automatically fill and submit the job application form'. This specific verb+resource distinguishes it from siblings like add_job_to_applications or search_jobs.

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

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

Usage is implied: you use this when you want to auto-apply. However, it does not explicitly state when not to use it or contrast with alternatives like add_job_to_applications, nor does it mention prerequisites or side effects. Only resumeUri guidance hints at parameter sourcing.

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?

Since no annotations are provided, the description carries the full burden of behavioral disclosure. However, it only says 'Create a new job hunt' without mentioning side effects, permissions, idempotency, or return value behavior. It does not elaborate on what the creation implies beyond the definition, leaving a significant gap in transparency.

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

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

The description is three sentences, front-loaded with the primary action, then explaining the concept and prerequisite. Every sentence contributes to understanding the tool's purpose and usage without extraneous detail. This is concise and well-structured.

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

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

Given the tool's complexity (nested config object, multiple filter parameters), the description provides essential context about what a job hunt is and the prerequisite relationship with other tools. While it doesn't explain the config structure, the schema covers that in full detail. The description is sufficiently complete for its role, though it could optionally add notes about autoMode or credit consumption, but those are already in the 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 description coverage is 100%, so the schema already thoroughly documents all parameters. The description's mention of 'titles, locations, skills, salary, etc.' adds no new semantic information beyond what the schema provides. Thus, the baseline score of 3 is appropriate; the description neither detracts nor adds meaningful parameter detail.

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

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

The description uses the specific verb 'Create' combined with the resource 'job hunt', clearly stating the tool's purpose. It also differentiates from sibling tools by explaining that a job hunt is a prerequisite for match_jobs and add_job_to_applications, which provides context on how this tool relates to others.

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 for when to use this tool: when starting a new job hunt, and explicitly states that at least one job hunt is needed before using match_jobs or add_job_to_applications. It does not explicitly mention alternatives or exclusions, but the dependency information gives solid usage guidance.

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

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

With no annotations provided, the description carries the full burden. It adds one behavioral constraint (primary vs alternate), which is useful, but it does not disclose whether deletion is permanent, any side effects, or potential errors. The note about primary resumes is helpful, but more transparency (e.g., irreversibility) would be expected for a delete operation.

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

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

The description is a single concise sentence plus a brief note. Every word earns its place, and the key limitation is front-loaded. There is no fluff or repetition of schema information.

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

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

Given the tool's simplicity (one parameter, no output schema), the description covers the essential purpose and a critical usage restriction. It could mention the result or error behavior, but for a straightforward delete operation with the given context, it is reasonably complete.

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

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

The schema already describes the 'id' parameter as 'The resume ID (URI) to delete' with 100% coverage. The description adds meaning by implying the ID must be an alternate resume, not the primary one, which is a valuable constraint beyond the schema. Therefore it earns a 4, above the baseline of 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?

The description clearly states the action: 'Delete an uploaded resume from your profile.' It uses a specific verb and resource, and the additional note about primary vs alternate resumes clarifies the tool's scope, distinguishing it from resume upload/list/get tools.

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

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

The description gives explicit when-not guidance: 'You cannot delete your primary resume, only alternate resumes.' This tells users the tool is for alternate resumes only, providing clear context. However, it does not explicitly name alternative tools for deleting a primary resume, so it falls short of a 5.

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

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

No annotations are provided, so the description must disclose side effects itself. It states it 'creates a customized version' and 'Returns JSON resume data', but does not mention whether the resume is persisted, whether it overwrites an existing generated resume, or whether it consumes credits. This is a notable transparency gap for a generation tool.

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

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

The description is three concise sentences, each contributing value: the first states the core action, the second clarifies the customization aspect, and the third states the return format. No redundant or filler content is present.

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

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

The schema is rich and fully documents parameters, but with no output schema and no annotations, the description should clarify the return structure and side effects more thoroughly. It gives a high-level 'Returns JSON resume data' and 'creates a customized version', leaving the agent to infer persistence and exact output shape.

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

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

Schema description coverage is 100%, with each of the five parameters documented in the input schema. The description adds little beyond the schema, aside from the general notion of 'highlighting relevant skills and experience', which only loosely corresponds to keywords and sections. Baseline 3 applies.

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

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

The description uses a specific verb 'Generate' and identifies the resource as 'an AI-optimized resume tailored for a specific job application'. This clearly distinguishes it from sibling tools like get_resume or list_generated_resumes, and the phrase 'creates a customized version' reinforces the generation purpose.

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 use when a job-specific tailored resume is needed ('tailored for a specific job application'), but it does not explicitly state when not to use the tool or mention alternatives such as get_generated_resume or upload_resume_from_url. Usage context is present but exclusions are absent.

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 transparency burden. It states the read operation ('Get details') and the optional expansion, but does not disclose side effects (none expected), permissions, rate limits, or the default response structure. For a read-only getter, this is adequate but not comprehensive.

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

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

The description is two short sentences with no wasted words. It front-loads the core purpose and then adds the optional modifier. Ideal structure for a simple getter.

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

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

For a tool with 2 fully described parameters and no output schema, the description covers the essential functionality. Minor gap: it doesn't explain what fields are returned by default or how this relates to specialized getters (e.g., get_application_recruiters, get_application_stats). But the tool is simple enough that the description is nearly 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 descriptions cover 100% of parameters, so the description need not repeat them. It does add value by mapping 'by ID' to the id parameter and 'full job listing' to includeJobListing, but this is redundant with the schema. The baseline of 3 is appropriate.

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

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

The description clearly uses a specific verb ('Get') and resource ('details of a specific job application by ID'), distinguishing it from sibling tools like list_applications and specialized getters such as get_application_recruiters. The optional job listing detail adds further scoping.

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 context is clear: use when you have an application ID and need its details. It doesn't explicitly mention alternatives or exclusions, but the simplicity of the tool makes the usage obvious. The optional includeJobListing parameter implies when you want more than just base 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, the description must carry behavioral weight. It discloses that the tool returns contact info and requires a saved application, which is meaningful for a read-only getter. It doesn't detail permissions or side effects, but the 'get' prefix and return statement 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?

The description is a single, front-loaded sentence that states the action, scope, and return value without any redundancy. It is as concise as possible while remaining informative.

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

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

For a simple one-parameter getter with no output schema, the description is sufficiently complete: it specifies the prerequisite (saved application) and the output (contact info). No additional context is required for effective use.

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% for the single applicationId parameter, and the description does not add any further parameter details. The baseline of 3 applies since the schema fully documents the parameter.

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

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

The description clearly states the tool gets recruiters for a saved job application and returns contact info. It distinguishes itself from sibling tools like get_job_recruiters (for a job) and get_application_referrers (referrers, not recruiters).

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: use it when you have a saved job application and need recruiter contact info. It does not explicitly exclude alternatives like get_job_recruiters, but the phrasing 'for a job application you have saved' implies the appropriate scenario.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It indicates the return type ('people at the company') but does not explicitly state that it is read-only or disclose any other behavioral traits. The name 'get' and the word 'Returns' imply a read operation, but more detail could be added.

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 concise at two sentences, but there is slight redundancy between 'potential referrers' and 'people who might refer you'. It is front-loaded with the main purpose and remains efficient.

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

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

For a simple read tool with no output schema, the description adequately covers the purpose and high-level return value. It does not detail the exact structure of returned people, but this is not critical given the tool's simplicity. It is complete enough 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?

Schema description coverage is 100%, so the baseline is 3. The description adds minimal context by indicating the tool is for a job application, but it does not add meaningful parameter semantics 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 clearly states the tool's function: finding potential referrers for a job application. It uses a specific verb 'find' and a resource 'job application', and it distinguishes from sibling tools like get_job_referrers (for jobs) and get_application_recruiters (recruiters vs 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 clear context that this tool is for finding referrers associated with a specific job application. It does not explicitly mention alternatives or exclusions, but the context is clear enough for an agent to know when 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 are provided, so the description carries the full burden of behavioral disclosure. It explains the tool produces aggregated stats and is faster than list_applications, which is useful context. However, it does not describe the exact output structure, whether stats include all applications or only those matching optional filters, potential rate limits, or any freshness/real-time behavior.

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

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

The description is extremely concise—one sentence with two clauses. It front-loads the core purpose ('Get aggregated stats') and immediately adds distinguishing value ('faster than paginating'). No filler or redundant words.

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

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

Despite lacking an output schema, the description effectively conveys the main return information (counts by status and auto-apply metrics) and the performance advantage. With only two optional parameters and a straightforward aggregation use case, the description is largely complete. It could benefit from stating whether stats are real-time or cached, but this is a minor gap.

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

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

The input schema provides 100% description coverage for both parameters (jobHuntId and dateOffset), so the description adds no necessary parameter-level semantics. The baseline of 3 applies because the schema fully documents the parameters; the description's mention of 'auto-apply metrics' hints at what is aggregated but does not extend parameter meaning.

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

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

The description clearly states the tool's function: 'Get aggregated stats for your job applications' with specific detail on what it returns ('total counts by status and auto-apply metrics'). It also distinguishes itself from sibling tool list_applications by emphasizing aggregation rather than raw paginated data.

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

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

The description explicitly positions this tool against an alternative: 'Much faster than paginating through list_applications.' This gives clear guidance to use this tool when aggregate stats are needed rather than paginating through individual records, directly addressing selection between sibling tools.

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

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

With no annotations provided, the description must carry the full burden of behavioral disclosure. It conveys a read-only operation through the verb 'Get' and indicates the returned data (balance and usage), but it does not mention authentication requirements, rate limits, or whether the call itself affects the usage stats. For a zero-parameter getter, this is adequate but not thorough.

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

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

The description is a single, front-loaded sentence with no filler or redundancy. Every word contributes to conveying the tool's purpose.

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 tool with no output schema, the description covers the core purpose sufficiently. However, 'usage information' is somewhat vague and could benefit from listing specific fields (e.g., credits used, limit, reset date), so it is not a 5.

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

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

The tool has zero parameters, so the baseline is 4. The description appropriately does not add parameter-level detail since there are no parameters to document.

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

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

The description states the specific action 'Get' and the resource 'your current credit balance and usage information'. It clearly distinguishes from all sibling tools, none of which mention credits, making its purpose unmistakable.

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

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

The description implies the tool should be used when a user needs their current credit balance or usage information, but it does not explicitly state when to use it versus alternatives or when not to use it. Since no sibling tools overlap in functionality, the lack of explicit alternatives is not a major gap.

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

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

No annotations are provided, so the description must convey behavior. It discloses the returned data (codes, symbols, units) and implies a read-only operation via 'Get,' but it doesn't explicitly state safety, side effects, or require authentication details. For a simple list tool this is acceptable but not exhaustive, earning a 3.

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

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

The description is two concise sentences with no filler. It front-loads the primary action and follows with the usage context.

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

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

For a simple list tool with no output schema, the description sufficiently explains what is returned and why to use it. It ties to the update_salary workflow, making it contextually complete.

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

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

The tool has zero parameters, so the schema coverage is trivially 100%. The description doesn't need to explain parameters, and the baseline for 0-param tools is 4, which is earned here.

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 'Get the list of supported currencies' with specific details about codes, symbols, and units. This distinguishes it from sibling tools like get_industries or get_salary and ties to a specific use case (updating 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 context: 'Use this to look up the correct currency code before updating salary.' This tells the agent when to use it, although it doesn't explicitly say when not to use it or suggest alternatives, so a 4 is appropriate.

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

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

With no annotations provided, the description carries the burden. 'Get' implies a read-only operation, and the 'download URL' is disclosed. However, it does not describe side effects, error behavior, or required permissions. For a read tool, this is adequate but not enriched.

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

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

The description is a single, front-loaded sentence with no redundant words. Every element earns its place: the verb, resource, and a specific output detail.

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

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

For a simple read operation with one documented parameter and no output schema, the description sufficiently covers what the tool does and returns. It is complete enough for an agent to invoke correctly, though it could briefly describe the return format or error conditions without much cost.

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 sole parameter 'id' is already fully described in the schema ('The generated resume ID') with 100% coverage. The description adds no additional meaning beyond what the schema provides, so a baseline of 3 is appropriate.

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

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

The description clearly states the action ('Get details') and the specific resource ('AI-generated resume') with a key output ('download URL'). The qualifier 'AI-generated' distinguishes it from sibling tools like 'get_resume', and 'specific' differentiates it from 'list_generated_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 phrase 'Get details of a specific...' implies it is used when you have an ID and need individual resume details, but no explicit alternatives or exclusions are mentioned. It does not say when to use this over 'get_resume' or 'list_generated_resumes', so usage guidance is only implied.

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

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

With no annotations provided, the description carries the full burden. It discloses that the tool returns a list of valid company industries, but does not describe ordering, whether the list is exhaustive, or any authentication requirements. For a simple read operation, this is acceptable but minimal.

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

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

The description is two sentences, with the purpose stated immediately and the usage guidance in the second. No filler or redundant language.

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

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

The description is sufficient for a zero-parameter, no-annotation tool. It explains the purpose and how to consume the result. The absence of an output schema is mitigated by the phrase 'list of valid company industries,' which implies an array. However, it could optionally mention the data type.

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

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

The tool has zero parameters, and the schema is trivially covered. The description correctly focuses on the output usage rather than parameters, earning the baseline score for zero-param tools.

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 the resource 'list of valid company industries.' It also names the three consuming tools (search_jobs, create_job_hunt, update_job_hunt), which clarifies its role as a reference-data provider and differentiates it from sibling getters like get_currencies.

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 explicitly instructs to use these values for the 'industries' filter in three named tools, making the usage context clear. It doesn't explicitly state when not to use or provide alternatives, but none are needed for this reference list.

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

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

No annotations are provided, so the description must carry the behavioral disclosure burden. It does describe the operation as retrieving detailed job information and lists the types of data returned (description, salary, skills, company info), which implies a read-only operation. However, it does not explicitly state that the operation is non-destructive, nor does it address error cases, authentication requirements, or the full return structure. This is adequate for a simple get-by-id tool but leaves some behavioral aspects implicit.

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

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

The description is two concise sentences. The first sentence states the action and scope, the second provides usage guidance and an alternative. Every sentence adds value with no 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?

For a simple get-by-id tool, the description covers the purpose, the distinguishing parameter semantics, and the types of information returned in the absence of an output schema. It does not cover error handling or access prerequisites, but given the low complexity and the explicit mention of the return content, it is nearly complete. A small gap remains in not describing the exact response structure.

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

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

The single parameter 'id' is described in the schema as 'The job ID'. The description adds meaningful context by clarifying it is the 'job listing ID (not application ID)', which is critical for correct usage and prevents confusion with get_application's ID. This goes beyond the schema's terse 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 uses a specific verb ('Get') and resource ('detailed information about a specific job listing/posting'), explicitly scopes it by job listing ID (not application ID), and differentiates from get_application. It also lists the key fields returned, making the purpose unmistakable.

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

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

The description clearly states when to use this tool: to view full job posting details. It explicitly directs users to get_application for application details, providing an alternative. However, it doesn't mention other relevant alternatives like search_jobs for finding jobs without an ID, so it is clear but not exhaustive.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Get details' which implies a read-only operation, but it does not disclose error behavior, authentication requirements, ownership restrictions, or what data is included in the details. There is no extra contextual information beyond the obvious read nature.

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

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

The description is a single, efficient sentence with no filler or redundant words. It front-loads the action ('Get details') and the resource ('specific job hunt by ID'), making it immediately clear and appropriately sized.

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

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

Given the tool's simplicity (one parameter, no output schema, trivial purpose), the description is largely complete. It states the operation and the input requirement. However, it could be slightly more explicit about the expected return value (e.g., the full job hunt object), but this is a minor gap for such a straightforward getter.

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

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

The schema already provides 100% coverage for the single parameter 'id' with the description 'The job hunt ID'. The tool description adds no additional meaning beyond saying 'by ID', so it does not enhance the parameter semantics beyond what the schema already states. Baseline 3 is appropriate.

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

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

The description clearly states the verb 'Get' and the resource 'specific job hunt by ID', which distinguishes it from sibling tools like list_job_hunts (which lists multiple job hunts) and update_job_hunt (which modifies a job hunt). This leaves no ambiguity about the tool's function.

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

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

There is no explicit guidance on when to use this tool versus alternatives. While the phrase 'by ID' implies it is for retrieving a single job hunt, the description does not mention when not to use it or that list_job_hunts should be used for browsing multiple job hunts. No alternative tools are referenced.

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

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

No annotations are provided, so the description carries the full burden. It discloses the return shape ('contact info including email and LinkedIn') and the scope ('posted or associated'), which is useful. However, it does not mention permissions, rate limits, or potential limitations (e.g., missing contact info), so transparency is moderate.

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

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

Two sentences, front-loaded with the core action and scope, followed by return value detail. Every word earns its place; no redundancy or fluff.

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

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

For a simple one-parameter read tool with no output schema, the description covers the essential return info (contact details). It could clarify what 'associated with' means or indicate multiple recruiters per job, but the plural 'recruiters' and job-scope wording make it reasonably complete.

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

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

Schema coverage is 100% with jobId described as 'The job ID to find recruiters for'. The description reinforces that the job ID is used to identify the job but adds no additional syntax, format, or usage detail beyond the schema, meriting the baseline score.

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 ('Get') with a clear resource ('recruiters') and scope ('who posted or are associated with a specific job'). This distinguishes it from related tools like get_application_recruiters and get_job_referrers, especially given the tool's name.

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

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

The description implies the tool is for job-level recruiters, contrasting with application-level or referrer tools, but it does not explicitly state when not to use it or name alternatives. Provides clear context without exclusions.

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

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

With no annotations provided, the description carries the full burden. It explains what the tool returns ('people who might be able to refer you') and the basis for selection ('based on your network and the job'), which adds behavioral context beyond just the action. However, it does not mention that the operation is read-only, or disclose any limitations, privacy, or data source details, leaving some gaps.

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

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

The description is a single, focused sentence that begins with the verb and conveys the core purpose immediately. Every phrase adds value, with no redundancy or extraneous detail.

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

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

For a simple read-only tool with two parameters and no output schema, the description provides a clear high-level understanding of what is returned. It mentions the result type ('people') and the criteria, which is sufficient for an agent to invoke the tool. It does not detail the structure of the returned data, but that is not critical given the tool's simplicity.

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

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

The input schema provides complete descriptions for both parameters (jobId and limit) with 100% coverage. The tool description does not add extra meaning beyond the schema, other than reinforcing that referrers are found for a specific job. This matches the baseline for full schema coverage.

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

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

The description clearly states the action ('Find') and the resource ('potential referrers at a company for a specific job'). It distinguishes itself from sibling tools like get_application_referrers (which targets applications) and get_job_recruiters (recruiters rather than referrers) by specifying the exact scope.

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

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

The description implies the usage context ('for a specific job') and the network-based selection, but it does not explicitly state when to use this tool over alternatives, nor does it mention exclusions or prerequisites. For a simple read tool, the context is reasonably clear, but it lacks explicit differentiation.

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 must stand alone. 'Get' signals a read operation and the listed content indicates what will be returned, but it does not mention authentication, response shape, or any side effects. This is minimal but not misleading.

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

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

A single sentence front-loads the action and resource, and the trailing list of included data adds essential detail without waste. 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 absence of parameters and output schema, the description offers a reasonable summary of return content. It does not specify exact field structure, but for a simple self-profile getter this level of detail is sufficient.

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

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

The tool has zero parameters, so the baseline is 4. The description adds no parameter details, but none are needed because the input schema is empty and schema coverage is effectively complete.

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' with the clear resource 'your user profile' and lists contents (personal info, skills, experience, work history), making its purpose unambiguous and distinct from siblings such as update_profile or get_resume.

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

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

The description clearly implies this tool is for retrieving the caller's own profile data, which establishes clear usage context. It does not explicitly name alternatives or exclusions, but for a parameterless getter, the scope is obvious enough to guide selection.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It indicates a read operation and mentions the download URL, but does not elaborate on response shape, error behavior, or potential side effects. For a simple get, this is adequate but not rich.

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

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

The description is a single, front-loaded sentence with no filler words. It precisely conveys the tool's purpose without unnecessary detail.

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

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

The tool is simple with two parameters and no output schema; the description provides essential context (specific uploaded resume, includes download URL). It is complete enough for an agent to understand the tool, though it could mention the effect of includeRawTxt or response details, which are already covered by the 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%, so the parameters are well documented in the schema. The description adds no additional parameter-level meaning 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 clearly states the action (Get), the resource (details of a specific uploaded resume), and a key output (download URL). It distinguishes from siblings like get_generated_resume by specifying 'uploaded'.

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 'specific uploaded resume' conveys when to use this tool (single uploaded resume) and implicitly differentiates from generated resumes, but it does not explicitly name alternatives 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?

With no annotations provided, the description carries the full burden of disclosing behavior. It clearly explains the critical unit interpretation (lakhs for INR, thousands for other currencies), which is a key behavioral trait. It does not mention auth, rate limits, or return format, but for a simple getter this disclosure is substantial.

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 concise and front-loaded: the first sentence states the purpose, and the subsequent sentences provide essential unit-conversion context. Every sentence adds value with no redundancy or fluff.

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

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

Given the simplicity of the tool (no parameters) and the absence of an output schema, the description is complete enough. It states the expected content (base, stocks, bonus, total compensation) and elaborates on the important currency unit nuance, which is sufficient for an agent to understand the tool's behavior.

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

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

The tool has 0 parameters, so the schema coverage is trivially 100%. The baseline for 0 parameters is 4, and the description adds no parameter-specific details because none exist. No additional compensation is needed.

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

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

The description clearly states the tool retrieves current salary/compensation details including base, stocks, bonus, and total compensation. It uses a specific verb ('get') and resource ('salary/compensation'), and its purpose is distinct from sibling tools like update_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 implicitly indicates this tool is for reading salary data, and the name itself distinguishes it from update_salary. However, it does not explicitly state when to use this tool over alternatives or provide exclusions, so usage guidance is only implied.

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

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

With no annotations provided, the description discloses key side effects: adding the job to applications and optionally triggering auto-apply. It clearly signals that this is a mutating operation and highlights the auto-apply behavior, which is essential for the agent's understanding.

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

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

Two concise, front-loaded sentences. The first sentence states the action and destination; the second provides a usage condition. No wasted words.

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

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

Given the moderate complexity (3 parameters, no output schema, no annotations), the description covers the core purpose and key optional behavior. It does not describe the return value, but the main outcome (adding to applications) is clear and 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 description coverage is 100%, so the description does not need to explain parameter syntax. The description adds context for autoApply ('immediately') that maps to the parameter, but this is marginal. Baseline 3 is appropriate as the schema already documents parameters well.

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 exact action ('Import a job from a URL') and the destination ('add it to your applications'), with a specific verb and resource. It distinguishes from siblings like add_job_to_applications by focusing on the URL import mechanism and optional auto-apply.

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 an explicit usage context: 'Use this when a user has a direct link to a job posting.' This gives clear guidance on when to invoke the tool, though it does not explicitly mention alternative tools or exclusion cases.

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 only says 'List' which implies read-only, but does not mention pagination behavior, response format, rate limits, sorting, or whether any authorization is needed. It adds minimal value beyond the tool's name.

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

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

The description is a single, concise sentence that immediately communicates the core function and key optional filters. No wasted words, and it is front-loaded with the action verb 'List'.

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

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

The tool is a simple list operation with no output schema and no annotations. The description covers the main filtering options but does not explain pagination defaults, response structure, or what a successful response looks like. While the schema fully documents parameters, the lack of behavioral and output context leaves some gaps for a new agent.

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

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

The input schema has 100% description coverage, so parameters page, limit, status, and jobHuntId are fully documented. The description mentions the status and jobHuntId filters ('optionally filtered by job hunt or status') but adds no extra meaning beyond the schema. The baseline of 3 is appropriate since schema does the heavy lifting.

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

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

The description clearly states 'List your job applications' with a specific verb and resource, and explicitly mentions optional filters for job hunt or status. It distinguishes this from singular get_application and other application-related tools like add/update, making its purpose unambiguous.

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

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

The description implies the tool is used for listing applications with optional filters, but it does not explicitly state when to prefer this over alternatives such as get_application for a single record, or mention any prerequisites or exclusions. Context signals show sibling tools like get_application, but no guidance is provided in the description.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the domain and does not mention pagination, return format, ordering, authentication, or any side effects. The read-only nature is inferred from 'List' but not explicitly disclosed.

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

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

The description is two sentences with no filler. The first sentence is a clear front-loaded command, and the second sentence adds useful context about the resume type 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?

The tool is low complexity: two optional filter parameters fully documented in the schema, no output schema, and no nested objects. The description sufficiently explains the core purpose and domain, though it lacks any behavioral return details. Since the task is a simple list, this feels complete enough.

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

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

Schema description coverage is 100%, with both parameters ('manualTrigger' and 'jobApplicationId') self-explanatory in the schema. The description adds no parameter-level detail, but the schema fully covers semantics, so a 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 starts with a specific verb+resource combo: 'List AI-generated custom resumes.' It clearly distinguishes this tool from the sibling 'list_resumes' by adding 'AI-generated custom' and elaborates with 'automatically tailored for specific job 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?

The description implies usage by defining what AI-generated custom resumes are, which helps differentiate from list_resumes, but it does not explicitly provide when-to-use guidance or name alternatives. There is no direct comparison to sibling tools or mention of exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that interviews are detected from email confirmations and clarifies the semantics of upcoming=true, but it does not mention return format, pagination behavior, or any other operational details. Some useful context is added, but not comprehensive.

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

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

The description is two sentences, front-loaded with the core purpose, and each clause adds value. It is efficiently worded without redundancy, making it easy to parse quickly.

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

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

For a list tool with five optional parameters and no output schema, the description covers the core purpose, data source, and filtering semantics. It does not describe return values, but the tool name and list-oriented nature make this less critical. The absence of pagination details is mitigated by well-documented schema fields.

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

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

Schema coverage is 100%, so a baseline of 3 applies. The description adds meaning by explaining that upcoming=true returns scheduled/rescheduled interviews (matching the enum values for those statuses) and by summarizing filtering by application ID or status, going beyond a simple restatement of parameter names.

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

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

The description uses a specific verb ('List') and resource ('job interviews'), and clarifies the scope ('actively tracked by JobGPT'). It distinguishes this tool from sibling list tools by explaining the data source (email confirmations), making its purpose unambiguous.

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

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

The description provides clear usage context, explaining how to get scheduled/rescheduled interviews with upcoming=true and mentioning additional filters by application ID or status. It does not explicitly name alternatives or exclusions, but the context is sufficient for an agent to decide when to use this tool.

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

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

No annotations are provided, so the description carries the burden. It discloses that the tool lists job hunts and also returns the credits balance, which is a behavioral trait. However, it does not describe filters, sorting, or the exact response format, and it relies on the verb 'List' to imply a safe read operation.

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

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

Two compact sentences, immediately clear, with no filler. The first sentence states the primary purpose, and the second adds a useful side-effect. Highly efficient.

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

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

For a simple listing tool with well-described optional parameters and no output schema, the description is largely complete. It covers the main action and the credits balance, but could be more explicit about output structure or whether all saved job hunts are returned regardless of status.

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

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

Schema description coverage is 100%, with page and limit clearly documented. The description adds no extra information about parameters beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

States clearly 'List your saved job hunts (job searches)' — specific verb and resource, and differentiates from siblings like get_job_hunt or create_job_hunt. The additional mention of credits balance makes the full purpose unambiguous.

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

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

The purpose implies usage (to list all job hunts), but no explicit guidance contrasts it with alternatives like get_job_hunt for a single hunt. There is no mention of when or when not to use this tool relative to other listing tools.

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

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

No annotations are provided, so the description carries the burden. It adds useful scope details ('your', 'sent to recruiters and referrers') but does not disclose pagination behavior, filtering capabilities, or return format. The verb 'List' implies a read operation, but more detail would improve transparency.

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

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

The description is one concise sentence, front-loaded with the verb 'List' and immediately conveying the resource and scope. Every word earns its place with no 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?

For a simple list tool with three optional, well-documented parameters, the description provides adequate purpose and scope. It does not explain the return shape or mention the jobApplicationId filter, but the schema covers parameters and the tool's behavior is broadly inferable.

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

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

The input schema covers 100% of parameters with clear descriptions (page, limit, jobApplicationId), so the description does not need to add parameter details. The description adds no parameter-specific semantics, which is acceptable given full schema coverage.

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

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

The description uses the specific verb 'List' with a clear resource ('outreach emails') and scope ('your ... sent to recruiters and referrers'). It clearly distinguishes this tool from siblings like send_outreach and list_applications by focusing on sent outreach emails.

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

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

The description implies when to use the tool (when you need sent outreach emails) but does not explicitly state when not to use it or name alternatives. It lacks explicit contrast with sibling tools such as list_applications or send_outreach.

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 burden. It adds useful context by clarifying the scope ('your uploaded resumes' and 'primary/alternate versions'), but it does not mention potential side effects, authorization requirements, or response structure. For a simple read-only list tool, this is adequate but not rich.

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

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

The description is two concise sentences, front-loaded with the action ('List your uploaded resumes') and then elaborating on what is included. Every sentence earns its place with no fluff.

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

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

For a simple list tool with one optional parameter and no output schema, the description covers the essential points: what it lists, whose resumes, and that both primary and alternate versions are included. It lacks explicit details about return fields, but that is not critical given the 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?

The input schema covers the single parameter (includeRawTxt) with a description, so schema description coverage is 100%. The tool description adds no additional parameter semantics, which is acceptable since the schema already documents it.

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

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

The description clearly states the verb 'List' and the resource 'your uploaded resumes', and further specifies that it returns all resumes including primary and alternate versions. This distinguishes it from sibling tools like get_resume (singular) and delete_resume.

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 by noting it returns all uploaded resumes for the user's profile, implying this is the list-all equivalent. However, it does not explicitly mention alternatives or when not to use it, so it stops short of the highest rating.

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 responsibility for behavioral disclosure. It transparently states that the tool uses saved filters and excludes jobs already seen, applied to, or rejected, which is valuable behavioral context beyond the schema. It does not elaborate on error handling or response format, but for a read tool this is acceptable.

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

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

The description is two sentences, front-loaded with the core purpose, and the second sentence adds essential behavioral and usage details with no redundant filler. Every word earns its place.

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

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

The tool is a parameterized read operation with no output schema or annotations. The description adequately covers its purpose, filter source, exclusions, and the need to update the hunt separately. It does not describe the response structure, which could be helpful, but given the tool's straightforward nature and schema-covered parameters, the description is complete enough for effective use.

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

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

The input schema already covers all three parameters with clear descriptions (jobHuntId, page, limit). The tool description adds minor semantic value by explaining that jobHuntId points to a saved configuration with filters like titles, locations, skills, and salary, but does not significantly enhance the parameter understanding 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 clearly states the tool's function: 'Get new job matches based on a saved job hunt configuration.' It specifies the resource (job matches) and the mechanism (saved job hunt configuration), and distinguishes itself from sibling tools like search_jobs by emphasizing that it returns only unseen, unapplied, unrejected jobs using pre-saved filters.

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 usage context: use this tool when you want to retrieve job matches for an existing job hunt. It explicitly mentions the prerequisite of having a job hunt configured and instructs to use 'update_job_hunt' to make changes, offering an alternative for filter modification. However, it does not explicitly state when not to use the tool or contrast it with search_jobs.

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

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

With no annotations, the description carries the full burden but only states that it 'Returns a list of matching job postings.' It fails to disclose filtering combination logic, default behaviors (e.g., result ordering, limit), potential cost of broad searches, or any side effects. The description adds minimal behavioral context beyond the schema.

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

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

The description is two sentences, front-loaded with the core action, and contains no fluff or redundant information. Every word earns its place, and it clearly communicates the primary function and return type.

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

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

The tool has 16 optional parameters, no annotations, and no output schema. The description only provides a high-level summary and does not explain return format, result ranking, how filters interact, or any limitations. Given the complexity, the description is insufficient for an agent to fully understand the tool's behavior and result structure.

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

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

Schema description coverage is 100%, so the baseline is 3. The description lists example filter types ('titles, locations, companies, skills, salary, and remote options') but does not add new meaning beyond what the schema already provides. It accurately summarizes the parameter categories without detailed 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's purpose: 'Search for jobs with filters' and specifies the resource (jobs) and the action (search with filters). It is distinct from siblings like get_job and match_jobs, as it explicitly mentions a broad filter-based search and returns a list.

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

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

The description implies usage when searching for jobs but provides no guidance on when to use this tool versus alternatives like match_jobs or get_job. It doesn't mention exclusions, prerequisites, or scenarios where other tools would be more appropriate.

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

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

With no annotations, the description must carry the full burden of behavioral disclosure. It adds the detail that the email is sent from a configured email, but it does not disclose other important behaviors such as irreversibility, potential credit usage, or whether an outreach record is created (implied by the sibling list_outreaches). This is thinner than expected for a mutation tool.

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

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

The description is two succinct sentences. The first states the core purpose, and the second adds an essential behavioral detail. There is no fluff or redundant information.

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

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

The tool is simple with four fully documented parameters, but there is no output schema or annotations. The description omits return behavior, error conditions, and any side effects beyond sending. While the schema covers parameter semantics, the overall context of what happens after sending and any irreversible consequences is missing.

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

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

Schema description coverage is 100%, with each parameter described, including that contactId comes from specific endpoints. The description itself adds no additional parameter semantics, so the baseline of 3 is appropriate.

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

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

The description clearly states the action ('Send an outreach email'), the target ('to a recruiter or referrer'), and the context ('for a job application'). This is specific and distinguishes it from sibling tools like apply_to_job, which submits an application rather than sending an outreach email.

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 as part of the job application workflow ('for a job application') but does not explicitly state when to use this tool vs. alternatives or mention prerequisites. The schema clarifies that contactId comes from get_application_recruiters or get_application_referrers, but this is not in the description itself.

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 must carry the burden of disclosing behavior. It only says 'update' without mentioning whether fields are overwritten, what happens if the id doesn't exist, or if status values are validated. This is minimal disclosure for a mutation tool.

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

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

The description is a single, front-loaded sentence with no unnecessary words. It efficiently conveys the core purpose 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?

For a simple tool with three well-documented parameters, the description is minimally adequate. However, it lacks usage context and behavioral details like error handling or side effects, which an agent would need for confident invocation.

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

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

Schema description coverage is 100%, so the schema already documents each parameter. The description adds no new meaning beyond repeating 'status or notes' from the parameter descriptions, matching the baseline expectation.

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 the resource ('job application'), specifying the fields affected ('status or notes'). This distinguishes it from sibling tools like get_application (read) and apply_to_job (initial 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?

No guidance is provided on when to use this tool versus alternatives, such as whether it's appropriate for updating existing applications versus creating new ones. It lacks any exclusions or preconditions.

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

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

The IMPORTANT warning reveals that the config object replaces the entire config, not a partial merge—a critical behavioral trait not otherwise annotated. With no annotations provided, the description carries the burden of disclosing this destructive behavior. It does not mention all possible side effects like credit consumption for autoMode, but those are covered in the schema, and the key risk is clearly flagged.

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 three sentences long, each serving a distinct purpose: stating the purpose, issuing a critical warning, and giving a usage instruction. There is no redundancy or fluff; 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 complexity (8 parameters, nested config object), the schema handles parameter documentation thoroughly. The description adds the essential replacement warning and the GET-first workflow. It does not describe the response format, but no output schema exists and the description still provides enough context for a mutation tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by clarifying that the entire config must be passed and the agent should fetch the current config first, which is essential for correct parameter usage. This goes beyond what the schema's property descriptions state.

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 'Update job hunt settings and search filters' with a clear verb and resource, distinguishing it from create_job_hunt and get_job_hunt. However, it is slightly broad because the tool also updates status, autoMode, and other fields that are not strictly 'search filters', but the overall purpose is clear.

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

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

The description provides clear guidance: 'Use get_job_hunt first to see current config, then include all fields you want to keep.' It gives a practical prerequisite and warns about the full-config replacement. It does not explicitly state when not to use the tool or mention alternative tools for different operations, but the provided instruction is actionable.

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 provides minimal behavioral disclosure. It implies a mutation via 'update' but does not state effects, authorization requirements, or response behavior, leaving the safety profile unclear.

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

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

The description is a single concise sentence with no filler, and it is front-loaded with the verb. While it lacks specificity, it is efficient given that parameter details are in the schema.

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

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

Despite 15 parameters and no output schema, the description is one vague sentence that does not explain the return value or usage context. It lacks guidance on when to use it, what happens on success/failure, or how it relates to the rest of the profile workflow, making it incomplete for a mutation tool.

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

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

Schema description coverage is 100% with detailed descriptions for all 15 parameters, so the baseline is 3. The tool description adds no additional parameter semantics 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 clearly states the action (update) and resource (user profile fields), distinguishing it from siblings like get_profile or update_application. However, it lacks a specific scope beyond 'fields', leaving the exact target ambiguous without the schema.

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

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

No guidance is provided on when to use this tool versus alternatives such as update_application or update_job_hunt. It does not mention prerequisites, conditions, or exclusions.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It explains the unit convention, but does not disclose whether the update overwrites all fields, supports partial updates, requires specific permissions, or is reversible. For a mutation tool, this is a significant gap.

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

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

The description is compact, with the key action front-loaded. The 'IMPORTANT' flag draws attention to the critical unit convention. The second sentence is a bit dense but not excessive, and every sentence adds essential information.

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

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

With no output schema and no annotations, the description explains the main operational quirk (units) but does not address partial updates, whether all fields are optional (suggested by no required params), or what happens on success/failure. It is adequate for a simple update tool but leaves room for more 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 coverage is 100%, so baseline is 3. The description adds value by summarizing the unit convention with concrete examples ('20 for 20 lakhs', '400 for $400K') and explicitly pointing to get_currencies, which goes beyond the per-parameter schema descriptions.

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

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

The description clearly states the action ('Update') and the resource ('your salary/compensation details'), with a specific scope. It is unambiguous and distinct from sibling tools like get_salary or get_currencies.

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 usage context, especially the critical unit conventions for INR vs. other currencies, and explicitly instructs to use get_currencies for looking up codes. It does not explicitly state when not to use the tool, but the guidance is strong enough to direct correct usage.

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 the 5MB limit, default profile sync, and implies a mutating upload. It does not mention response behavior or error handling, but covers the key behavioral aspects sufficiently for an upload tool.

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

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

Three efficient, front-loaded sentences cover purpose, constraints, and alternative usage. Every sentence earns its place with no fluff or repetition of schema details.

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

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

The description explains the operation's scope, constraints, and fallback, but omits any mention of return values or success/failure indicators. Given the lack of output schema, a brief note on the expected response would make it more complete, but the current content is adequate for most use cases.

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 parameters are well-documented. The description adds a small note about default sync, but mostly reiterates schema content. Baseline 3 is appropriate since the schema does the heavy lifting.

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

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

The description clearly states the tool's function: 'Upload a resume from a publicly accessible URL.' It specifies the resource (resume) and the method (from URL), and distinguishes itself from sibling tools like delete_resume or generate_resume_for_job by focusing on ingestion from a URL.

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 guidance on when to use this tool versus alternatives: users without a hosted resume are directed to upload directly from their profile. It also states file type and size constraints, and mentions the default sync behavior, giving clear usage context.

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