Jobs by Workable

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so safety behavior is covered. The description adds that the response includes open job listings, but no additional behavioral traits such as rate limits, authorization needs, or payload size are disclosed. This is acceptable for a simple read tool but does not exceed the annotation baseline meaningfully.

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

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

A single, information-dense sentence that front-loads the verb and resource, immediately specifies the required identifier, and adds the relevant extra return content. There is no filler, repetition, or unnecessary detail.

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

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

For a one-parameter read-only tool with a full output schema and complete annotations, the description is sufficient. It covers what the tool returns, how to identify the company, and is consistent with the sibling tool landscape. No additional context is 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?

Schema description coverage is 100%: the only parameter, companyId, is already fully documented in the schema, including accepted id formats and how the id is returned by other tools. The tool description adds no new parameter information, 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 states a specific action ('Get the full profile of a company') and a clear resource, with a precise identifier format ('Workable UUID or database _id'). It also adds scope ('including open job listings') and is easily distinguishable from sibling tools like get_job, which target jobs rather than company profiles.

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

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

The description clearly implies when to use the tool: when an agent needs a company's full profile or open job listings by company id. It does not explicitly list exclusions or name alternative tools, but the context is unambiguous given the sibling set and the specific id-based retrieval.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the useful context that only published jobs are accessible and that it returns full details, but it does not disclose additional behavioral traits such as error behavior or unpublish edge cases. This is adequate but not rich.

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

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

A single sentence that is entirely relevant and clearly structured. It states the action, the target resource, the scope, and the required identifier without any filler, making it easy for an agent to parse quickly.

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

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

The tool has one documented parameter, a read-only annotation set, and an output schema. The description supplies the remaining needed context: it fetches full details of a single published job by UID. Nothing essential is missing 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 input schema has 100% coverage for the single parameter, uid, including its type and accepting full or shortened forms. The description essentially restates the parameter's purpose without adding material new meaning, 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 specifies a precise verb and resource: getting the full details of a single job by its advertising UID. It clearly distinguishes this from sibling tools like search_jobs or get_company by focusing on a single job and a unique identifier.

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

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

The description clearly implies when to use the tool: when you have a job's advertising UID and need full details for that specific job. It does not explicitly mention when not to use it or name alternatives, but the context is clear enough for an agent to select it correctly.

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

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

Annotations already declare readOnlyHint and destructiveHint, covering the safety profile. The description adds useful behavioral details about optional filtering and pagination via after_key, going beyond the structured annotations.

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

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

The description is compact and front-loaded: the core purpose appears in the first sentence, followed by filtering and pagination behavior. Every sentence adds value without redundancy.

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

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

For a read-only list tool with output schema, annotations, and full schema coverage, this description is complete. It conveys what the tool returns, how to filter, and how pagination works, with no critical missing context.

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

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

Schema description coverage is 100%, so parameters are already documented in the schema. The description summarizes query filtering and pagination but does not add substantial meaning beyond the schema's own 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 uses a specific verb ('List') and clearly identifies the resource ('city/country pairs where jobs are published'). It distinguishes this tool from siblings like get_job and search_jobs by focusing on locations rather than individual jobs or search results.

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

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

The description gives clear context: use this tool to list location pairs where jobs are published, with optional filtering by city/country name. It does not explicitly name alternatives or state when not to use it, but the use case is unambiguous.

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

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

Annotations already mark this as read-only and non-destructive, so the safety profile is covered. The description goes further by disclosing exact response fields (jobOpen, isWithdrawable), the limitation that pipeline stages are not tracked, and the nuance that applications with isWithdrawable=false can still be withdrawn via email but not MCP. No annotations are contradicted.

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

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

The description is efficiently front-loaded with the core purpose, then adds high-value behavioral details in compact sentences. Every sentence earns its place: fields returned, withdrawability semantics, email caveat, and pipeline-stage limitation. There is 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?

The tool is simple (one optional parameter) and has a rich output schema, so the description does not need to explain return values. It covers ordering, pagination, field semantics, edge behavior around withdrawal, and explicitly states a limitation. An agent has everything needed to select and invoke it correctly.

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

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

Schema coverage is 100%, and the single page parameter is fully described in the schema with type, default, minimum, and meaning. The description's mention of pagination adds context but does not introduce parameter semantics beyond the schema, so the baseline of 3 applies.

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

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

The description opens with a specific verb and resource: 'List your submitted job applications,' and adds ordering ('most recent first') and pagination. It clearly differentiates from sibling tools like search_jobs and get_my_profile by focusing on applications, and it references withdraw_application as a related but distinct 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 clearly indicates this tool is for listing your own submitted applications. It also provides situational guidance around isWithdrawable, telling the agent when an application can or cannot be withdrawn via the withdraw_application tool. It does not explicitly name alternatives for listing applications, but no sibling directly competes, so the context is sufficient.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to restate safety. It adds some context by listing the profile fields returned, but it does not disclose any additional behavioral traits such as authentication requirements or response structure. The output schema covers return shape, so this is adequate but not rich.

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

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

The description is a single, efficient sentence with no filler words. It front-loads the action and resource, then enumerates the contained fields in a natural list. Every part contributes meaningful 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 read-only, zero-parameter profile retrieval tool, the description fully covers what the agent needs: the resource and its key contents. An output schema is present, so return-value details are already structured. Annotations cover safety, and there are no complex behaviors left unexplained.

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 there are no parameter semantics to explain. With no input schema properties, the description does not need to compensate for schema gaps; the baseline of 4 applies.

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

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

The description uses a specific verb ('Get') on a clear resource ('your candidate profile') and lists the main fields it returns (name, contact details, headline, summary, resume, education, experience). It is immediately distinguishable from sibling tools like get_job or get_company because it is scoped to the user's own 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 clearly implies when to use this tool: whenever the agent needs the caller's own candidate profile data. It does not explicitly state when not to use it or mention alternatives like update_my_profile, but the 'my' scoping and sibling names make the intended use 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?

Annotations already cover readOnlyHint=true and destructiveHint=false, so the description does not need to restate safety. It adds useful behavior beyond annotations: results are 'tailored to your last known location' and each item includes 'a URL to run each search.' These are concrete behavioral traits not available from structured fields.

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

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

A single, front-loaded sentence that states the core action first and then adds two relevant qualifiers. Every phrase earns its place and there is no filler.

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

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

For a zero-parameter, read-only tool with an output schema present, the description is complete. It explains what will be returned conceptually, mentions the location context, and notes the actionable URL, leaving no material gap for an agent to call it correctly.

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

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

The tool has zero parameters and schema coverage is 100%, so there is nothing for the description to clarify. The baseline for no-parameter tools is 4, and the description appropriately focuses on behavior rather than inventing parameter information.

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

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

The description opens with 'List popular/recent job search terms', which states a specific verb and resource. It adds meaningful detail—location tailoring and a URL for each search—that clearly separates it from siblings like search_jobs or get_recommendations.

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 a use case—when you want popular or recent search terms—but it never explicitly tells the agent when to choose this tool over alternatives. It does not mention sibling tools like search_jobs or provide when-not-to-use guidance, so the agent must infer the boundary.

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

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

Beyond the read-only annotation, the description reveals meaningful behavior: recommendations are matched to profile, exclude jobs already applied to, and fall back to location-based results if the profile is incomplete. This is exactly the kind of behavioral context that helps an agent predict tool behavior.

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

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

Three sentences, each earning its place: purpose, matching/filtering behavior, and fallback behavior. The most important information is front-loaded and the description is free of filler.

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

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

Given the output schema is present and the annotations already signal a safe read-only operation, the description is complete. It covers the core use case, filtering behavior, fallback logic, and leaves pagination semantics to 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 already fully documents both parameters (limit and pageToken) with descriptions. The description adds no parameter-specific meaning, but with 100% schema coverage, 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 uses a specific verb and resource: 'Get personalized job recommendations'. It clearly states what the tool returns and differentiates it from general job search and application-related tools by mentioning profile matching and exclusion of already-applied 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?

The description gives clear context: this is for personalized, profile-matched recommendations, not general search or application history. It does not explicitly name alternatives or state when not to use it, but the use case is well defined.

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

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

Annotations already establish readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so no safety disclosure is needed from the description. The description adds the scope 'published jobs' and the Workable board context, which clarifies what data is included, but it does not disclose additional behavior such as pagination or default sorting (the schema covers pageToken).

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. Every word contributes to the core purpose; it is appropriately brief and easy to scan.

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

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

The description is minimal, but the extensive input schema and output schema already provide parameter and return details. However, it lacks contextual guidance about when to call this tool instead of other job-related siblings, which is relevant given the wide sibling set. Overall 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% and every parameter (query, location, companyId, day_range, pageToken, workplace, employment_type) has a descriptive schema entry. The tool description itself adds no parameter explanation, but the schema fully carries the meaning, so a baseline of 3 is appropriate.

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

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

The description uses a clear verb ('Search') and resource ('published jobs on the Workable job board'), making the tool's basic purpose immediately understandable. It does not explicitly contrast with sibling tools like get_job or get_recommendations, so it could be clearer on differentiation, but the search 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?

The description offers no guidance on when to use this tool versus siblings such as get_job (single job lookup) or get_recommendations (personalized suggestions). The intended use is only implied by the word 'search' and the tool name; there are no exclusions, prerequisites, or alternative-selection criteria.

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

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

The annotations already declare destructiveHint=true, and the description adds no behavioral context beyond that. It does not disclose that the education and experience arrays fully replace existing lists, nor what happens when no parameters are supplied.

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

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

A single, front-loaded sentence with no wasted words. The verb and resource come first, followed by a concise list of the updateable areas.

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

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

The schema and annotations carry most of the burden: all parameters are described, destructive behavior is flagged, and an output schema is present. Still, the description alone leaves ambiguity around partial updates, full replacement semantics for education/experience, and the lack of required parameters.

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

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

Input schema coverage is 100%, so the schema already documents all parameters thoroughly. The description's field list loosely maps to the schema (location→address, name→firstname/lastname) but adds little semantic value beyond what the schema provides.

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

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

The description states a specific verb ('Update') and a clear resource ('your candidate profile'), then enumerates the touched fields: name, phone, location, education, and work experience. It is obviously distinct from the read-only sibling get_my_profile, though it does not explicitly name that alternative.

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

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

Usage is implied: use this tool when the candidate's profile fields need to be changed. However, there is no explicit 'when to use' guidance, no mention of get_my_profile for reading current data first, and no warning about whether omitted fields are preserved or cleared.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true. The description adds value beyond these by explicitly stating that the action 'cannot be undone from here,' alerting the agent to irreversibility. It also scopes the operation to submitted applications, providing useful behavioral context without contradicting the annotations.

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

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

Two short sentences deliver the essential information: what the tool withdraws, how the target is identified, and the critical irreversibility warning. Every sentence earns its place, and the key verb is front-loaded.

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

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

For a simple one-parameter destructive tool, the combination of the main description, detailed parameter schema, destructiveHint annotation, and output schema is sufficient for correct invocation. The irreversibility warning compensates for the tool's destructive nature, and no critical missing guidance is apparent.

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

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

Schema description coverage is 100%: the input schema already explains that applicationId comes from get_my_applications and that only applications with isWithdrawable true can be withdrawn. The main description only restates 'by its application id,' adding minimal semantic 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 uses a specific verb ('Withdraw'), a concrete resource ('submitted job applications'), and identifies the key parameter ('by its application id'). It clearly distinguishes this from sibling getter tools and update_my_profile, leaving no ambiguity about its 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 clearly implies when to use the tool: when the user wants to withdraw one of their already submitted applications. It also adds a caution that the action cannot be undone. It does not explicitly name alternatives, but there are no direct sibling alternatives for withdrawal, and the input schema further constrains usage to withdrawable applications.

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