JobGPT

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

No annotations are provided, so the description must carry the burden of behavioral disclosure. It identifies the operation as saving/tracking but does not disclose side effects, idempotency, preconditions (e.g., job must exist, job hunt must exist), or error behavior. This is minimal 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 long, front-loaded with the action, and contains no redundant or filler content. Every word earns its place.

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

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

For a tool with two required parameters and no output schema, the description plus schema provide sufficient context for most use cases. The main gap is the lack of details on side effects and preconditions, but given the tool's simplicity, the description 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 input schema provides full descriptions for both jobId and jobHuntId (100% schema coverage), so the baseline is 3. The description adds no extra parameter-specific meaning beyond what the schema already says.

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

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

The description clearly states the action: 'Add a job from search results to your applications.' It uses a specific verb and resource, and the context distinguishes it from siblings like apply_to_job (which implies actually applying) and list_applications (which lists existing 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 explicitly says 'Use this when a user wants to save/track a job they found,' providing a clear when-to-use scenario. It does not mention alternatives or when not to use it, but the usage context is unambiguous.

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 transparency burden. It discloses the core mutating behavior (filling and submitting the form) and the optional resume selection. However, it omits potential side effects such as credit consumption, irreversibility, or prerequisites like requiring an active job hunt.

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 primary action, and contains no redundant or filler information. Every word contributes to understanding the tool.

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

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

This is a simple action tool with two parameters, one required, and no output schema. The description adequately covers the action and the optional resume parameter, thanks to strong schema descriptions. It could be improved by noting required conditions or side effects, but it is sufficient for basic usage.

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

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

Schema coverage is 100%, and both parameters are well-described in the input schema. The tool description adds minimal extra meaning beyond the schema, only rephrasing the resume option without new details.

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 a specific action ('Trigger auto-apply') on a specific resource ('job application') and explains the mechanism (automatically fill and submit). This distinctly separates it from sibling tools like update_application or add_job_to_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?

It provides clear context that this tool is for automating a job application submission. However, it does not explicitly name alternative tools or state when not to use it, leaving room for the agent to infer based on the action.

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 states the tool creates a job hunt and its purpose, which is transparent for a create operation. However, it omits any side effects like autoMode consuming credits or that creation itself doesn't trigger applications unless configured. The schema covers these details, but the description doesn't add extra context beyond the obvious.

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 action, and every phrase earns its place. The first sentence states the verb and object, and the second explains what a job hunt is and its prerequisite role. 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?

Given the tool's complexity (nested config, many optional filters, no output schema), the description is minimal but adequate. It explains the core concept and prerequisite, but doesn't mention the default behavior of autoMode or that only titles is required in config. The schema fills these gaps, but the description alone would leave a user under-informed about the full scope.

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

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

Schema coverage is 100%, so the baseline is 3. The description mentions titles, locations, skills, salary, etc., mapping to config properties, but it doesn't add meaning beyond what the schema already provides. It provides a high-level summary but no new parameter relationships or usage tips.

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 creates a job hunt, which is a specific resource. It distinguishes from siblings like list_job_hunts, get_job_hunt, and update_job_hunt by implying this is the creation entry point. The phrase 'start tracking and applying to jobs' adds context on the resource's 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?

Explicitly mentions that you need at least one job hunt to use match_jobs or add_job_to_applications, providing a clear prerequisite and usage context. It doesn't explicitly contrast with update_job_hunt, but the creation role is unambiguous, so it earns a 4.

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 deletion is limited to alternate resumes, which is valuable behavioral context. However, it does not discuss the permanence of deletion, potential side effects, or any required permissions beyond the basic action.

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 action and followed by a necessary constraint. Every word earns its place; there is no fluff or redundant explanation.

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 delete tool with no output schema, the description is largely complete. It conveys the purpose and the key restriction. It could have mentioned how to obtain the resume ID (e.g., via list_resumes) or what happens after a successful deletion, but those are not strictly necessary.

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

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

The input schema has 100% description coverage for the 'id' parameter ('The resume ID (URI) to delete'). The description does not add extra meaning beyond the schema, 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 'Delete an uploaded resume from your profile' with a specific verb and resource. It distinguishes itself from sibling tools like list_resumes, get_resume, and upload_resume_* by focusing on deletion, and adds a key constraint about primary resumes.

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

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

The description implicitly tells when to use (to delete an uploaded resume) and explicitly gives a when-not scenario: 'You cannot delete your primary resume, only alternate resumes.' It does not name alternative tools, but the primary/alternate distinction is a clear usage boundary.

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 behavioral disclosure burden. It does state that it returns JSON resume data and uses AI optimization, but it does not mention any side effects, such as whether the generated resume is saved for later retrieval or if credits are consumed. This leaves some ambiguity for an agent.

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 a brief elaboration of behavior and output. Every word is useful, and there is 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?

The description adequately explains the tool's action and return type, but it does not cover the lifecycle of the generated resume. Given the sibling tools for managing generated resumes, it would be helpful to mention whether the output is persisted and can be retrieved later, which is a notable 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% coverage for all five parameters, so the baseline is 3. The description does not add any extra meaning or context about the parameters beyond what the schema already documents.

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 (generate), the resource (resume), and the specific context (tailored for a job application). This distinguishes it from sibling resume tools like get_resume or upload_resume_from_file by emphasizing generation and job-specific customization.

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 clear context for when to use the tool: when an AI-optimized resume tailored to a specific job application is needed. It does not explicitly exclude alternatives, but the purpose is unambiguous enough for an agent to select it appropriately.

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 the optional inclusion of job listing details, which is a behavioral aspect, but omits response shape, error behavior, and permission requirements. For a simple read operation, 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?

Single sentence with a clear front-loaded verb-resource structure. The optional flag is integrated compactly. Every sentence/word earns its place; 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 2-param simple getter with no output schema, the description is sufficiently complete. It implies a return of application details and covers the main variant (with/without job listing). Sibling tool names add context, though the description alone could clarify the return type explicitly.

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

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

Input schema covers both parameters with detailed descriptions (100% coverage). The tool description mentions 'full job listing' and 'etc.', adding little beyond the schema. 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?

Description uses specific verb 'Get' with resource 'specific job application by ID', clearly indicating a single-record read. It distinguishes from siblings like list_applications (list) and get_job (job listing), 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?

The phrase 'by ID' implies retrieval of one application, which distinguishes it from list_applications. It does not explicitly name alternatives or exclusions, but the context signals (sibling tools) and the optional includeJobListing parameter provide clear usage context.

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

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

With no annotations, the description carries the disclosure burden and does a solid job: it explains the alreadyContacted flag semantics, states that the operation fails with a not-found message when nobody is found, and advises retrying after a minute on lookup failure. It omits any auth/credit cost or rate-limit detail, which keeps it below a 5.

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

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

Three tight sentences with the core purpose and return contract front-loaded, followed by the flag semantics and failure behavior. The inline 'alreadyContacted ({date})' notation is slightly cryptic formatting, but no sentence is wasted.

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

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

There is no output schema, so the description must describe the return payload, and it does at a high level (contact info plus an alreadyContacted flag) along with both failure modes. It could say more about which contact fields come back, but nothing essential for calling it correctly is missing.

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

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

There is a single required parameter at 100% schema description coverage, so the schema already documents applicationId. The description only implicitly reinforces that the ID refers to a saved application; it adds no format or sourcing detail beyond the schema.

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

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

States a specific verb and resource ('Get the recruiter for a saved job application') and adds the scoping detail that the recruiter is matched to the role's function. It implicitly separates itself from the job-level sibling get_job_recruiters by scoping to a saved application, but never names the recruiter-vs-referrer distinction that separates it from get_application_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 phrase 'for a saved job application' and 'contact info for reaching out' implies the outreach use case, but there is no explicit when-to-use or when-not-to-use guidance. An agent must infer on its own why it would pick this over get_job_recruiters, get_application_referrers, or list_outreaches.

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 present, the description must carry the behavioral burden. It explicitly discloses operational constraints, such as failure modes ('not-found' vs. 'lookup fails') and the conditional logic used internally ('hiring_manager' when confident vs 'referral' otherwise).

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 dense paragraph, but every sentence contributes to the functional specification and operational constraints. While dense, it is efficiently written without unnecessary filler.

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

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

The definition is highly complete for a tool without annotations, as it covers the logic of retrieval, the specific failure modes, and the conditions governing the returned value.

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?

Although the provided schema does not include a `slot` parameter, the description provides vital semantic meaning by defining the tool's core branching behavior based on this distinction. This context helps an agent understand the underlying logic and limitations of the function.

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

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

The description provides a clear and nuanced purpose: finding specific individuals (hiring manager or peer) to ask about a saved job application. It effectively defines the tool's goal beyond a simple retrieval 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?

It provides excellent usage guidance by defining the condition for choosing one contact type over another (confident vs. peer). It also includes critical operational guidance regarding expected failure modes and retry logic.

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 a key behavioral trait: performance ('much faster than paginating') and the nature of the response (aggregated counts, auto-apply metrics). However, it does not mention potential side effects, permissions, or data freshness, which is a minor gap for a read-only aggregation 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 concise sentences. The first sentence front-loads the purpose, and the second adds a comparative advantage. There is no wasted words 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?

For a simple aggregation tool with two optional parameters and no output schema, the description provides a clear picture of what the tool does and when to use it. It mentions the kind of data returned (counts by status, auto-apply metrics) but does not detail the exact response structure, which is a slight gap given the lack of an output 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% for both parameters (jobHuntId and dateOffset), and both have clear descriptions in the schema. The tool description adds no extra parameter-specific context beyond the schema, so the baseline of 3 applies.

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

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

The description clearly states the tool's function: 'Get aggregated stats for your job applications — total counts by status and auto-apply metrics.' It uses a specific verb and resource, and explicitly distinguishes it from the sibling tool list_applications by emphasizing aggregated stats over paginated listing.

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 usage guidance: 'Much faster than paginating through list_applications.' This tells the agent when to choose this tool over an alternative, based on the need for aggregate data rather than individual records. It names the alternative and the performance benefit.

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 states the tool retrieves balance and usage information, implying a read-only operation, but it does not explicitly confirm safety, authentication requirements, or what 'usage information' includes. The verb 'Get' gives some hint, but more explicit transparency would be better.

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 is front-loaded with the verb and resource. It contains no extraneous words and communicates the essential purpose efficiently.

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

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

Given the tool's simplicity (no parameters, no output schema, no annotations), the description provides adequate context: it tells what data is returned. It could be slightly more specific about the nature of 'usage information' (e.g., time period, units), but for a simple balance getter, this 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 input schema is fully covered vacuously. The description adds context about what the result pertains to (credit balance and usage), but there are no parameter meanings to clarify. A baseline of 4 is appropriate for a no-parameter tool.

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

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

The description uses the specific verb 'Get' and clearly identifies the resource: your current credit balance and usage information. This distinguishes it from siblings like get_profile or get_salary, which target different resources.

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 when to use the tool: when you need to check your current credit balance or usage. While it doesn't explicitly mention alternatives or when not to use it, the context is unambiguous for a simple getter tool.

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

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

With no annotations, the description carries the full burden. It discloses the data returned (codes, symbols, units) and the intended workflow (pre-salary update), which is sufficient for a read-only list. It does not mention auth or rate limits, but those are unlikely to be concerns for a simple getter.

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 primary action and output. Every word earns its place; 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 zero-parameter, no-output-schema list tool, the description fully covers what the tool does and why to use it. It is complete for the agent's needs.

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

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

There are zero parameters, and schema coverage is 100% (empty schema). The description adds value by clarifying the purpose and output of the tool, which is more than the schema provides. Baseline for 0 params is 4.

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

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

The description states a specific verb ('Get') and resource ('list of supported currencies') with the details it returns (codes, symbols, units). It clearly distinguishes this tool from all sibling tools, none of which deal with 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?

Explicitly states when to use: 'Use this to look up the correct currency code before updating salary.' This gives a concrete scenario and implies no other tool needed for this purpose.

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

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

No annotations are provided, so the description carries the full burden. 'Get' implies a read-only operation, and the description adds the useful behavioral detail that the response includes a download URL. However, it does not disclose response format, pagination, or any other side effects, which is adequate for a simple get 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 wasted words. It clearly states the action and key output (download URL), making it 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 get operation with one parameter and no output schema, the description is largely complete. It mentions the download URL as a key detail, but 'details' is somewhat vague. Given the tool's simplicity, the description is nearly sufficient, with little missing.

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

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

The input schema has 100% coverage for the single required parameter ('id'), and the description aligns with it by referencing a 'specific AI-generated resume'. The description adds no additional semantic detail beyond what the schema already 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 uses a specific verb ('Get') and resource ('details of a specific AI-generated resume') and highlights the download URL. It clearly distinguishes from sibling tools like get_resume and list_generated_resumes by targeting AI-generated resumes specifically.

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 when to use this tool: when you need details of a specific AI-generated resume. However, it does not explicitly state when not to use it or mention alternatives, though sibling tools make this contextually obvious.

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?

There are no annotations, so the description carries the burden of behavioral disclosure. It indicates a read-only, list-returning operation ('Get the list') and the nature of the values ('valid'), but does not disclose details such as output format, sorting, or any potential pagination. For a simple, parameterless lookup, 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 sentences: the first states the primary purpose, the second explains where to use the values. It is concise, front-loaded, and every sentence earns its place 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?

This is a simple, parameterless lookup tool with no output schema. The description fully covers what the tool does and how to use the result in the broader workflow, making it complete for the tool's complexity and 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 tool has zero parameters, so the schema fully covers parameter semantics. The baseline for 0 params is 4, and the description adds contextual meaning by explaining how the returned values will be used as filter inputs in other tools, which is helpful beyond the empty schema.

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

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

The description clearly states the tool's function: 'Get the list of valid company industries' with a specific verb ('Get'), resource ('list of valid company industries'), and a clear domain distinct from sibling tools like get_currencies or get_profile. It defines exactly what is returned and the scope ('valid company industries').

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 on when to use the tool: to retrieve values for the 'industries' filter in search_jobs, create_job_hunt, or update_job_hunt. It names specific integration points, giving clear usage guidance, though it does not explicitly state when not to use the tool or mention alternative 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 full burden. It discloses that the tool returns full job posting details including description, salary, skills, and company info, and it clarifies the ID type (job listing ID vs application ID). It does not mention potential errors or permission requirements, but for a read-only get operation, the behavior is adequately transparent. Slight deduction for not stating that the job must exist or that it returns a single object.

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

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

Two sentences, zero fluff. The first sentence states the core purpose and the ID distinction. The second gives the alternative tool. The description is front-loaded and every sentence earns its place.

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

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

With no output schema, the description communicates what the response includes (description, salary, skills, company info). It also differentiates from get_application. It does not describe error behavior or authorization requirements, but for a simple get-by-id tool, this is a reasonably complete description. Slight gap: no mention of what happens if the ID is invalid.

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 only describes the parameter as 'The job ID'. The description adds crucial meaning by specifying it is the 'job listing ID (not application ID)', which resolves a likely ambiguity in a domain with multiple ID types. It also implies the ID should identify a job posting. This exceeds the baseline for high schema coverage.

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

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

The description clearly states the tool retrieves detailed information about a specific job listing/posting, naming the resource and the action. It explicitly distinguishes itself from get_application by specifying that it uses the job listing ID, not the application ID, which separates it from a key sibling tool.

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

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

It explicitly says 'Use this to view the full job posting details' and provides a direct alternative: 'For job application details, use get_application instead.' This gives clear when-to-use and when-not-to-use guidance with a named sibling tool.

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

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

With no annotations, the description carries full burden for behavioral disclosure. 'Get details' implies a read operation, but there is no mention of response contents, error/not-found behavior, or permission requirements. It adds minimal behavior context beyond the verb.

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

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

A single, concise sentence that is front-loaded with the action and resource. No filler or redundant phrasing.

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

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

For a simple single-parameter getter, the description is minimally viable but leaves the return 'details' unspecified. Without an output schema, it would benefit from naming at least a few example fields or stating it returns the full job hunt object.

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 'id' parameter, and the description repeats that the parameter is an ID without adding format, source, or usage details. The schema already provides the meaning, so 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 a specific verb ('Get') and resource ('details of a specific job hunt'), with the scope ('by ID') distinguishing it from list_job_hunts and other resource-specific getters like get_job.

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

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

The description implies usage when a known job hunt ID exists, but does not explicitly mention alternatives like list_job_hunts for finding IDs or contrast with update_job_hunt. Usage context is present but no exclusions or alternatives are named.

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 disclosure burden and does reasonably well: it names the returned contact fields (email, LinkedIn), documents the not-found failure mode, and advises retrying after a minute for transient lookup failures. It stops short of stating permission/auth requirements or explicitly confirming the operation is a read-only lookup.

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

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

Three tight sentences, front-loaded with purpose and followed by return contents and failure behavior; nothing is redundant. The phrase 'matched to the role's function' is slightly vague but still earns its place as scoping information.

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

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

For a one-parameter read tool with no output schema, the description covers return contents, error behavior, and retry semantics, which is what an agent needs to call it and interpret results. Minor gaps (auth context, whether multiple recruiters can be returned) keep it from 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?

Schema coverage is 100% with a single required 'jobId' already documented, so the baseline is 3. The description adds only the notion of matching the recruiter to the role's function, which hints at selection logic but not at anything jobId-specific beyond what the schema says.

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

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

States a specific verb and resource ('Get the recruiter for a specific job') plus the scoping detail that the recruiter is matched to the role's function. It implicitly distinguishes itself from the application-scoped siblings (get_application_recruiters) by saying 'for a specific job', but never names those alternatives explicitly.

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

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

Provides useful operational guidance about failure and retry, but gives no explicit when-to-use comparison against close siblings like get_application_recruiters, get_job_referrers, or get_application. The agent must infer that this tool is for job-level recruiter lookup rather than application-level.

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

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

With no annotations, the description carries the full burden and does well: it discloses the confidence-based selection logic, a not-found failure mode, and retry advice on transient lookup failure. It omits auth/permission requirements and what a successful response contains, keeping it from a 5.

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

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

Two tight sentences, front-loaded with the tool's core purpose before the failure/retry caveats. Dense but every clause is relevant, though the ambiguous 'slot' clause adds confusion rather than value.

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?

Covers failure modes and retry behavior for a small two-parameter tool, which is meaningful given no output schema or annotations. However, it never explains what contact information is returned or what 'limit' governs, and the phantom 'slot' parameter leaves the contract unclear.

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 jobId and limit are already documented, and the description adds nothing about limit. Worse, it references a 'slot' argument ('hiring_manager' or 'referral') that does not exist in the input schema, which can mislead an agent into passing an unsupported 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?

States a specific verb and resource: find referrers (who to ask) for a given job, with a clear hiring-manager-vs-peer distinction. It does not differentiate from close siblings like get_job_recruiters or get_application_referrers, so it stops short of a 5.

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

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

Usage is implied through the hiring-manager/peer fallback logic and a retry hint on lookup failure, but there is no explicit guidance on when to prefer this tool over the sibling recruiter/referrer tools. The agent must infer selection from names alone.

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

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

No annotations are provided, so the description carries the full burden. It states the action and content but does not explicitly confirm read-only behavior, authentication requirements, or absence of side effects. The word 'your' implies scope but is not explicit about 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, concise sentence that front-loads the verb and resource. Every word contributes meaning 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?

The tool has no parameters and no output schema, so the description must explain return content. It lists four content categories, which gives a reasonable picture. However, it could mention whether the response includes any additional metadata or format, but for a simple profile getter this is adequate.

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 coverage is 100% (vacuously). The baseline for 0 parameters is 4, and the description adds no unnecessary parameter information, which 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) and the resource (user profile), and lists specific content areas (personal info, skills, experience, work history). This distinguishes it from sibling tools like update_profile and get_job.

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

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

The description implies usage for retrieving the user's profile but does not explicitly contrast with alternatives like update_profile or mention when not to use it. No exclusions or alternative tool references are provided.

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

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

With no annotations provided, the description must carry the full burden of behavioral disclosure. It only says 'Get details' and mentions the download URL, but does not disclose that includeRawTxt controls raw text inclusion, any auth/permission requirements, or the nature of 'details'. The optional parameter behavior is left entirely to 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 a single concise sentence that front-loads the action and resource. Every word earns its place, with no redundant information or filler.

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

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

This is a simple get operation with full schema coverage for parameters. The description mentions the download URL as a key return value, but does not explain the includeRawTxt behavior or what other 'details' are included. Given the absence of an output schema, a bit more detail would improve completeness, but the description remains minimally viable.

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

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

The input schema already provides descriptions for both parameters (id, includeRawTxt) with 100% coverage. The description adds no additional meaning beyond the schema, 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 a specific verb ('Get') and resource ('details of a specific uploaded resume'), and highlights a key output (download URL). It distinguishes from siblings like list_resumes (listing multiple) and get_generated_resume (generated resumes), making the tool's 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 no guidance on when to use this tool vs alternatives such as list_resumes or get_generated_resume. No exclusions, prerequisites, or contextual cues are given, leaving the agent to infer usage solely from the name.

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

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

With no annotations provided, the description carries the responsibility for behavioral disclosure. It reveals a critical non-obvious behavior: INR values are in lakhs and other currencies in thousands. This adds significant transparency beyond a generic 'get salary' description and helps the agent interpret results correctly.

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 well-structured: the first sentence states the primary purpose, and the second sentence provides an essential, clearly marked IMPORTANT note about currency units. Every sentence serves a purpose 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?

Given there is no output schema, the description must explain the return structure and any non-obvious formatting. It does both by listing components (base, stocks, bonus, total compensation) and explaining the unit convention for INR versus other currencies. This is complete for a zero-parameter read tool.

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

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

The input schema has zero parameters, so the baseline is 4. The description does not need to explain parameters; instead, it adds value by clarifying output unit semantics, which is indirectly helpful for understanding the tool's behavior even though it is not parameter-specific.

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 'your current salary/compensation details including base, stocks, bonus, and total compensation.' This distinguishes it from siblings like update_salary, which handles modifications, by the explicit 'Get' verb and resource specification.

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

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

No explicit guidance is given about when to use this tool versus alternatives. The verb 'Get' implies read-only usage, but the description does not mention update_salary or provide any 'use instead' language. The currency interpretation note is useful for data handling but does not address tool 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 disclosing behavioral traits. It mentions the main side effect: 'Optionally trigger auto-apply immediately', which is important. However, it lacks details about handling duplicate jobs, error conditions, or permission requirements.

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

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

The description is two sentences, front-loaded with the main action, and has zero waste. Every phrase serves a purpose: what it does, supported examples, optional side effect, and when to use.

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

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

For a simple 3-parameter tool with 100% schema coverage, the description adequately covers the main workflow and use case. It doesn't explain return values, but since no output schema exists, the core functionality and trigger conditions are sufficiently described.

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 mild value by clarifying that the URL is a direct link to a job posting and that autoApply is optional, but it doesn't add syntax or format details beyond the schema.

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

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

The description clearly states the specific action: 'Import a job from a URL' and 'add it to your applications', distinguishing it from siblings like add_job_to_applications that don't use URLs. The mention of supported platforms (LinkedIn, Greenhouse, etc.) adds specificity.

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 a clear usage context: 'Use this when a user has a direct link to a job posting.' It doesn't name explicit alternatives or exclusions, but the context is sufficient for an agent to know when this tool 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?

No annotations are provided, so the description carries the full burden. It states it lists applications but gives no details on authentication, response format, pagination defaults, or sorting behavior. The 'list' verb implies a read operation, but no safety or behavioral context is 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?

A single, efficient sentence with no redundant content. It front-loads the action and resource, and the filter options are stated compactly.

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 adequate for a simple list tool, but without annotations or an output schema, it lacks details about return structure and default pagination behavior. The schema covers parameter documentation, so the tool is callable, but an agent might not know what fields are in the response.

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 all four parameters (page, limit, status, jobHuntId) documented in the schema. The description adds a concise summary of filtering by job hunt or status but does not introduce 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 tool lists job applications and mentions optional filters by job hunt or status. However, it doesn't explicitly distinguish from sibling tools like get_application or list_interviews, though 'list' implies collection.

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 given on when to use this tool versus alternatives such as get_application or list_interviews. No exclusions, prerequisites, or alternative tool references are provided.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It adds context about the resume type (AI-generated, tailored for specific job applications), but does not describe return format, pagination, or other behavioral traits. It does not contradict any annotations.

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

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

The description is two sentences, front-loaded with the verb and resource, and the second sentence clarifies the tool's scope without redundancy. 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 description does not differentiate this tool from the sibling list_resumes, and with no output schema, it lacks information about the return structure. The schema covers filters, but the overall context is incomplete for an agent to choose correctly.

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

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

The input schema describes both optional parameters (manualTrigger and jobApplicationId) with 100% coverage, so the baseline is 3. The description adds nothing about parameters, but the schema is sufficient.

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 ('List') and the resource ('AI-generated custom resumes'), and explains that these are automatically tailored for job applications. This distinguishes it from the sibling tool list_resumes, which likely lists all resumes.

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

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

The description implies usage context by defining the resume type ('AI-generated custom resumes' tailored for job applications), but it does not explicitly say when to use this tool versus alternatives like list_resumes, nor does it provide exclusion criteria.

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

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

No annotations are provided, so the description carries the burden. It discloses that the data is sourced from email confirmations and that only 'actively tracked' interviews are listed. The verb 'list' implies a read-only operation, which is further supported by the non-mutating tone. It does not detail side effects or permissions, but for a list tool this is acceptable. It adds useful context about the data source.

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 exactly two sentences, front-loaded with the primary action ('List job interviews'), and every clause adds value: data source, active tracking, and parameter usage. No filler or 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 has 5 parameters and no output schema. The description covers the data source, the primary filter semantics, and the tracking scope. It does not describe the return format, but for a simple listing tool this is a minor gap. The parameter schema handles the input details comprehensively, so the description is adequate for the tool's complexity.

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

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

Schema description coverage is 100%, so parameters are already well-documented. The description adds a usage hint for 'upcoming=true' and mentions filtering by application ID or status, but these repeat the schema's descriptions rather than adding new meaning. The baseline of 3 applies; no extra value beyond the schema is provided.

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 begins with a clear verb+resource: 'List job interviews'. It further specifies that interviews are actively tracked by JobGPT and detected from email confirmations, which clearly distinguishes this from sibling tools like list_applications or list_outreaches. No ambiguity.

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

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

The description provides explicit usage guidance: 'Use upcoming=true to get scheduled/rescheduled interviews' and 'Can also filter by application ID or status.' This tells the agent when to use specific parameters. It doesn't exclude alternatives, but there is no competing interview-listing tool among siblings, so the context is sufficient.

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 clearly indicates that this is a read operation ('List') and mentions the additional credits balance. However, it does not disclose details like pagination behavior, ordering, or whether any side effects occur. The behavior is straightforward, but additional context could be helpful.

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, immediately stating the main purpose and then the additional credits balance. No filler or redundant information. It is well-structured and front-loaded.

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

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

For a simple list tool with two optional parameters and no output schema, the description is sufficiently complete. It states the primary return (job hunts) and the secondary return (credits balance), covering the essential information. It could mention pagination details, but these are not critical for this straightforward operation.

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

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

The input schema already provides descriptions for both parameters (page and limit), achieving 100% coverage. The tool description adds no further parameter details, so the baseline score of 3 is appropriate. The schema adequately explains the purpose and defaults for each 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's function: listing saved job hunts, with a specific verb and resource. It also adds the secondary function of returning the credits balance. This distinguishes it from siblings like get_job_hunt and create_job_hunt.

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

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

The description implicitly conveys when to use this tool: whenever you need to list your saved job hunts. It does not explicitly exclude alternatives, but the context is clear. Sibling tools like get_job_hunt imply a more targeted use case, though no direct comparison is made.

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 burden. It discloses that only sent emails are listed, which is a useful scope constraint. However, it does not mention pagination behavior, return format, or explicitly confirm read-only status beyond the verb 'list'.

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

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

The description is a single, front-loaded sentence that conveys the action and resource without any unnecessary words. It 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?

For a simple list tool with all parameters documented in the schema, the description adequately states the resource and scope. It lacks explicit return-structure details, but the absence of an output schema makes this a minor gap rather than a critical omission.

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?

All three parameters (page, limit, jobApplicationId) are fully described in the schema with defaults and meaning, so the schema provides 100% coverage. The description adds no additional parameter semantics, so the baseline score of 3 is appropriate.

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

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

The description explicitly states 'List your outreach emails that have been sent to recruiters and referrers,' using a clear verb ('List') and specific resource ('outreach emails'). It distinguishes itself from siblings like send_outreach by focusing on retrieval, and from other list tools by targeting outreach-specific 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 clearly implies this is for viewing sent outreach emails, which is distinct from sending them (send_outreach). It doesn't explicitly name alternatives or exclude other contexts, but the resource type is unambiguous, so the usage context is clear.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does reveal that the tool returns all uploaded resumes including primary and alternates, but it does not mention authentication requirements, pagination, or the effect of the includeRawTxt parameter on response size/content.

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 long, front-loaded with the action 'List your uploaded resumes,' and contains no redundant or unnecessary information. Every phrase contributes meaning.

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

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

This is a simple list tool with one optional boolean parameter, and the description adequately states the scope (all uploaded resumes) and output intent (returns resumes). It lacks a contrast with list_generated_resumes and does not describe the response format, but given the low complexity, this is fairly complete.

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

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

The input schema fully documents the only parameter includeRawTxt with a default value, so the schema_description_coverage is 100%. The description adds no additional parameter-level meaning, so the baseline score of 3 is appropriate.

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

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

The description opens with 'List your uploaded resumes,' which is a specific verb-resource pairing. It further clarifies scope by including 'primary resume and any alternate versions' and uses 'uploaded' to distinguish from the sibling 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 description clearly implies use when the caller needs a list of uploaded resumes, but it does not explicitly name alternatives or state when not to use it. Given the sibling list_generated_resumes, a direct contrast would have made the guidance more explicit.

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

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

With no annotations, the description carries the full burden. It discloses important behavioral traits: it uses saved job hunt filters (titles, locations, skills, salary, etc.) and returns only jobs not already seen, applied to, or rejected. This adds value beyond the tool name. It doesn't mention pagination or error handling, but the core behavior is well covered.

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 primary purpose. The second sentence adds key behavioral details and a pointer to update_job_hunt. There is no redundant or extraneous text.

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

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

Given no output schema and no annotations, the description sufficiently explains the tool's function, filtering behavior, and prerequisite for changing filters. It implies a list return ('only returns jobs'), which is clear enough for an agent. It does not explicitly state return format or edge-case behavior, but for its complexity it is fairly complete.

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

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

The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds some contextual info (e.g., that jobHuntId references the saved configuration with filters), but it does not meaningfully extend the schema's parameter descriptions. No additional semantics are 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's purpose: 'Get new job matches based on a saved job hunt configuration.' It uses a specific verb ('Get') and names the resource (job matches tied to a job hunt). It distinguishes from siblings like search_jobs by referencing the saved configuration and the filtering of already seen/applied/rejected 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?

It gives clear context for when to use the tool (when you want new matches from a saved job hunt) and explicitly points to update_job_hunt for changing filters. However, it does not explicitly state when not to use it (e.g., for ad-hoc searches, use search_jobs), so it lacks a bit of alternative guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that it 'Returns a list of matching job postings' but does not mention pagination behavior, default response sizes, potential rate limits, or the fact that no filters will return all jobs. The schema documents page and limit parameters, but the description does not clarify how they affect behavior, leaving significant behavioral traits undisclosed.

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 that efficiently state the purpose and the return type. There is no filler, redundancy, or unnecessary detail. Every phrase ('Search for jobs with filters...', 'Returns a list...') serves a clear communicative purpose, making it appropriately sized and front-loaded.

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

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

Given the tool's complexity (16 parameters) and lack of an output schema, the description is somewhat under-specified. It does not explain how filters combine (e.g., AND logic), whether results are sorted, or that pagination is available. However, the rich schema covers parameter semantics, and the description clearly states the core purpose and output. It is minimally complete but lacks helpful context about pagination and no-filter behavior, warranting a score slightly above the minimum.

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 covers all 16 parameters with detailed descriptions, giving a baseline of 3. The description adds marginal value by listing some filter categories (titles, locations, companies, skills, salary, remote), which maps to schema properties. However, it does not add new semantic meaning, syntax, or combination rules beyond what the schema already provides. It reinforces the existence of filters but does not compensate for any gaps.

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

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

The description clearly states the tool's function: 'Search for jobs with filters like titles, locations, companies, skills, salary, and remote options.' This specific verb-action and resource combination distinguishes it from siblings like get_job (retrieve one job) and match_jobs (likely a different matching algorithm). It also notes the output ('Returns a list of matching job postings'), 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 provides no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or comparisons to related tools such as match_jobs, get_job, or import_job_by_url. The only usage context is implicit from the tool's name and purpose, which is insufficient for an agent deciding between multiple job-related 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 carries the full burden of behavioral context. The statement, 'The email will be sent from your configured email,' provides useful operational context regarding the sender's origin/authentication, earning it a minimal positive score above baseline.

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

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

The definition is highly efficient, using two concise sentences to cover both the action and a key behavioral characteristic (sender identity). There is zero redundancy.

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

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

Given the detailed input schema, the definition is functionally complete for initiating the request. It clearly outlines the required inputs for a successful action, although it lacks behavioral guarantees (e.g., delivery rate or failure states).

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 provides 100% description coverage, setting the baseline at 3. The description contributes marginally by explaining the overall goal (reaching out to specific job contact types), but it does not add unique or specialized semantic meaning to any individual parameters beyond what is already detailed in the schema.

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

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

The description uses a specific verb ('Send'), identifies the resource (outreach email), and clearly defines the target audience (recruiter or referrer for a job application). This distinguishes it effectively from sibling tools like 'apply_to_job' or 'get_job_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 describes what the tool does, but not when to use it. It provides no guidance on prerequisites, such as which contact data must be obtained first, nor does it mention alternative approaches or limits, leading to minimal actionable usage advice for the agent.

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 for behavioral disclosure. It only says 'Update' without mentioning side effects, whether it partially updates or replaces existing data, return values, permission requirements, or error behavior. This is minimal 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, compact sentence with no wasted words. It front-loads the purpose and is immediately scannable.

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 (3 params, no output schema), the description covers purpose and parameter names, but lacks behavioral information like return values or side effects. The schema fills parameter details, but no annotation/description covers the effects of the update. It's minimally sufficient but not comprehensive.

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

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

Schema coverage is 100%, and the description adds no meaning beyond the schema. The description 'status or notes' merely mirrors property descriptions. Since the schema already explains params clearly, 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 a specific verb and resource: 'Update a job application status or notes'. It distinguishes from siblings like get_application (read) and apply_to_job (create) by specifying the update action on the same resource.

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 you need to update application status or notes) but provides no explicit when-to-use vs alternatives, prerequisites, or exclusions. There is no mention of using get_application for viewing or other related 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 takes on the burden of disclosing behavioral traits. It prominently highlights that the config replaces the entire object (not a partial merge), a critical non-obvious behavior. It could add details about side effects like credit consumption, but the schema covers field-level semantics adequately.

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

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

Three sentences, front-loaded with purpose, followed by usage and a critical warning. No redundant phrasing; each sentence delivers 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?

The description addresses the key complexity (config replacement) and provides a clear workflow. However, it doesn't explicitly mention the full range of updatable top-level fields (e.g., status, autoMode) or the return value. Given no output schema, some return-type guidance would help, but the schema and get_job_hunt reference mitigate this gap.

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

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

Schema coverage is 100%, so baseline is 3. The description adds crucial parameter usage guidance: pass the entire config object and retrieve the current config first. This meaningfully supplements the schema by clarifying replace 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 verb 'Update' and the resource 'job hunt settings and search filters', making it distinct from sibling tools like get_job_hunt and create_job_hunt. It accurately conveys the tool's function without ambiguity.

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

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

The description provides clear usage context ('Use this to change what jobs are matched') and explicitly recommends calling get_job_hunt first to retrieve the current config, which is a strong guideline for correct usage. It doesn't enumerate exclusions, but the reference to get_job_hunt covers the read-only alternative.

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 responsibility for behavioral disclosure. It only repeats the action ('Update your user profile fields') without explaining whether it's a partial update, whether it modifies the authenticated user's profile exclusively, or any side effects. This is inadequate 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 concise sentence that is front-loaded and free of fluff. It is appropriately short for a tool whose parameter details are fully documented in the schema, though it borders on under-specification.

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 15 parameters and no output schema, the description is incomplete. It fails to mention that all parameters are optional, that only provided fields will be updated, or what the response contains. This is a significant gap for a tool of this complexity, making it much less useful than it could be.

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%, meaning all 15 parameters have detailed descriptions in the input schema. The tool description itself adds no parameter semantics, but since the schema already covers them, 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 tool's purpose with a specific verb ('Update') and resource ('user profile fields'). It distinguishes from siblings like get_profile (read-only) and update_salary (salary-specific). However, it lacks detail on which fields are included, leaving that to 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?

There is no explicit guidance on when to use this tool or when to prefer alternatives. It does not mention exclusive conditions, prerequisites, or a note like 'Use update_salary for salary changes.' The usage context is only implicitly derived from the tool's name.

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

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

No annotations are provided, so the description must carry the behavioral burden. It does so admirably by revealing the non-obvious unit behavior (lakhs vs thousands) and pointing to get_currencies for valid codes. It also implies the update modifies existing salary data, which is intuitive. However, it doesn't disclose potential side effects, reversibility, or permission requirements, which would be valuable but are not critical for this simple update 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 efficiently structured: a brief purpose statement, an important unit-convention warning with examples, and a pointer to get_currencies. Every sentence earns its place, and the most critical behavior (units) is front-loaded. It is appropriately sized for a tool with six parameters and no annotations.

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 has six optional parameters, no output schema, and no annotations, the description does a strong job covering the essential context: unit conversions, currency lookup, and the scope ('your salary'). However, it omits return-value behavior (e.g., whether it returns the updated salary) and whether partial updates (only some fields) are supported. These gaps are minor since the schema implies all fields are optional, but they prevent a perfect score.

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%, providing descriptions for all six parameters, including the unit convention. The tool description adds value by giving concrete examples (e.g., '20 for 20 lakhs' and '400 for $400K') and reinforcing that all numeric fields use the same convention. It also clarifies the currency parameter by referencing get_currencies, which goes beyond the schema's generic 'Currency code' description.

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

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

The description clearly states the tool's function: 'Update your salary/compensation details.' It specifies the resource (salary/compensation) and the action (update), which differentiates it from sibling tools like get_salary (read) and update_profile (general profile update). While it doesn't explicitly contrast with update_profile, the resource is distinct enough for an agent to select correctly.

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

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

The description provides explicit usage context by explaining the critical unit convention (lakhs for INR, thousands for other currencies) and instructs the agent to 'Use get_currencies to look up currency codes.' This gives clear when-to-use guidance and references an alternative tool for a prerequisite step. It does not explicitly state when not to use this tool, but the context is sufficient for most 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?

No annotations exist, so the description must disclose behavioral traits. It reveals that by default the profile is synced with resume content, and specifies a 5MB size limit. However, it omits the default behavior of replacing the primary resume (only implied by the schema's isAltResume) and any information about authentication or success/failure responses.

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 four sentences long and covers action, constraints, and an alternative. It is relatively concise, but the final sentence about the profile URL is somewhat wordy and could be shortened. Overall, every sentence serves a 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?

The tool has no annotations or output schema, so the description should carry the full burden. It provides usages, file types, and sync behavior, but lacks a description of return values or the fact that the primary resume is replaced by default unless isAltResume is set. This leaves gaps for a complete understanding.

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 descriptions for all three parameters, so coverage is 100%. The description adds a file size limit (5MB) not present in the schema, and restates the sync behavior that's already in the syncProfile parameter description. It adds little 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 action with a specific verb and resource: 'Upload a resume from a publicly accessible URL.' It lists supported file types and size limit. The URL-based method distinguishes it from the sibling tool 'upload_resume_from_file', though not explicitly named.

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 an explicit alternative when the user lacks a hosted URL: 'they can upload it directly from their profile at https://6figr.com/profile instead.' It implies the tool should be used when a direct URL is available. However, it does not name the sibling tool 'upload_resume_from_file' as a local file alternative, so it's not fully explicit.

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