Himalayas Remote Jobs MCP Server

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 states the authentication requirement, which is useful, but it fails to disclose what happens when a perk is added (e.g., whether it creates a new record, if there is any validation, if duplicates are allowed, or what the response will be). For a mutation tool, this is a significant gap.

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

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

The description is a single, well-structured sentence that immediately states the primary action and the key requirement (authentication). Every word serves a purpose, with no redundancy or filler, making it highly concise and easy to parse.

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

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

The tool is relatively simple with three fully documented parameters and no nested objects or output schema. The description adds the essential authentication context, which helps the agent decide if it can invoke the tool. However, the absence of any information about side effects or response behavior leaves some gaps, especially since no annotations exist to fill them.

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

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

The input schema covers 100% of the parameters with detailed descriptions, including length constraints and an enum for category. Since the schema already provides the necessary semantic meaning, the description does not need to repeat it. The baseline of 3 applies because the schema does the heavy lifting.

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

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

The description clearly states the tool's verb ('Add') and resource ('a perk/benefit to your company'), making it immediately obvious what the tool does. It also distinguishes itself from sibling tools like get_company_perks and remove_company_perk by specifying the action is to add, not retrieve or delete.

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 prerequisite: 'Requires employer authentication,' which tells the agent that this tool is only for employer users and not for general talent seekers. However, it does not explicitly mention when to use this tool over alternatives or list any exclusions, so it falls short of the top score.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It does mention 'Requires authentication', which is a useful precondition, but it does not disclose side effects such as whether existing education entries are modified or whether duplicate entries are allowed. This is partial disclosure.

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

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

The description is two short sentences with no filler. The core function is front-loaded in the first sentence, and the second adds a necessary precondition. Every sentence earns its place.

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

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

The tool has 9 parameters and no output schema or annotations. The description covers the action and authentication but does not explain return values or parameter interactions (e.g., end_year should be omitted when current is true, though that is already in the schema). It is adequate but leaves some context gaps.

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

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

The input schema provides descriptions for all 9 parameters (100% coverage), so the description does not need to add parameter-specific details. The tool description adds no parameter information, but the schema already covers them, justifying a baseline score of 3.

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

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

The description states 'Add an education entry to your Himalayas profile', which is a specific verb and resource. It clearly distinguishes from sibling tools like 'add_experience' and 'add_company_perk' by explicitly targeting education.

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 only mentions 'Requires authentication' and does not provide explicit when-to-use or when-not-to-use guidance compared to alternatives. Usage is implied by the tool name and description, but no exclusions or alternative recommendations are given.

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

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

The description discloses that authentication is required, but without annotations, it does not clarify side effects (e.g., whether it modifies the profile, idempotency, or if it replaces existing experiences). Since this is a mutation tool, more behavioral context would be expected.

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

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

The description is two sentences with no redundant information; it front-loads the purpose and appends the auth note. 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 9 parameters and no output schema, the description covers purpose and auth but does not explain the expected response or constraints beyond the schema. It is minimally sufficient given the schema richness, but leaves some gaps about the operation's effect.

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 all 9 parameters with 100% coverage, so the description adds no additional parameter-level semantics. Baseline 3 is appropriate.

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

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

The description clearly states the action ('Add') and the resource ('a work experience to your Himalayas profile'), which also distinguishes it from sibling tools like add_education and update_profile.

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

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

The description states only what the tool does and the authentication requirement, but provides no explicit guidance on when to use it versus alternatives. The usage scenario is implied by the verb but no exclusions or alternative tool mentions are given.

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

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

With no annotations, the description adds the useful note that no authentication is required. However, it does not disclose return format, potential errors, or whether the operation is read-only, leaving some behavioral aspects unspecified.

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

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

The description is two sentences with the main purpose front-loaded and no redundant information. Every sentence contributes meaning, making it appropriately concise.

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 tool with no output schema, the description adequately covers purpose, parameter source, and authentication. It could mention what the response contains, but given the tool's low complexity, the information provided 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 schema already describes session_id as a Stripe checkout session ID (100% coverage). The description adds value by explaining where this session_id originates (from post_job_public or create_company_job with extras), which is not present 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 clearly states the tool checks the payment status of a job posting, using a specific verb and resource. It also specifies where the required session_id comes from, distinguishing it from related tools like update_job_status or purchase_job_extras.

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 by instructing to use the session_id from post_job_public or create_company_job with extras. It does not list alternatives or exclusions, but the workflow implication 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?

With no annotations provided, the description carries the full burden for behavioral disclosure. It adds meaningful context: jobs are free to post, require admin approval before going live, and require employer authentication. However, it does not mention the draft parameter, what happens to a draft, or potential error conditions (e.g., if the employer is not authenticated), leaving gaps in the behavioral picture.

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

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

The description is concise at two sentences and front-loads the primary purpose ('Post a new job'). It communicates the most critical contextual facts without fluff. It could have used the second sentence to mention the draft option, but as a standalone description it is efficiently paced.

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

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

For a complex tool with 14 parameters and no output schema, the description covers the essential purpose and two key behavioral aspects (free posting, approval required). However, it omits mention of the draft workflow, screening questions, extras, and other nuances that the input schema handles. The description is adequate but not comprehensive enough to fully orient an agent without relying heavily on the schema.

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

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

The input schema has 100% description coverage for all 14 parameters, meaning the schema already documents each parameter clearly. The tool description itself adds no parameter-specific information, so it neither enhances nor detracts from the schema's guidance. 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 clearly states the tool posts a new job on Himalayas, with a specific verb ('Post') and resource ('job'). It also adds context ('free to post', 'require admin approval') and an authentication requirement. However, it does not explicitly distinguish from the sibling tool 'post_job_public', making the differentiation partially reliant on the tool name and the employer authentication note.

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

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

The description implies the tool is used when an authenticated employer wants to create a job, and notes that jobs are free and require admin approval. It does not explicitly state when to use this tool over alternatives like 'update_company_job' or 'post_job_public', nor does it mention any prerequisites beyond 'employer authentication'.

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?

Without annotations, the description carries the burden of disclosing behavioral traits. It explicitly states 'This action cannot be undone' (irreversibility) and 'Requires employer authentication' (permission requirements). This adds significant context beyond the basic action of deletion, though it does not mention effects on related data such as applications.

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

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

The description is two sentences long and every word earns its place: the action, the scope ('from your company'), the platform, the irreversibility, and the auth requirement. No filler or repetition.

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

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

For a single-parameter delete tool with no output schema, the description covers the essential aspects: what it does, who can use it, and a critical consequence (irreversibility). It could optionally mention what the response looks like, but that is not required for completeness given the tool's simplicity.

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

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

The input schema has 100% description coverage with 'Job slug to delete' for the only parameter. The description adds no further meaning beyond confirming the slug identifies the job to delete, but the schema already provides clear semantics, so a baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'Delete' and the resource 'a job posting from your company on Himalayas'. It distinguishes this from sibling tools like create_company_job, update_company_job, and show_company_job by specifying it's a deletion operation.

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

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

The description gives context that this is for an employer's own job posting and requires employer authentication, but it does not explicitly state when to use this over alternatives or provide exclusion criteria. Sibling tools exist for creation, updating, and viewing, which implicitly clarifies usage, but no direct guidance is given.

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

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

Without annotations, the description carries the full burden. It discloses a key behavioral trait (employer authentication) and the input flexibility (room_name or talent_slug). However, it omits critical information about permanence, side effects (e.g., message deletion), and response behavior, which is significant for a destructive operation.

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

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

The description is extremely concise at three short sentences, front-loaded with the action, and every sentence adds a distinct piece of information: purpose, accepted inputs, and authorization requirement.

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

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

The tool is simple (2 params, 0 required, no output schema), and the description covers the essentials. However, it lacks any mention of consequences (irreversibility, impact on messages), error conditions, or confirmation behavior, which would be expected for a delete operation. Adequate but with clear gaps.

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

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

Schema description coverage is 100%, so baseline is 3. The description's mention of 'Accepts room_name or talent_slug' is redundant with the schema, which already explains both parameters and the auto-resolution of talent_slug. No additional meaning 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 clearly states the action ('Delete a conversation') with a specific verb and resource. It distinguishes itself from siblings like get_conversation and list_conversations by being the only delete operation, and the parameter flexibility is mentioned.

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

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

There is no guidance on when to use this tool vs alternatives, nor any exclusions or conditions beyond 'Requires employer authentication.' The usage is implied rather than explicit, and no sibling alternative is referenced.

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

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

With no annotations, the description carries the full behavioral burden. It implies a read-only browse operation but does not disclose pagination behavior, response format, or any required permissions. The schema reveals a 'page' parameter and the worldwide override behavior, but the description itself adds little transparency beyond the basic purpose.

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

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

The description is a single concise sentence that immediately states the tool's purpose and key optional filters. Every word earns its place with no fluff 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?

Despite having no output schema and at least one sibling tool (search_companies) that overlaps, the description is too sparse. It fails to mention response format, pagination behavior, or when to choose this over search_companies, leaving the agent without adequate context for correct invocation.

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

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

Schema description coverage is 100%, so the parameters are already well-documented. The description above maps conceptually to 'country' and 'worldwide', but adds no extra semantic value beyond what the schema provides, such as the override behavior or default pagination.

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 remote-friendly companies and supports optional filtering by country or worldwide availability. The verb 'Browse' distinguishes it from more specific tools like get_company_details, though it doesn't explicitly differentiate from the sibling search_companies.

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

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

No guidance is provided on when to use this tool versus alternatives like search_companies. The description implies usage for browsing/filtering but gives no exclusions or context on when this list endpoint is preferred over other company-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, the description carries the full burden of behavioral disclosure. It lists return content but does not mention authentication requirements, error behavior, read-only safety, or potential limitations. The verb 'Get' implies a read operation, but explicit transparency is lacking.

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

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

The description is a single, focused sentence that opens with the action and resource, then lists the included data categories. It contains no redundant or extraneous wording.

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 a simple interface with one well-documented parameter, but no output schema or annotations. The description covers the main return categories but omits operational context such as authentication, pagination, or error handling, making it only partially 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 single `company_slug` parameter, including an example. The description adds no additional parameter semantics beyond the schema, so the baseline score 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 identifies the tool as retrieving comprehensive company details and enumerates specific data categories (about, tech stack, benefits, open positions, social links). While it doesn't explicitly contrast with sibling tools like get_company_profile, the 'full details' phrasing gives a specific scope.

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

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

No guidance is provided on when to use this tool versus alternatives such as get_companies, get_company_profile, or list_company_jobs. The description only states what the tool does, leaving the agent to infer appropriate usage from the name and context.

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

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

With no annotations provided, the description carries the full burden. It notes the authentication requirement, which is useful behavioral context, but does not disclose whether the operation is read-only, what the return shape is, or how errors (e.g., missing auth) are handled. These gaps reduce transparency.

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

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

The description is a single, front-loaded sentence that states purpose and a key constraint. Every word earns its place with no redundancy or filler.

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

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

For a zero-parameter, read-type tool, the description covers the essential purpose and authentication context. However, since there is no output schema, the description could briefly mention what the response includes (e.g., a list of perks) to be fully complete. Overall, it is adequate for the tool's simplicity.

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

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

The tool takes zero parameters and the schema has empty properties. Per the rubric baseline, 0 parameters earns a 4. The description adds no parameter information, but none is needed since there are no inputs.

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 clearly identifies the resource ('your company's perks/benefits') and platform ('Himalayas'). This distinguishes it from sibling tools like add_company_perk and remove_company_perk, which handle mutations.

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 view your company's perks) and mentions the employer authentication requirement. However, it does not explicitly contrast with the add/remove sibling tools or state when not to use it, so guidance is only implicit.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It mentions the authentication requirement, which is a key behavioral trait, but does not disclose return format, error behavior, or explicitly state that it's a read-only operation. This is partial transparency – better than nothing but not comprehensive.

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

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

The description is a single, front-loaded sentence with no filler. It states the action and the key requirement (authentication) in under 10 words, earning its place.

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

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

Given the tool is a zero-parameter read operation with no output schema, the description is nearly complete. It could optionally mention what data is returned, but the tool name and description make the purpose clear. The only minor gap is potential confusion with get_company_details, but sibling differentiation is handled in purpose clarity.

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 for this dimension is 4. The description does not need to explain any parameters since there are none. It also does not misuse or misinterpret 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 'Get your company's profile on Himalayas' – a specific verb (get), resource (company profile), and platform. The possessive 'your company's' distinguishes it from get_company_details, which likely retrieves public company information.

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 'Requires employer authentication' provides a clear context for when to use this tool (as an authenticated employer). It does not explicitly list exclusions or alternatives, but the context is clear enough to infer it's for your own company's profile, not for arbitrary companies.

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 an important behavioral prerequisite (employer authentication) and the automatic resolution of talent_slug to room_name, but it does not explicitly state that this is a read-only operation, nor does it describe return values, pagination, or error 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 only two sentences, front-loaded with the primary purpose and immediately followed by essential input and auth information. No wasted words.

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

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

For a simple read tool with two optional parameters and no output schema, the description is largely complete. It explains what it does, what inputs to use, and an authentication requirement. Minor gaps include the exact contents of 'full message history' and whether pagination exists, but these are not critical for basic use.

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

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

The input schema provides 100% coverage with clear field descriptions (e.g., 'Room name from list_conversations', 'resolves to room name automatically'). The tool description merely repeats the parameter names without adding extra 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 clearly states the action ('Get full message history') and the resource ('a conversation'), with specific input modes ('room_name or talent_slug'). This distinguishes it from siblings like list_conversations, which likely only lists metadata.

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 on when to use the tool (to retrieve full history) and prerequisites ('Requires employer authentication'). However, it does not explicitly mention alternatives or exclusions, leaving room for confusion with list_conversations, though the intent 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?

There are no annotations, so the description must disclose behavioral traits. It reveals that the tool resolves a name to a system-specific correct format, which implies a lookup/transformation operation. However, it does not describe behavior for unknown inputs, case sensitivity, or whether it returns null/error, which is a notable gap for a normalization tool.

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

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

Two short sentences, each carrying distinct information: the core function and the intended use case. Information is front-loaded, with no filler or repetition of schema content.

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

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

For a single-parameter lookup tool with a high-coverage schema and no output schema, the description covers the essential information: what it does, what its output is intended for, and when it is useful. It does not specify error handling, but that is likely not critical for such a simple utility.

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's description is nearly tautological ('The country name to get the correct name for'). The tool description adds valuable context by stating that the input may be fuzzy user input, implying that the parameter accepts common variations and that the output is normalized. This goes beyond the schema to clarify acceptable input format.

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

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

The description uses the specific verb 'Resolve' and clearly identifies the resource ('country name') and the target ('correct format accepted by Himalayas filters'). This distinguishes it from sibling tools, which are mostly CRUD operations on jobs/profiles/messages. The second sentence clarifies its purpose in fuzzy matching.

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 indicates a clear use case: 'Useful for fuzzy matching user input' suggests it should be used when user-provided country names may be informal or misspelled, before applying Himalayas filters. However, it does not explicitly state alternatives or scenarios where it should not be used, but given its unique normalization role, the guidance is adequate.

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 return content (description, requirements, salary, application link) but does not explicitly state that this is a read-only operation or discuss potential errors or authorization. The read intent is obvious from 'get,' but it could be more explicit.

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

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

Two short sentences, front-loaded with the main action and then parameter guidance. Every word earns its place; no fluff 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?

For a simple retrieval tool with two parameters and no output schema, the description is quite complete. It lists the key return fields and explains where to get the input values. It could mention the response format or any limits, but given the simplicity, it 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?

Schema coverage is 100% with clear descriptions for both parameters. The description adds 'from job listings' which mirrors the schema's 'from the job listing URL.' This provides slight context on source but does not significantly go beyond 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 purpose: 'Get full details for a specific job' and lists the main content (description, requirements, salary, application link). This specific verb+resource phrasing distinguishes it from listing tools like get_jobs and from other mutating operations.

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

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

The description implies usage context: you need a specific job and have slugs from listings. It does not explicitly mention alternatives or exclusions, such as 'for a list of jobs, use get_jobs' or 'this is read-only.' Thus usage is implied rather than explicitly guided.

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 behavior. It communicates read-only browsing and the filter behavior, but does not disclose pagination behavior, return format, authentication needs, or whether results include only active jobs. It adds some context but lacks depth.

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, well-structured sentence that places the primary action ('Browse') upfront and concisely lists filtering options. No superfluous words; every element 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 list-browsing tool with no output schema or annotations, the description covers the core purpose and filters but is missing critical return information such as pagination details, response structure, and sorting. It is adequate but not fully complete for an agent to know what to expect.

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 all three parameters (page, country, worldwide). The description adds minimal value beyond the schema, simply mentioning optional country/worldwide filtering without additional semantics. Per calibration, baseline 3 applies when schema does the heavy lifting.

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

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

The description clearly states the tool's function: browsing the latest remote job listings with optional country/worldwide filtering. It distinguishes itself from sibling tools like get_job_details (single job), search_jobs (search-based), and list_company_jobs (company-specific) by focusing on general remote job browsing.

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 (browsing remote jobs) and mentions filtering options, but it does not explicitly state when to use this tool over alternatives like search_jobs or get_related_jobs. It lacks exclusions or comparisons to siblings, leaving the agent to infer.

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 discloses that authentication is required, which is a key prerequisite, and the verb 'Get' indicates a read operation. While it does not elaborate on response format or error conditions, the simplicity of the tool makes this sufficient context.

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

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

The description is extremely concise at two sentences and eight words, with the main verb and resource front-loaded. Every word earns its place, and there is no redundant or filler content.

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

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

Given the tool's low complexity (no parameters, no output schema), the description is complete enough for an agent to select it confidently. It states what the tool does and the authentication requirement, covering the essential information needed for correct invocation.

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

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

The tool has zero parameters, and the schema coverage is 100% (empty properties). Per rubric, a baseline of 4 is appropriate when there are no parameters, and the description does not need to compensate for anything.

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 specific resource ('your Himalayas profile information'), making it obvious that this tool returns the authenticated user's own profile. The possessive 'your' and the resource name 'Himalayas profile' effectively distinguish it from sibling tools like get_company_profile and get_talent_profile.

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

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

The description provides clear context by indicating that this tool is for retrieving your own profile and explicitly notes that authentication is required. It does not mention alternatives or explicitly state when not to use it, but the 'your' phrasing strongly implies the appropriate use case, so it slightly exceeds implied usage.

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

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

No annotations are provided, so the description carries the full burden. It adds useful behavioral context about matching criteria (skills, location, category) but does not disclose whether it is a read-only operation, return format, or potential limitations. Some gaps remain but the description is not misleading.

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

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

Two concise, front-loaded sentences. The first explains the core function, the second the intended use case. No redundant words.

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

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

For a simple 2-parameter read tool with no output schema, the description covers the essential context: what it does and when to use it. It lacks explicit return type info, but the name and description imply a list of job results, which is adequate for this 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 the schema already documents both parameters as 'slug of the original job.' The description adds marginal value by clarifying that the similarity is based on skills/location/category, effectively reinforcing the relationship between parameters and behavior without providing new syntax or format 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 the tool finds jobs similar to a specific job based on skills, location, and category, using a specific verb ('Find') and resource ('jobs similar'). It distinguishes itself from sibling tools like search_jobs and get_job_details by explicitly targeting a reference job and suggesting alternatives.

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

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

Gives clear context: 'Use after viewing a job to suggest alternatives.' This tells the agent when to invoke it, though it does not name specific alternatives or exclusions, preventing a 5.

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

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

With no annotations provided, the description must convey behavior. It discloses that the tool returns counts by various breakdowns. However, it does not mention defaults (e.g., default type is 'skills', default record is 'jobs') or the constraint that 'industries' only works with record='companies' (though the schema covers this). No side effects are mentioned, but 'get' implies a read-only operation. The transparency is adequate but not comprehensive.

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

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

The description is two sentences, front-loaded with the primary action and resource, then the specific dimensions. Every word adds value, and there is no redundant information. 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?

Given the tool's moderate complexity (three optional params, no output schema), the description provides a clear overview of what the tool offers. It explains the grouping dimensions and counting basis, but does not describe the output structure (e.g., whether results are sorted, or include both name and count). However, the schema's parameter descriptions fill in most gaps, making the tool sufficiently understandable for an agent.

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

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

The input schema has 100% coverage with descriptions for all three parameters, so the baseline is 3. The description adds value by clarifying the relationship between the parameters: 'by job/company count' explains the 'record' parameter, and listing 'skills, categories, countries, industries' maps to the 'type' enum. This supplements the schema's individual parameter descriptions.

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

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

The description clearly states the tool's function: 'Get remote work statistics' and enumerates the breakdown dimensions (skills, categories, industries, countries) and the counting basis (job/company count). This distinguishes it from sibling tools like get_jobs or search_jobs, which return records rather than aggregated statistics.

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 'Great for understanding the remote work landscape' provides a clear use case and implies when to use it (for high-level analysis) versus alternatives that return individual records. However, it does not explicitly state when not to use it or name alternative tools, so it stops short of full differentiation.

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

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

With no annotations, the description carries the full burden. It discloses the return format (min, max, median in USD), which is useful, but does not mention side effects, permissions, or read-only status. The verb 'Get' implies a safe read operation, but the description does not explicitly state this.

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 purpose ('Get salary benchmarks') and efficiently packs in the key details (remote jobs, filters, return values). No wasted words.

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

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

For a simple lookup tool with 3 parameters and no output schema or enums, the description is fairly complete: it covers purpose, parameters, and return values. It could be slightly enhanced by explicitly noting that the tool is read-only or by providing an example, but it is adequate as is.

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 reiterates the parameters (job_title, seniority, country) but adds minimal new meaning beyond what the schema already provides, such as noting they are optional and the currency is USD.

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 with a specific verb ('Get'), resource ('salary benchmarks'), and scope ('remote jobs by job title'), mentioning optional filters. This distinguishes it from sibling tools like get_jobs (job listings) and get_remote_work_statistics (remote work statistics).

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

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

The description implies when to use the tool (when you need salary benchmarks by job title) but does not explicitly state alternatives or exclusions. It lacks direct guidance on when not to use it or how it differs from related tools such as get_remote_work_statistics.

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 behavioral disclosure burden. It discloses that authentication is required, which is a useful behavioral trait. However, it does not mention whether the operation is read-only (though 'get' implies so), potential pagination, or return format. The description adds minimal context beyond the tool name, but the authentication note provides some value.

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 of eight words, with the core purpose front-loaded: 'Get all jobs in your application tracker.' The additional note about authentication is brief and earns its place. There is no unnecessary verbosity or repetition.

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 that the tool is a simple no-parameter getter with no output schema, the description is nearly complete: it states what the tool does and the auth requirement. However, it does not describe the return value structure (e.g., what fields are included) or behavior when there are no saved jobs. Still, for this level of complexity, it is adequate and close to complete.

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

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

The tool has zero parameters, so the parameter baseline is 4. The description does not need to explain parameters, and the schema coverage is trivially 100% with an empty properties object. No additional parameter 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 a specific action ('Get') and a specific resource ('all jobs in your application tracker'), which distinguishes it from general job searching tools like get_jobs. The term 'application tracker' effectively conveys that this is about the user's saved jobs, differentiating it from sibling tools like search_jobs and get_jobs.

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

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

Usage context is implied: it is for retrieving jobs the user has saved in their application tracker. However, no explicit guidance is given about when to prefer this over alternatives like get_jobs or search_jobs, nor any exclusions. The description does not explicitly name alternatives, so it falls short of full usage guidance.

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

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

With no annotations provided, the description carries the full burden. It does disclose the read-only nature ('Get full details') and the kind of data returned, but it does not mention authentication requirements, error behavior, response format, or potential rate limits. This is acceptable for a simple read tool but leaves some behavioral aspects 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 sentences with no wasted words. The first sentence front-loads the purpose and key data categories, and the second sentence gives the essential input source. Every sentence contributes useful 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 one-parameter read tool, the description is adequate: it names the resource, lists the types of data included, and explains where to get the input. There is no output schema, so a bit more detail about the exact return structure could help, but the description's list of content categories covers the essentials.

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 has 100% coverage for the single parameter, including an example ('john-doe'). The description adds a workflow hint by saying to use the talent_slug from search_talent results, but this is largely redundant with the schema's own parameter description. 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 uses a specific verb ('Get') and resource ('full details for a candidate'), listing concrete content categories (bio, experiences, education, tech stack, social links). It clearly distinguishes this from sibling tools like get_company_profile or get_my_profile by targeting candidate profiles and pointing to search_talent as the source.

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

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

The description explicitly instructs to use 'the talent_slug from search_talent results,' which provides clear when-to-use context and workflow guidance. It does not explicitly mention exclusions or alternatives, but the reference to search_talent makes the intended usage 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?

With no annotations provided, the description carries the transparency burden. It discloses the authentication requirement and the fields shown, but does not mention pagination behavior, return format, or the read-only nature. Some valuable context is added, but gaps remain.

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

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

Two sentences, front-loaded with the core purpose, followed by essential detail on output and authentication. Every word earns its place with zero redundancy.

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

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

For a simple list tool, the description covers the essentials: what it lists, key output fields, and authentication. It would benefit from an explicit mention of pagination, but the schema already handles that, and the tool's simplicity means the description is nearly complete.

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

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

The schema covers the only parameter (page) with a clear description, so the description's lack of parameter details is acceptable. The description adds no further meaning beyond the schema, aligning with the baseline score of 3.

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

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

The description uses a specific verb ('List') and resource ('your company's job postings on Himalayas'), clearly distinguishing it from public job search tools like get_jobs and search_jobs. It also lists the key output fields (status, views, clicks, expiry), 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 statement 'your company's' and 'Requires employer authentication' establishes clear context for when to use this tool (employer viewing their own postings) versus public-facing tools. However, it does not explicitly name alternatives or state exclusions, so it stops short of a 5.

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

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

With no annotations, the description carries the burden of disclosing behavioral traits. It reveals the authentication requirement ('Requires employer authentication') and the nature of returned data (conversations with status). Though it does not explicitly state read-only, the verb 'List' implies a non-mutating operation, providing reasonable transparency.

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

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

The description is two sentences long, front-loaded with the core action, and includes only relevant details (status preview, auth). Every sentence earns its place with no redundancy.

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

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

Given zero parameters and no output schema, the description sufficiently covers the purpose, return content (preview/status), and auth requirement. It omits potential details like pagination or ordering, but for a simple list tool, the description is adequate for an agent to use the tool correctly.

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

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

The tool accepts zero parameters, and the schema has no properties. Per the rubric, a 0-param tool gets a baseline of 4. The description adds no further parameter detail because none 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 'List all your messaging conversations with last message preview', specifying the verb, resource, and scope. This distinguishes it from sibling get_conversation, which likely retrieves a single conversation.

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

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

The description implies the usage context ('List all your messaging conversations'), and the output details (preview/status) make it clear what to expect. However, it does not explicitly compare to alternatives like get_conversation, so it lacks explicit when-not-to-use guidance.

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

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

No annotations are provided, so the description carries the full burden. It discloses the employer authentication requirement, which adds useful context for a mutation action. However, it does not explain side effects (e.g., whether it is idempotent, what happens if the message doesn't exist, or if it affects unread counts). For a simple mark-as-read operation, this is adequate but not thorough.

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

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

The description is extremely concise: two short sentences with no wasted words. It front-loads the primary action and then states the key prerequisite. 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 simple tool with three parameters (one required) and no output schema, the description is largely sufficient. It covers the core action and the auth requirement. However, it omits that certain parameters (room_name, talent_slug) are alternative ways to identify the target conversation, which the schema descriptions handle but the tool description does not. The overall context is complete enough for a straightforward mutation tool.

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

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

Schema description coverage is 100%, so all three parameters (room_name, message_id, talent_slug) are already documented with meaningful descriptions. The tool description adds no extra parameter information beyond what the schema provides. 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 clearly states the action ('Mark a message as read') and the specific resource ('a message by its ID'). It is distinct from sibling tools like send_message or start_conversation, though it does not explicitly call out alternatives. The purpose is unambiguous and specific.

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 only mentions the authentication requirement, which is a constraint, not a usage guideline. There is no mention of prerequisites, edge cases, or when not to use it.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses three critical traits: no authentication needed, payment required, and that a Stripe checkout URL will be returned. It does not, however, clarify whether the job goes live immediately upon posting or only after payment confirmation, which is a meaningful gap for a paid action. Still, it covers the major behavioral aspects.

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

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

The description is three sentences with no wasted words. It opens with the primary purpose, then mentions necessary inputs, and closes with the payment outcome. Every sentence earns its place, making it highly 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?

The tool has 14 parameters and no output schema, but the description covers the essential context: the purpose, the lack of authentication, the payment requirement, and the return of a Stripe checkout URL. It doesn't explain post-payment behavior or any other response structure, but given the tool's simplicity, it is reasonably complete. A minor gap prevents 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?

The input schema has 100% parameter description coverage, so the description is not expected to add detailed parameter semantics. The only addition is 'Provide your email and company details,' which generically highlights required fields but adds no specific value beyond the schema. According to the rubric, baseline 3 is appropriate.

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

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

The description clearly states the tool's function: 'Post a job on Himalayas without an account.' It specifies the resource (a job on Himalayas) and the scope (no account required), distinguishing it from siblings like create_company_job that likely require authentication. The phrase 'No authentication needed' reinforces this differentiation.

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

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

The description provides clear context for use: when posting a job without an account. It doesn't explicitly mention alternatives or exclusionary conditions, but the emphasis on 'without an account' and 'No authentication needed' effectively implies when this tool should be chosen over authenticated posting tools. A score of 4 fits since it gives clear context but no explicit alternatives.

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

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

With no annotations, the description carries the full burden. It discloses that it returns a Stripe checkout URL and requires employer authentication, which are key behavioral traits. However, it does not state whether the job is updated immediately or only after payment completes, nor does it describe error conditions (e.g., invalid job_slug).

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

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

The description is three short sentences, front-loading the core purpose and then adding return and auth context. Every sentence earns its place.

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

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

For a tool with two simple parameters and no output schema, the description covers the purpose, available extras, the return value, and authentication requirement. It does not explain the post-payment flow or how it relates to check_job_payment_status, but the essential information for invoking the tool is present.

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 documents both parameters thoroughly, including the enum values and descriptions with prices. The description's mention of sticky and newsletter prices adds no new information 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 opens with 'Purchase paid extras for an existing job posting', specifying both the action (purchase) and the resource (extras for an existing job). It names the two extras with prices, and the specific verb 'purchase' clearly distinguishes it from sibling tools like check_job_payment_status or update_company_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 states the tool is for purchasing extras on an existing job posting and notes it requires employer authentication, providing clear context for when it applies. It does not explicitly name alternative tools or exclusions, but the context (existing posting, paid extras) is clear enough.

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

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

The description discloses the authentication requirement, which adds behavioral context beyond the schema. However, it does not describe side effects, reversibility, or return behavior. With no annotations provided, the description carries the burden but only partially fulfills it.

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 wastes no words. It immediately states the action and resource, making it highly 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 deletion tool with one parameter and no output schema, the description is adequate but lacks details like return value or error behavior. The auth requirement adds some context, but the absence of any behavioral notes on the deletion itself leaves gaps.

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

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

The tool description itself doesn't elaborate on parameters, but the schema covers 100% with the id description 'Perk ID to remove (use get_company_perks to find IDs)', which adds helpful guidance beyond the property name. This meets the baseline for high schema coverage.

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

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

The description uses the specific verb 'Remove' with the resource 'perk/benefit from your company on Himalayas', clearly distinguishing it from sibling tools like add_company_perk and get_company_perks. It also adds the context of employer authentication, which clarifies the intended audience.

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, nor any exclusions or alternative recommendations. The only additional context is the authentication requirement, which is a prerequisite, not a usage guideline.

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

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

No annotations are provided, so the description carries the full burden. It discloses the destination ('application tracker') and the auth requirement, but does not mention whether the removal is permanent, what side effects occur, or what the response looks like. For a mutation tool, this is minimal.

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

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

The description is a single sentence with no filler words; every word contributes to the meaning. It is appropriately sized for a tool with one parameter.

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

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

Given the simple tool (one required parameter, no output schema), the description covers the core action and a key prerequisite, and the schema fully documents the parameter. However, it could provide more context about what 'application tracker' refers to and the effect of removal, but the sibling and name clarify it somewhat.

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 a clear description for the only parameter ('Kanban item ID to remove'), so the schema coverage is 100%. The description does not add additional semantic detail about the id, but the baseline 3 applies because the schema does the heavy lifting.

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

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

The description uses the specific verb 'Remove' and identifies the resource as 'a job from your application tracker', which clearly distinguishes it from sibling tools like save_job and get_saved_jobs. It unambiguously states the tool's function.

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

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

The description includes a prerequisite ('Requires authentication') but does not explicitly state when to use this tool versus alternatives like delete_company_job or save_job. The usage is implied by the name and brief description, but no exclusions or context 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?

No annotations are provided, so the description must carry the burden. It only states 'Requires authentication' and does not disclose whether saving creates or updates, idempotency, return value, or any other side effects beyond the implied mutation.

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

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

The description is a single, front-loaded sentence with no filler. It states the action and a key requirement (authentication) in minimal words.

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

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

The rich schema covers parameter details, but the description is thin on behavioral and usage context. For a save operation with 10 parameters and no output schema, it could benefit from mentioning idempotency, return behavior, or relationship to other saved-job tools. Even so, it is minimally 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?

Schema description coverage is 100%, so all 10 parameters are documented in the schema. The description adds no extra meaning about parameters, such as which are required or how fields interact (e.g., status default), meeting the baseline but not exceeding it.

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

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

The description uses a specific verb ('save') and resource ('job'), and clarifies the scope ('to your application tracker'). It clearly distinguishes this tool from siblings like get_saved_jobs and remove_saved_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 offers no guidance on when to use this tool versus alternatives (e.g., update_job_status or create_company_job). 'Requires authentication' is a prerequisite, not usage context, and no exclusions or alternatives are mentioned.

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

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

With no annotations provided, the description carries the full burden. It discloses that this is a search operation (implying read-only), but does not mention result format, pagination, or how filters interact. The schema covers some of this, but the description adds minimal behavioral context beyond the core search 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 a single, well-structured sentence that front-loads the action verb 'Search' and contains no redundant words. Every element contributes to understanding the tool's purpose.

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

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

For a tool with 7 parameters, no required fields, no output schema, and no annotations, the description is minimal. It gives a high-level purpose but does not explain return values, how filters compose, or important nuances like the worldwide/country override (though the schema does). It is adequate 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 description coverage is 100%, so the schema already documents all seven parameters. The description reinforces keyword and country as the primary filters but adds no new parameter-level meaning beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states the verb 'Search' and the resource 'remote-friendly companies', and specifies the method (keywords with optional country filtering). This distinguishes it from sibling tools like get_companies (which lists companies) and search_jobs/search_talent.

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

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

The description provides clear context for when to use this tool: searching for remote-friendly companies with keyword and country filters. However, it does not explicitly name alternatives or state when NOT to use it, which would elevate it to a 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only restates the primary action and filter options, but does not mention key behavioral aspects such as pagination, result structure, default sort order, the fact that all parameters are optional, or that 'worldwide' overrides country. This is insufficient for a 15-parameter search 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, efficient sentence that is front-loaded with the main purpose ('Search for remote jobs') and immediately mentions key filtering options. There is no redundancy or filler; every word contributes to the core 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?

The tool has 15 parameters, no output schema, and no annotations, so the description needs to provide substantial context. It only offers a high-level summary and does not explain what the response contains, pagination behavior, default settings, or any special filter interactions. This is inadequate 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?

The schema descriptions cover 100% of parameters, so the baseline is 3. The description adds limited value by highlighting the keyword, country, and worldwide filters, but it does not explain any other parameters or their interactions. Since the schema already provides detailed parameter semantics, the description adds only marginal value beyond the schema.

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

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

The description clearly states the tool searches for remote jobs using keywords with optional country or worldwide filters. It identifies a specific verb (search) and resource (remote jobs), giving a clear purpose. However, it does not explicitly distinguish itself from sibling tools like get_jobs or get_related_jobs, so it loses a point for lacking explicit differentiation.

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

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

The description implies the tool is appropriate when searching for remote jobs, but it does not provide explicit guidance on when to use this tool versus alternatives like get_jobs or search_companies. There are no stated exclusions or alternative recommendations, so the usage context is implied rather than 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?

No annotations are provided, so the description carries the full burden. It indicates a read-only search operation but does not disclose behaviors like pagination, result format, or any restrictions. The description is too brief to provide meaningful behavioral transparency 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?

The description is appropriately concise—two short sentences that communicate the core function without redundant language. It front-loads the main action and resource.

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 and 100% schema coverage, the description provides adequate context for basic use. However, it does not mention default behavior, pagination limits, or what the output looks like, and the 'role' mention creates ambiguity. The lack of an output schema raises the burden on the description to explain expected results, but it falls short.

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 detailed descriptions for all four parameters. The tool description adds a reference to 'role' as a search criterion, but 'role' is not a parameter in the schema, which could mislead users. This mismatch reduces the value of the description in explaining parameter semantics.

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

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

The description clearly states the tool's function: searching for remote talent/candidates on Himalayas. It mentions the resource (professionals) and the criteria (keyword, country, role), distinguishing it from sibling tools like search_jobs or search_companies.

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

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

The description implies this tool is for browsing talent, but it does not explicitly mention when to choose it over search_jobs or get_talent_profile. There are no exclusions or alternative guidance, so usage context is only implied.

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

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

With no annotations provided, the description carries the full burden. It discloses the action is a write/send operation, requires employer authentication, works only on existing conversations, and explains that talent_slug resolves to a room name automatically. It does not mention return values or error behavior, but for a simple message-sending tool it provides substantial behavioral context.

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

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

Three sentences, all substantive. The core purpose is front-loaded, followed by parameter sourcing and a prerequisite note. No filler or repetition; every sentence earns its place.

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

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

For a simple tool with 3 parameters, no output schema, and no annotations, the description is complete enough for an agent to select and invoke it correctly. It covers what the tool does, when to use it, what inputs are accepted, the prerequisite of an existing conversation, and authentication requirements.

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 reinforces the parameter meanings already present in the schema (room_name from list_conversations, talent_slug from search_talent) and adds the note that talent_slug resolves automatically, which is also already in the schema. It does not add new semantic detail beyond the schema, so it meets but does not exceed the baseline.

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

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

The description clearly states the specific action ('Send a message') and resource ('existing conversation'), and it distinguishes itself from siblings like start_conversation (creating a new conversation) and mark_message_read. It also mentions accepting identifiers from related tools, 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 explicitly says to use start_conversation first if no conversation exists, which is a clear exclusion/alternative. It also tells the agent where to obtain valid identifier values (room_name from list_conversations, talent_slug from search_talent) and notes the employer authentication prerequisite.

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 discloses the authentication requirement (employer auth), which is valuable, and the read-only nature is implied by 'Get full details'. However, it does not clarify behavior like error cases, data scope, or pagination, leaving some transparency gaps.

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

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

The description is a single, front-loaded sentence that conveys the action, scope, and a key requirement. It contains no redundant words and is appropriately concise for a simple one-parameter tool.

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

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

For a simple get-by-slug tool with no output schema, the description is reasonably complete. It specifies the target ('one of your company's job postings'), the key prerequisite (employer authentication), and the parameter source. It could mention the return value shape, but 'full details' sufficiently implies the response. The simplicity of the tool reduces the need for more.

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

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

The schema has 100% description coverage for the single parameter job_slug, including its origin ('from list_company_jobs'). The description itself adds no additional parameter meaning beyond what the schema already states, matching 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 action ('Get full details') and resource ('one of your company's job postings'), which distinguishes it from generic job tools like get_job_details by emphasizing company-specific postings. However, it does not explicitly name any sibling tools, so it falls short of a 5.

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

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

The description implies usage context: use this when you need full details of your own company's job posting, and it requires employer authentication. The parameter description adds that job_slug comes from list_company_jobs, which helps sequencing. However, it does not explicitly state when to avoid using it or provide alternatives, so guidance is only partially 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 provided, the description carries the full burden. It discloses optional message sending, idempotent behavior ('If the conversation already exists, returns it'), and employer authentication requirement. This goes beyond simple action phrasing and provides useful behavioral context.

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

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

The description is three sentences, front-loaded with the primary action, and contains no fluff. Every sentence adds value: core action, idempotent behavior, and prerequisite workflow.

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 covers prerequisite, authentication, behavior, and parameters. It lacks detailed return format, but 'returns it' and the simplicity of the operation make this a minor gap. No output schema exists, but the description is otherwise complete enough.

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

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

Schema description coverage is 100%, so the baseline is 3. The description restates talent_slug and message but does not add new 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 uses a specific verb 'Start a conversation' with a resource ('with a candidate by talent slug'), making the action unmistakable. It also distinguishes itself from sibling tools like send_message by describing idempotent creation behavior ('If the conversation already exists, returns it').

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

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

The description explicitly instructs to use search_talent to find candidates first, providing a clear prerequisite workflow. It does not explicitly contrast with alternatives like send_message for existing conversations, but the context is sufficient for most use cases.

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

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

With no annotations, the description carries the burden of disclosing behavior. It communicates partial update semantics ('Only provide fields you want to change') and the critical replacement behavior for screening_questions. It also states authentication requirements. It does not describe side effects like re-approval or return values, but covers the most important non-obvious behaviors.

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

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

Two concise sentences that are front-loaded with the core purpose. Every sentence adds value: the first states the action, the second explains partial updates and screening_questions replacement, and the third covers authentication. No wasted words.

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

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

Despite having 14 parameters and no output schema, the description covers the essential context: what the tool does, how fields are handled (partial update), the special screening_questions behavior, and authentication. It could mention post-update consequences (e.g., approval status) but is reasonably complete for a mutation tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds a general 'only provide fields you want to change' instruction and reiterates the screening_questions full-set behavior already in the schema. It does not provide additional parameter-specific semantics 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 'Update an existing job posting on Himalayas' with a specific verb and resource. This distinguishes it from sibling tools like create_company_job and delete_company_job, and 'existing' clarifies it is for modification, not creation.

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

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

Provides clear context for use (updating an existing job) and practical guidance ('Only provide fields you want to change'). It also notes the authentication requirement. However, it does not explicitly mention alternatives or exclusions relative to tools like update_job_status, but the usage context is clear enough.

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. It discloses the authentication requirement, which is a useful behavioral note, but it omits critical mutation details such as whether fields are partially updated, side effects, return value, or reversibility. The auth requirement alone is insufficient for a write operation.

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

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

The description is a single concise sentence with no fluff, effectively conveying the tool's core purpose and a key requirement. It is appropriately sized, though it could be slightly more informative without losing conciseness.

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

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

Given the tool has 10 optional parameters, no output schema, and no annotations, the description is too sparse. It does not clarify whether updates are partial or full, what the API returns, or how parameters interact. This leaves the agent uncertain about invocation expectations.

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

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

Schema description coverage is 100%, so all 10 parameters are already documented in the schema. The description adds no additional parameter meaning or usage examples, warranting the baseline score of 3.

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

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

Description states the verb 'Update' and the resource 'your company's profile on Himalayas', clearly distinguishing it from personal profile updates (e.g., update_profile) and read-only lookups (e.g., get_company_profile). The scope is specific and 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?

Implies usage context by specifying the company profile and mentioning employer authentication, but does not explicitly state when to use this tool over alternatives or provide exclusion criteria. It gives a prerequisite but no direct guidance on 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 full burden. It discloses that technology names are 'matched to the Himalayas stack database' and that employer authentication is required. However, it does not reveal critical behavioral details such as whether the update replaces the entire stack or appends to it, nor does it address error handling or idempotency. This is a notable gap 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 three sentences, front-loaded with the main purpose, then provides the parameter usage example and an authentication requirement. Every sentence adds value; no fluff 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?

For a simple tool with one documented parameter and no output schema, the description is fairly complete: it states purpose, parameter usage, matching behavior, and authentication. However, the absence of clarity on replace-vs-append semantics is a significant gap that could cause misuse. It is adequate but lacks a key detail.

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% since the only parameter `stacks` has a clear description in the schema. The description's example ('React', 'Python') adds no new information beyond the schema. The matching behavior is mentioned but is more about the tool's processing than parameter semantics. 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 begins with 'Update your company's tech stack on Himalayas,' which clearly states the verb (update), resource (company tech stack), and platform (Himalayas). It distinguishes itself from the sibling tool 'update_tech_stack' by specifying 'company's' and 'employer authentication.'

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 usage context: it is for employers updating their company's tech stack, reinforced by 'Requires employer authentication.' It does not explicitly name alternatives or exclusions, but the 'company' context separates it from similar tools like `update_tech_stack`. This meets 'clear context, no exclusions'.

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

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

With no annotations provided, the description must carry the full burden of behavioral disclosure. It adds 'Requires authentication', which is useful, but it fails to disclose whether updates are partial or full, how missing fields are handled, what happens if the ID doesn't exist, or the return value. This is a significant gap 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 extremely concise (two short sentences) and front-loaded with the verb and resource. Every word earns its place, and the authentication note is directly relevant to the invocation. There is no fluff 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?

For a mutation tool with no annotations and no output schema, the description is incomplete. It omits key behavioral context such as partial-update semantics, error handling (e.g., invalid ID), and what the response contains. The schema covers parameter details but not the tool's runtime behavior or return value, leaving the agent under-informed.

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

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

The input schema has 100% coverage with descriptions for all four parameters, so the schema already explains the parameters. The description's mention of 'status or details' roughly maps to the schema but adds no additional meaning beyond what the schema provides, warranting the baseline score of 3.

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

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

The description clearly states the action ('Update') and resource ('a saved job's status or details'), which is specific and distinguishes it from related tools like 'update_company_job' (which targets company jobs rather than saved jobs). While it doesn't explicitly list sibling alternatives, the scope is unambiguous.

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

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

No guidance is given about when to use this tool versus alternatives. The description only mentions the action and an authentication requirement, with no mention of exclusions, prerequisites, or when a different tool should be used. The auth requirement is a precondition, not usage context.

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

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

With no annotations provided, the description carries full responsibility for disclosing mutation behavior. It only states 'Update' and 'Requires authentication', without explaining whether it performs partial or full replacement, whether missing fields are cleared, or what the response contains. This is a significant gap for a profile 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 short, direct sentences, front-loaded with the primary action and followed by a necessary prerequisite. There is no wasted wording 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?

Given the tool has 8 optional parameters, no output schema, and no annotations, the description is too sparse. It fails to convey key context such as whether the update is partial, what the expected response is, or potential side effects. While the schema covers parameter details, the overall behavioral context 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?

All 8 parameters have descriptions in the schema (100% coverage), so the schema already provides the necessary semantic information. The description itself adds no parameter-specific details, but given the high schema coverage, no additional compensation is required.

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 'Update your Himalayas profile' clearly identifies the action (update) and the target resource (the user's personal profile). This distinguishes it from sibling tools like update_company_profile or update_job_status, making its purpose unambiguous.

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

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

The description provides a prerequisite ('Requires authentication') but does not explicitly state when to use this tool over alternatives. However, the tool name and purpose make the intended use case fairly clear. No exclusionary guidance or alternative tools are mentioned, so it stops at a basic 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. It discloses that authentication is required, but does not state whether the update replaces the existing stack, appends to it, or how it interacts with other fields. This is a significant gap 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 resource, and contains no filler. It is highly concise and well-structured.

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

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

Given the tool's simplicity (one parameter, no output schema), the description is mostly adequate but lacks crucial context about the update semantics (replace vs. append). It does not fully clarify expected input behavior or side effects, leaving some uncertainty for the agent.

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

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

The input schema provides 100% coverage with a description for the 'stacks' parameter. The tool description adds no additional semantic value beyond the schema, 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 uses a specific verb ('Update') and a resource ('tech stack on your Himalayas profile'), clearly identifying the tool's function. It also distinguishes from the sibling tool 'update_company_tech_stack' by specifying 'your' profile, though it does not explicitly contrast them.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'update_company_tech_stack' or 'update_profile'. It implies usage through the verb and resource but does not state clear contexts or exclusions.

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