Search open jobs from company career sites by the country you can apply from, remote or onsite.
Scored across 5 tools
Each tool has a clearly distinct target: two entity getters (get_company, get_job), two filter-vocabulary listers (list_countries, list_roles), and one search. The only near-overlap is get_job versus search_jobs, but the distinction between fetching one job by id/URL and paging through search results is explicit in the descriptions.
All names follow a consistent snake_case verb_noun pattern: get_company, get_job, list_countries, list_roles, search_jobs. The two get_* and two list_* pairs make the convention predictable.
Five tools is well-scoped for a read-only job board: two detail lookups, two vocabulary lists, and one search. Nothing feels redundant or missing for the core purpose.
Core workflows (search jobs, inspect a job, inspect its company, discover valid filter values) are covered. The notable gap is company discovery: get_company needs an id or slug, and there is no tool to search or list companies, so agents must obtain company identifiers from job results first.
One employer by its id or page slug: name, number of open jobs, its workfinds.app page and, when known, its profile (industry, size, headquarters, founded, website, short description). Use search_jobs with company_id for its jobs.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | The company id or slug, e.g. a job's company.id. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | |
| name | Yes | |
| profile | Yes | |
| jobs_url | Yes | |
| open_job_count | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, closed-world, non-destructive, so the safety profile is covered. The description adds value beyond them by warning that profile fields are only present 'when known', implying partial/optional responses the agent must tolerate — a real behavioral cue not in 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?
A single front-loaded sentence identifies the resource and identifier, a compact parenthetical lists the payload, and a closing sentence routes to the sibling. 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?
An output schema exists, so the field enumeration is partly redundant but harmless context. Nothing an agent needs in order to call it correctly is missing; only not-found/error behavior is left implicit.
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 schema already documents the single param with a pattern and example, so baseline is 3. The description adds that a page slug is also accepted, broadening the accepted identifier types beyond the schema's job.company.id example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('One employer by its id or page slug') and enumerates the payload (name, open jobs count, page URL, profile fields), which makes it instantly distinguishable from get_job and list_roles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes job lookups away from this tool: 'Use search_jobs with company_id for its jobs.' That is a genuine alternative-selection rule. It does not state failure/precondition cases (e.g., company not found), so it falls short of full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One job by its id or its workfinds.app job URL: title, company, location, work arrangement, employment type, the countries it accepts applicants from, salary when listed, when it was posted, whether it is still open, its apply URL on the employer site and its workfinds.app page. A closed job answers with status "closed" and when it closed.
| Name | Required | Description | Default |
|---|---|---|---|
| job | Yes | The job id from search_jobs, or a https://workfinds.app/jobs/... URL. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | The job page on workfinds.app. |
| title | Yes | |
| status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description still adds real behavioral context by disclosing that a closed job does not error but answers with status "closed" plus a closing date — a non-obvious outcome an agent would otherwise have to discover by calling. It says nothing about invalid-id or not-found 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?
Two dense sentences, front-loaded with the lookup key before the field list. The long field enumeration partly duplicates the output schema and is the least-necessary part, but it stays readable and contains 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 one-parameter read tool with full annotations and an output schema, the description covers purpose, inputs and the closed-job special case. The remaining gap is error/not-found behavior, and the return-field list is somewhat redundant given the output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'job' parameter, and the description merely restates the accepted forms (id or workfinds.app URL) without adding format or validation detail. Baseline 3 applies since the schema does the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource and access pattern: 'One job by its id or its workfinds.app job URL', immediately distinguishing it from the sibling bulk tool search_jobs. The field enumeration that follows pins down exactly what a single-job retrieval yields, so an agent knows what it gets without opening the output schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the single-job-by-id framing plus the schema note that the id comes 'from search_jobs' tells an agent this is the follow-up call after a search. The description itself never says when to use this versus search_jobs or the list_* siblings, and gives no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The country codes search_jobs accepts, with their English names.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| countries | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered elsewhere. The description adds only that the list is the accepted set for search_jobs, which is mildly useful context but not rich behavioral detail; with a full annotation set, a 3 is appropriate.
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 short sentence with no waste, and the key fact (these are the codes search_jobs accepts) 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?
An output schema exists, so return values need not be explained, and the description still states what the list contains (codes plus English names). For a zero-parameter lookup tool with full annotations, this is essentially complete; only the implied workflow with search_jobs could be spelled out.
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, so the baseline is 4 and there is nothing for the description to compensate for. The description correctly adds no parameter detail, which is consistent with the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names the exact resource (country codes with English names) and ties it to the sibling that consumes it (search_jobs accepts). Slightly noun-phrase in form rather than a verb+resource statement, but an agent can immediately tell what it returns and why it exists.
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 connection to search_jobs implies the intended use (fetch valid codes before searching), but there is no explicit when-to-use or when-not-to-use guidance, and no mention of the other siblings like list_roles or get_job.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The role families search_jobs accepts as role.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| roles | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the safety profile is fully covered by structured data. The description adds the useful linkage to search_jobs but says nothing about return format, ordering, or whether the list is static; with a rich annotation set, this is adequate rather than exceptional.
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 short sentence with no filler, and the key information (these are role values for search_jobs) is front-loaded. It is slightly telegraphic — a lead verb would cost one word and remove the fragment feel.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description needn't describe the returned structure, and no parameters exist to document, so almost nothing is missing. The only gap is that it doesn't hint the values are a fixed enumeration suitable for validation, but the output schema likely carries that.
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, so there is nothing for the description to disambiguate; baseline for a nullary tool applies. The sentence correctly frames the output as input to another parameter rather than pretending there is an argument here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states precisely what the tool returns — the set of role family values — and ties it to the sibling that consumes it (search_jobs' role parameter). It lacks an explicit verb like 'List', but the resource and scope are unambiguous, so an agent can distinguish it from get_job/get_company.
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?
By naming search_jobs and its 'role' argument, it tells the agent exactly when this tool is useful: before filtering jobs by role. It does not spell out exclusions or an explicit 'do not use for X', keeping it just below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search open jobs on workfinds.app. Returns at most 50 jobs per search, in pages of 20 (pages 1 to 3), newest first unless sort is "relevance", each with a workfinds.app page URL, plus the total and a search_url that opens the same search on the site. Every argument is optional; combine them to narrow the search.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Result page, 1 to 3. | |
| role | No | A role family, see list_roles. | |
| sort | No | newest (default) or relevance (only with a query). | |
| query | No | Words to search for: a job title, skill or company name, e.g. "data engineer". | |
| country | No | ISO 3166-1 alpha-2 code of the country the person will work from, e.g. "PH". Returns jobs open to applicants from that country, worldwide remote jobs included. See list_countries. | |
| company_id | No | Only this company's jobs: the id or page slug from get_company or a job's company. | |
| posted_within | No | Only jobs published within the last 24h, 3d, 7d, 14d or 30d. | |
| salary_listed | No | Only jobs whose employer lists a salary. | |
| employment_type | No | Any of full_time, part_time, contract, temporary, internship. | |
| work_arrangement | No | Any of remote, hybrid, onsite. |
| Name | Required | Description |
|---|---|---|
| jobs | Yes | |
| page | Yes | |
| total | Yes | Matching open jobs. |
| search_url | Yes | The same search on workfinds.app. |
| total_pages | Yes | |
| total_is_lower_bound | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds real behavior: result cap of 50, 20-per-page with only pages 1-3 available, default ordering of newest-first, and that sort=relevance only applies with a query. It doesn't mention rate limits or empty-result behavior, but the pagination and default-sort disclosure is substantive.
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 first sentence front-loads purpose, then pagination, then return contents, then the optional-args note. It's a single dense paragraph with no wasted clauses, though the run-on enumeration of return fields makes it slightly harder to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-param, fully-optional search tool, the description covers scope, pagination ceilings, default ordering, filter combinability, and return shape. With an output schema present and 100% schema coverage, nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter is documented in-schema (including the sort default and page bounds). The description largely restates those constraints rather than adding syntax or cross-parameter rules (e.g. that relevance requires query is already in the schema), so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Search open jobs on workfinds.app") plus scope limits (max 50 results, pages 1-3). The plural/search framing clearly separates it from single-record siblings get_job and get_company.
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?
"Every argument is optional; combine them to narrow the search" gives clear usage context for the filter set. It stops short of explicit exclusions (e.g. "use get_job for a specific posting, list_roles to discover role values"), so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_companyget_joblist_countrieslist_rolessearch_jobsSearch remote jobs from company career pages by title, location, seniority, salary, and tech stack.
Search remote jobs by the country they hire from, and jobs with relocation or visa sponsorship.
Open jobs from 20,000+ company career sites: search, list a company's roles, read full job ads
Search open jobs from employers' own career sites: roles, companies and posting status.
Add one secure layer between your agents and this server.