Skip to main content
Glama
Sign In
adhistory-mcp

adhistory-mcp

by OBrandon
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Remote jobs from 6 job boards

remote_jobs
Read-onlyIdempotent

Find deduplicated remote job postings from six boards in one newest-first list, filterable by keywords, location, posting age and minimum yearly pay, with parsed salary data for each job.

Instructions

List current remote jobs from Remotive, Remote OK, We Work Remotely, Jobicy, Himalayas and Arbeitnow in one deduplicated list (same company + title is returned once), newest first. Each item: board (sourceName, sourceUrl), title, company, allowed location, job type, pay as posted plus parsed salaryMin/salaryMax/salaryCurrency/salaryPeriod and a yearly figure (salaryYearlyMin/Max), posted date, job and apply URLs, optional description text. Filter by keywords, location, age and pay. Returns what those six boards currently list, not the whole web; currencies are not converted. Cost: $1.00 per 1,000 jobs on the user's Apify account; the default 20 jobs cost $0.02. Latency: usually 5-30 s.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "remote_jobs"
  }
}

Input Schema

NameRequiredDescriptionDefault
sourcesNoOptional. Boards to read; default all six.
max_itemsNoStop after this many jobs in total.
salary_onlyNoKeep only jobs that show pay.
search_textNoOptional. Keep jobs whose title, company, category or tags contain all these words, e.g. 'python developer'.
location_containsNoOptional. Keep jobs whose allowed-location text contains this, e.g. Europe, USA, Worldwide.
min_yearly_salaryNoOptional. Keep jobs whose top pay, as a yearly amount in the job's own currency, is at least this.
posted_within_daysNoOptional. Only jobs posted in the last N days.
include_descriptionNoAdd the job description text. Same price.
max_items_per_sourceNoOptional cap per board so one big board does not use the whole limit.
only_new_since_last_runNoSkip jobs returned by an earlier run on this Apify account (for daily new-job feeds).

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, yet the description adds substantial context beyond them: explicit pricing ($1.00 per 1,000 jobs, $0.02 for the default 20), latency (5-30 s), the dedup key, the fact that currencies are not converted, and the cross-run statefulness of 'only_new_since_last_run'. These are exactly the operational traits an agent needs before deciding to spend money on a call.

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

Conciseness5/5

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

Three dense sentences, front-loaded with what the tool returns, followed by filtering capability, then cost and latency. No filler, and the cost/latency facts are placed last where they are easiest to check before invoking.

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

Completeness5/5

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

For a 10-parameter aggregation tool with an output schema, the description covers sources, dedup, ordering, field set, filtering, pricing, latency and the stateful option. Nothing an agent needs in order to call it correctly or budget for it is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real interpretation: 'min_yearly_salary' is clarified as comparing the job's own currency with no conversion, and location filtering is tied to 'allowed location' text. It still does not walk through each parameter, so it is an increment rather than a full substitute.

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

Purpose5/5

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

States a specific verb and resource — 'List current remote jobs' — and names all six source boards plus the dedup rule ('same company + title is returned once') and ordering ('newest first'). The scope boundary 'Returns what those six boards currently list, not the whole web' separates it from company-ATS style job tools without needing to name a sibling.

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

Usage Guidelines4/5

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

Gives clear conditions for use — filtering by keywords, location, age and pay — and an explicit scope exclusion ('not the whole web'). It does not name an alternative tool for a related need (e.g. company-specific or ATS-sourced postings), so the when-not side is only implied rather than routed.

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

Deploy Server

Other Tools