Search worldwide remote jobs with USD pay and Indonesia-friendly roles, read job details, and get free top rows of salary, skill-demand and hiring-trend data. No API key or sign-up. Employer talent search, shortlists, job posts and full market-data depth are sold per call on Apify: https://apify.com/kelvindesman/job-market-intelligence-mcp
Scored across 12 tools
Seeker-side tools (search_jobs, get_job, apply_to_job, draft_application) are distinct, but the employer trio hire, match_candidates, and talent_search all return ranked anonymized candidate shortlists and require query/skills/roles, making boundaries blurry. Descriptions differentiate them somewhat (hire also emails and can post a role; talent_search gives a fit breakdown), but an agent could easily pick the wrong one.
Almost all names are snake_case and verb-led (apply_to_job, buy_dataset, get_job, get_me, match_candidates, post_job, search_jobs), forming a predictable pattern. Minor deviations are the single-verb advertise and hire, plus the noun-first talent_search.
Twelve tools is well within a healthy range for a dual-sided job marketplace, and each covers a distinct operation or monetization path. No filler tools are present.
The surface covers search, apply, drafting, skill demand, matching, hiring, posting, and monetization, which is a broad span. However, there is no way to list/track submitted applications or manage/edit/close a posted job, leaving notable lifecycle gaps that could stall an agent's workflow.
Advertiser tool. Buy one monthly ad on Loker Dollar (rotates site-wide for 30 days). Sold through the Apify listing only: the run's pay-per-event charge is the payment. The creative passes an automatic check before it serves; a confirmation goes to contact_email.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Landing page (http/https). | |
| body | No | Optional, ≤200 chars. | |
| locale | No | `en` (default) or `id` for the emails. | |
| market | No | `indonesia` or `global` (optional). | |
| cta_url | No | Optional CTA link; defaults to `url`. | |
| cta_text | No | Optional, ≤40 chars. | |
| headline | No | Optional, ≤80 chars. | |
| contact_name | Yes | Your name. | |
| business_name | Yes | Advertiser name. | |
| contact_email | Yes | Your email. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses important behavior: payment via pay-per-event charge, a 30-day site-wide rotation, an automatic creative check before serving, and a confirmation email. It does not cover failure modes if the creative check fails, so it is strong but not exhaustive.
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 compact sentences and front-loads the core action. The opening 'Advertiser tool' is slightly redundant but sets category quickly; every sentence contributes useful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter mutation tool with no annotations and no output schema, the description covers payment, duration, validation, and confirmation channel. It leaves some behavioral gaps around failed validation and response handling, but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 10 parameters. The description adds some context around the creative and contact email, but does not provide additional parameter-level syntax or constraints 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 states a specific verb and resource: 'Buy one monthly ad on Loker Dollar,' with duration and rotation scope. This is clearly distinct from all job/application/dataset siblings.
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 explains the purchase channel and payment mechanism ('Sold through the Apify listing only'), which implies usage context. However, it does not explicitly state when to use this versus alternatives or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply to a job. Only works on keys that already hold apply credits; spends 1 credit. Jobs with an employer contact are submitted into our curate queue (returns an applicationId); external-ATS jobs return the apply URL for the agent to open and finish.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Job id to apply to, e.g. `job_8f2a1c`. | |
| locale | No | id | en (default id). | |
| message | Yes | Cover note, 80–3000 chars. | |
| resume_url | No | Public http(s) resume URL. | |
| candidate_name | Yes | Applicant full name (1–120 chars). | |
| candidate_email | Yes | Applicant contact email the employer can reply to. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses cost (spends 1 credit), a precondition (credits must exist), and — critically — that the outcome is not uniform, describing both the curate-queue path and the external-ATS path with different return shapes. Missing: whether the operation is idempotent/retryable and whether a failed attempt still consumes a credit.
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 short sentences, front-loaded with the action, then the constraint, then the divergent outcomes. No filler and no 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 mutation tool with no annotations and no output schema, the description covers the essential risks an agent needs: credit spend, precondition, and that the return value differs by job type. It stops short of covering failure behavior and the draft-then-apply workflow, which would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter (id, locale, message, resume_url, candidate_name, candidate_email) is already documented in the schema with formats and length bounds. The description adds nothing parameter-specific, 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?
States a specific verb and resource ('Apply to a job') and then distinguishes two execution paths — curate-queue submission returning an applicationId versus external-ATS jobs returning a URL. This is clearly separable from siblings like draft_application or get_job.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a hard precondition ('Only works on keys that already hold apply credits'), which is genuinely useful gating information. However, it never routes the agent to alternatives — draft_application is an obvious sibling (prepare vs. submit) and is not mentioned, and there is no guidance on when to prefer drafting or fetching the job first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Buy the full active Loker Dollar job dataset (CSV: title, company, location, remote type, salary, skills, posted date). Sold through the Apify listing only: the run's pay-per-event charge is the payment. Returns a download link valid 24 hours.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses the key behavioral traits: this is a paid purchase, the charge happens via pay-per-event, and the returned download link is valid for 24 hours. It could further clarify irreversibility or authentication needs, but the financial side effect and link expiry are clearly stated.
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: it states what is bought, what the CSV contains, how payment works, and what is returned. Every clause adds 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?
Given the lack of parameters, annotations, and output schema, the description provides enough context to call the tool: dataset contents, payment model, and return value. Minor gaps such as link regeneration or auth requirements remain, but the essential behavior is covered.
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 is nothing for the description to disambiguate. The baseline for a parameterless tool 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 and resource: buy the full active Loker Dollar job dataset. It lists the exact CSV fields included, so an agent can distinguish this dataset-purchase tool from sibling job-search and application tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states the purchase channel and payment mechanism: only through the Apify listing, with the run's pay-per-event charge serving as payment. It does not explicitly compare this tool to alternatives like search_jobs, but the intended 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.
Draft a grounded cover letter and a tailored plain-text resume for one job from the key owner's saved resume. Every claim is checked against the resume; unsupported claims are removed or the call fails with ungrounded. Returns the apply URL and, when enabled, a reply-to address that routes employer replies back to the seeker. Nothing is submitted — the seeker applies by hand. Free on every tier; monthly AI quota applies.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Job id, e.g. `job_8f2a1c`. | |
| parts | No | Default both. | |
| locale | No | id | en (default: the account's preferred locale, else id). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so: it discloses the grounding enforcement ('Every claim is checked against the resume'), the failure mode (`ungrounded`), that unsupported claims are stripped, side-effect freedom ('Nothing is submitted'), and the pricing/quota constraint ('Free on every tier; monthly AI quota applies'). That is auth/cost/safety/destructive-behavior coverage in one paragraph.
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?
Five short sentences, front-loaded with purpose, then grounding behavior, return values, the non-submission guarantee, and cost. No sentence is redundant with another and the most decision-relevant fact (no submission) is placed where it will be read.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description compensates by naming the return payload (apply URL, optional reply-to address) and the `ungrounded` failure. Gaps remain around quota consumption on regeneration, whether a re-draft overwrites a prior draft, and idempotency, but the essentials for correct invocation are 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?
Schema description coverage is 100%, so `id`, `parts`, and `locale` are already documented with defaults and examples. The description adds only general framing ('for one job', 'from the key owner's saved resume') and mentions an optional reply-to address, but nothing about `parts` selection trade-offs or `locale` behavior beyond the schema. 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?
Specific verb and dual resource ('Draft a grounded cover letter and a tailored plain-text resume') scoped to 'one job' from the owner's saved resume. The line 'Nothing is submitted — the seeker applies by hand' cleanly separates it from the write-oriented sibling apply_to_job, so an agent can route without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is clear: drafting one application package against one job, with the explicit exclusion that nothing is submitted, which implicitly routes submission elsewhere. It does not name apply_to_job directly or state prerequisites (e.g., whether the seeker must already have a saved resume), so it falls just short of full when/when-not/alternative coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a single active job by id. Returns basic job fields + an apply URL.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Job id, e.g. `job_8f2a1c` (from a search_jobs result's `id`). | |
| locale | No | id | en (default id). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden, and it does add useful signals: the lookup is restricted to 'active' jobs and the response includes basic fields plus an apply URL. It stops short of stating behavior for missing/expired ids, errors, auth needs, or rate limits, which matters for an unannotated 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 sentences, no filler, with the core operation front-loaded and the return shape appended as secondary 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 two-parameter read tool with no output schema, the description covers what it does and roughly what comes back, which is sufficient to call it correctly. The gaps are minor: locale is unmentioned and the 'active only' constraint's consequence for non-active ids is left unstated.
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 both parameters are already documented, including the id format and its provenance from search_jobs results. The description adds nothing beyond 'by id' and never mentions the optional locale parameter. Baseline 3 applies when 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?
States a specific verb and resource with scope: fetch a single active job by id. This implicitly separates it from the discovery-oriented sibling search_jobs, but it never names that sibling or any other alternative explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by the phrase 'by id' — an agent can infer this is the follow-up call once it has a job id. There is no explicit when-to-use, when-not-to-use, and no alternative named among the eleven siblings such as search_jobs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the caller's tier, granted scopes, remaining apply credits, and per-tier limits (rate limit, max page, apply-enabled, ad-free). Call this before apply_to_job to confirm you can apply.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden, and it does well: it implies a read-only identity/preflight probe with no side effects and documents the returned content. It stops short of stating auth requirements or failure behavior (e.g., unauthenticated calls).
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, both earning their place: the first enumerates the return payload, the second states the preflight purpose. The return contents are front-loaded before the usage cue.
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?
No output schema exists, so the description must enumerate return fields, which it does in detail (tier, scopes, credits, rate limit, max page, apply-enabled, ad-free). What is missing is any statement of error/edge behavior, but for a zero-parameter read tool this 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 tool takes zero parameters, so there is nothing for the description to disambiguate beyond what the empty schema already communicates. Baseline 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 states a specific verb-and-resource combo ('Return the caller's tier, granted scopes, remaining apply credits, and per-tier limits') and enumerates the exact payload fields. This clearly differentiates it from the job/candidate-oriented siblings, though the verb 'Return' is slightly passive compared to the resource specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit trigger: 'Call this before apply_to_job to confirm you can apply,' naming the sibling and the condition that selects it. It does not state when NOT to call it or note alternative preflight paths, keeping it just 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.
Top in-demand skills across our active remote-job corpus (Indonesia-reachable postings), by mention count. Same data as GET /api/v1/market/skills. A key without paid market access gets the free layer (top rows, free_layer: true, paid_depth_url).
| Name | Required | Description | Default |
|---|---|---|---|
| top_n | No | 1–100 (default 25). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and largely succeeds: it discloses the underlying data source and population (active remote-job corpus, Indonesia-reachable), and explains tiered access behavior — unprivileged keys get top rows plus `free_layer: true` and a `paid_depth_url`. Rate limits and auth mechanics are not covered, keeping it below a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the purpose before the endpoint mapping and tier behavior. No filler, though the endpoint reference and the tier sentence could be tighter.
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 optional-parameter read tool with no output schema or annotations, the description covers the data population and the paid/free response variation, which are the main things an agent needs. It stops short of describing the row fields (skill name, mention count) beyond the two flags.
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 `top_n` is documented there with its 1–100 range and default of 25, so the schema does the heavy lifting. The description adds no meaning about how top_n interacts with the free-layer truncation, which would have been the valuable addition.
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 specifically that this returns top in-demand skills by mention count, scoped to an active remote-job corpus filtered for Indonesia-reachable postings. That is enough to distinguish it from job-search siblings like search_jobs or talent_search, though it never uses an explicit verb like 'list' or 'returns'.
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 conveys the domain of use (market demand statistics) and cross-references the equivalent REST endpoint, which helps an agent recognize the data shape. But it never says when to prefer this over the sibling market/recruiting tools, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Employer tool, one call. Describe who you need to hire. If at least 3 consented candidates in the Loker Dollar pool match strongly, you get an ANONYMIZED shortlist back (opaque ids, headline, region, skills, 0–100 score — no PII) and the same shortlist is emailed to contact_email. If the pool has no strong match, the result says so; ask the user whether to post the role free on the Loker Dollar network, then call again with publish_if_no_match=true — the listing goes live automatically when it passes our scam check, and every applicant is forwarded to contact_email.
| Name | Required | Description | Default |
|---|---|---|---|
| brief | Yes | Who you need, in plain words: role, must-have skills, seniority, remote/location, budget if you have one (30–4000 chars). | |
| locale | No | `en` (default) or `id` for the email language. | |
| location | No | Optional, e.g. `Remote — APAC` or a city. | |
| apply_url | No | Optional. If set, applicants are sent there; otherwise Loker Dollar hosts the apply form and forwards each applicant to contact_email. | |
| is_remote | No | Default true. | |
| company_name | Yes | Company name. | |
| contact_name | Yes | Your name. | |
| contact_email | Yes | Your work email. The shortlist (or the listing confirmation) goes here. | |
| publish_if_no_match | No | Only after the user confirms: post the role as a free listing when the pool has no strong match. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so well: it discloses the anonymized shortlist fields, the absence of PII, the contact_email side effect, the minimum strong-match threshold, and the automatic publishing/applicant-forwarding behavior when publish_if_no_match is used.
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 opening sentence front-loads the tool's purpose and the rest is dense but relevant. It is a single long paragraph, which makes it slightly harder to scan, but every sentence contributes useful workflow or side-effect 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 nine-parameter tool with no output schema and no annotations, the description covers the return shape, privacy behavior, email side effect, conditional publishing path, and scam-check behavior. An agent has enough context to invoke it correctly and to know when a follow-up confirmation call is needed.
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 nine parameters are already documented in the schema. The description reinforces the role of contact_email and the confirmation condition for publish_if_no_match, but it does not add materially new syntax or meaning beyond the schema 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 states a specific employer action: submit a hiring brief to get an anonymized shortlist from the Loker Dollar pool, with a fallback to publish the role. This is clearly distinguishable from adjacent tools like post_job or match_candidates because it describes a one-call end-to-end hiring flow and its conditional listing behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit workflow guidance for the no-match case: ask the user before retrying with publish_if_no_match=true, and explains that the listing then goes live after the scam check. It does not explicitly compare when to use hire versus siblings such as match_candidates or talent_search, which keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Employer tool. Return a ranked, ANONYMIZED shortlist of consented candidates open to work, matching a role. No PII is returned (no email/name/salary/resume) — each candidate has an opaque id, coarse profile, a 0–100 relevance score, and privacy-safe facts (work auth, sponsorship, notice, skill-years). Provide at least one of query/skills/roles.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 1–25 (default 8). | |
| query | No | Free-text hiring brief or pasted job description. | |
| roles | No | Target job titles, e.g. ["Senior Frontend Engineer"]. | |
| skills | No | Required skills, e.g. ["react", "typescript"]. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does it well: it discloses the anonymization guarantee, enumerates what is NOT returned (email/name/salary/resume), and specifies the returned shape (opaque id, coarse profile, 0–100 score, privacy-safe facts). It stops short of auth requirements, rate limits, or whether results are stable across calls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the employer framing and immediately followed by the privacy contract, which is the highest-value information. Dense but no wasted clauses; the parenthetical PII list earns its space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description must explain return values on its own, and it does so specifically. What is missing is behavioral context on result limits beyond the schema's 1–25 note and the relationship to sibling candidate tools.
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 and each parameter is already documented with examples. The description does add one genuine constraint not expressible in the schema — that at least one of query/skills/roles must be supplied despite zero required params — but otherwise adds little beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: return a ranked, anonymized shortlist of consented candidates matching a role. Scope and audience (employer) are clear. It never names talent_search or buy_dataset, so the agent gets no explicit differentiation from the closest sibling.
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?
Establishes employer context and a hard precondition ("Provide at least one of query/skills/roles"), which is real usage guidance. But it gives no when-to-use-this-vs-talent_search guidance and no exclusions, so routing between candidate-matching siblings is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Employer tool. Create a job-post order and get back a checkout link (Mayar, IDR). Defaults to the Standard tier; the free pilot goes to manual review. apply_url is required unless host_apply_form is true.
| Name | Required | Description | Default |
|---|---|---|---|
| currency | No | e.g. USD, IDR. | |
| location | Yes | e.g. `Remote — APAC` or a city. | |
| apply_url | No | Where candidates apply (required unless host_apply_form). | |
| is_remote | No | Default true. | |
| job_title | Yes | Role title (1–200 chars). | |
| salary_max | No | Optional. | |
| salary_min | No | Optional. | |
| description | Yes | Role description (30–10000 chars). | |
| product_key | No | employer_standard (default) | employer_pilot_free | employer_featured | employer_premium. | |
| company_name | Yes | Company name. | |
| contact_name | Yes | Your name. | |
| contact_email | Yes | Your work email. | |
| host_apply_form | No | Let Loker Dollar host the apply form and forward applicants. | |
| company_logo_url | No | Optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does meaningful work: it discloses that the call produces an order plus an external checkout link via Mayar in IDR, that the free pilot is gated by manual review, and the conditional requirement between apply_url and host_apply_form. Missing are permission requirements, what happens on payment abandonment, and whether reposting the same job creates duplicates.
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 short sentences, zero filler, front-loaded with the actor and the operation before the conditional rule. Every sentence contributes a distinct fact: purpose, return value/payment context, default tier, and the conditional 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?
For a 14-parameter creation tool with a fully documented schema and no output schema, the description adequately covers what is produced (checkout link) and the one cross-field constraint that could trip an agent. It is slightly thin on post-call behavior — pricing, order status, or what to do with the returned link — which is the only real gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 14 parameters (including product_key enum-like values and char limits) are already documented. The description restates the apply_url/host_apply_form conditional that the schema also states and reaffirms the default tier, adding little beyond the structured fields. 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 ('Create a job-post order') and adds the concrete outcome ('get back a checkout link'), so the agent knows this is the employer-side posting flow rather than the candidate-side apply_to_job or draft_application. It signals audience with 'Employer tool' but never names a sibling explicitly, so differentiation is inferential rather than stated.
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 useful context about which product/tier applies by default (Standard) and what happens with the free pilot (manual review to handle). It does not say when to prefer this over 'advertise' or 'hire', nor any prerequisites such as being authenticated as an employer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search active remote / Indonesia-friendly jobs. Returns basic job fields + an apply URL. On the free tier, results may include promoted listings labeled sponsored: true.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Free-text query (title, company, skills). | |
| limit | No | 1–50 (default 20). | |
| locale | No | id | en (default id). | |
| offset | No | Result offset for pagination. | |
| job_type | No | full-time | part-time | contract | freelance | |
| location | No | Location text filter. | |
| remote_type | No | worldwide | regional | timezone-based | |
| opportunity_type | No | regular | internship | fellowship | apprenticeship | volunteer | gig (default: regular) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the return shape ('basic job fields + an apply URL') and a monetization caveat about promoted listings on the free tier, but says nothing about pagination behavior, rate/quota limits beyond the 'free tier' hint, or result ordering.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with purpose and scope, each adding distinct information (scope, return shape, sponsored caveat). 'Basic job fields' is the only slightly imprecise phrase.
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?
Adequate for a no-required-param search tool: it covers purpose, return contents, and a caveat, and the schema handles parameter detail. It omits result ordering, pagination strategy, and any sibling routing, which leaves an agent with gaps for an eight-parameter 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 schema already documents all eight parameters including defaults and pagination via offset. The description adds only marginal semantic value through the 'Indonesia-friendly' framing, which loosely relates to locale/location but does not clarify how parameters interact.
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 (Search) and resource (jobs) with a narrowing scope: 'active remote / Indonesia-friendly'. An agent can distinguish it from get_job (single job) and talent_search (candidates) by scope, though no sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The domain scope implies when to use it ('remote / Indonesia-friendly jobs'), but there is no explicit when-not guidance and no routing to alternatives such as get_job for a known job ID. Usage must be inferred from the scope phrase.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Employer tool. Talent search from plain words: describe who you need and get the match count plus up to 10 ANONYMIZED cards (opaque code, role, years, top skills, city, 0–100 explainable fit with per-component breakdown, and a tier of exact/close/broader; the result says when it was widened). Never returns name, contact, CV or salary, and results cannot be exported. Free; limited to 50 calls per day per key. Provide at least one of query/skills/roles.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 1–10 (default 10). | |
| query | No | Who you need, in plain words (up to 2000 chars). | |
| roles | No | Target job titles, e.g. ["Admin"]. | |
| skills | No | Required skills, e.g. ["laravel", "mysql"]. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses anonymization, excluded fields (name, contact, CV, salary), non-exportability, free usage, a 50-calls/day/key limit, widening behavior, and the fit-component breakdown. These are exactly the behavioral constraints an agent needs before invoking the 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?
Despite being dense, the description is front-loaded with purpose and output shape, then moves through privacy, limits, and required inputs in a compact, information-rich paragraph with 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?
There is no output schema and no annotations, so the description must explain output, privacy, limits, and usage requirements. It does all of these, including match count, card fields, anonymization, rate limit, and widening notice.
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 adds the important cross-parameter constraint that at least one of query/skills/roles must be supplied, which is not evident from the zero required parameters alone.
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 gives a specific verb and resource ('Talent search from plain words') and describes the output, scope, and employer context clearly. It does not explicitly differentiate itself from the similar sibling match_candidates, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states that at least one of query/skills/roles must be provided and frames this as an employer talent-search tool. However, it does not explain when to use this versus match_candidates or other siblings, nor does it provide explicit exclusions.
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.
advertiseapply_to_jobbuy_datasetdraft_applicationget_curated_listget_job5 fields changedInput schema / properties / idAdded value: +{
+ "description": "Job id, e.g. `job_8f2a1c` (from a search_jobs result's `id`).",
+ "type": "string"
+}Input schema / properties / include_region_lockedRemoved value: -{
- "description": "Default false. When true, return the job even if it is region-locked away from Indonesia; read `indonesiaEligibility` on the result.",
- "type": "boolean"
-}Input schema / properties / job_idRemoved value: -{
- "description": "Job id from a search_jobs result.",
- "type": "string"
-}Input schema / properties / localeAdded value: +{
+ "description": "id | en (default id).",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "job_id"
-]New value: +[
+ "id"
+]get_meget_skill_demandhirematch_candidatespost_jobsearch_jobs14 fields changedInput schema / properties / categoryRemoved value: -{
- "description": "Category slug filter.",
- "type": "string"
-}Input schema / properties / freshnessRemoved value: -{
- "description": "fresh | active | stale_risk (W5 tier; omit for no filter).",
- "type": "string"
-}Input schema / properties / geo_verified_onlyRemoved value: -{
- "description": "Only jobs classified geo_fit = id_friendly (W2).",
- "type": "boolean"
-}Input schema / properties / include_region_lockedRemoved value: -{
- "description": "Default false. When true, also return jobs restricted to a region an Indonesia-based applicant cannot work from (geo_fit = restricted, or applicant_region in US/UK/EU/Canada/North America). Check each row's `indonesiaEligibility` before recommending one.",
- "type": "boolean"
-}Input schema / properties / job_typeAdded value: +{
+ "description": "full-time | part-time | contract | freelance",
+ "type": "string"
+}Input schema / properties / limitAdded value: +{
+ "description": "1–50 (default 20).",
+ "type": "integer"
+}Input schema / properties / localeAdded value: +{
+ "description": "id | en (default id).",
+ "type": "string"
+}Input schema / properties / locationAdded value: +{
+ "description": "Location text filter.",
+ "type": "string"
+}Input schema / properties / offsetAdded value: +{
+ "description": "Result offset for pagination.",
+ "type": "integer"
+}Input schema / properties / opportunity_typeAdded value: +{
+ "description": "regular | internship | fellowship | apprenticeship | volunteer | gig (default: regular)",
+ "type": "string"
+}Input schema / properties / qAdded value: +{
+ "description": "Free-text query (title, company, skills).",
+ "type": "string"
+}Input schema / properties / queryRemoved value: -{
- "description": "Free-text query matched against title/company.",
- "type": "string"
-}Input schema / properties / remote_typeAdded value: +{
+ "description": "worldwide | regional | timezone-based",
+ "type": "string"
+}Input schema / properties / remote_usd_onlyRemoved value: -{
- "description": "Only worldwide-remote jobs paid in USD.",
- "type": "boolean"
-}talent_searchget_curated_listget_jobsearch_jobsJobs, visa sponsors, tenders, SEC filings, KYB checks, company and domain intel via Apify.
Remote job boards, LinkedIn jobs, company ATS pages and Upwork jobs as tools. Runs on Apify.
Jobs, ads, SEO, keywords, YouTube and AliExpress data for AI agents. Runs on Apify.
Google Jobs in 26 countries: job title, company, location, parsed salary, full description and every apply link, with date, type and remote filters and an only-new mode. Runs on Apify, $2 per 1,000 jobs.
Add one secure layer between your agents and this server.
