Skip to main content
Glama

Fairquery Agent Trust & Data Safety

by com.getfairquery
OverviewDiscussionsAdmin

List the verified starter boards (free, offline)

jobs_list_seed_boards
Read-onlyIdempotent

WHAT: List the bundled starter list of company job boards that Fairquery verified on their official ATS APIs (company, domain, ats, slug, verified_at, jobs_at_verification). WHEN: To pick companies to scan, or to know which names jobs_find_board resolves instantly. WHEN NOT: Live jobs on one board (jobs_get_board), a place search across this list (jobs_search_by_location), or companies not in the list (jobs_find_board). The list is a starting point, not a global index of employers. BEHAVIOR: Runs on this Fairquery-hosted Worker (Cloudflare), not on the caller's machine; inputs leave the client. This Worker's code is designed not to store inputs or results. No further network call: it reads a static list compiled into this Worker. jobs_at_verification is a snapshot from verified_at and goes stale. COST: No APIFY_TOKEN, no billing. RETURNS: Paged "seed_board" rows in the fixed bundled order (original boards stay first, so earlier offsets stay put). 135 Greenhouse, Lever and Ashby boards. PARAMETERS: ats narrows the list; omit it for the whole starter list (Greenhouse, Lever, Ashby). Personio, Pinpoint and Gem are not in the starter list (named accounts only). meta.by_ats always counts the whole list per ATS and ignores ats, so take paging totals from total. Feed ats + slug of any item straight into jobs_get_board. EXAMPLE: {"ats":"lever"} -> Palantir, Spotify, Zoox, Ro, then more Lever boards.

Input Schema

NameRequiredDescriptionDefault
atsNoOptional filter: "greenhouse" | "lever" | "ashby" | "personio" | "pinpoint" | "gem"; default all. The starter list has no Personio, Pinpoint or Gem boards
limitNoOptional page size, integer 1-500, default 100
offsetNoOptional items to skip, integer >= 0, default 0; pass nextOffset from the previous response

Output Schema

NameRequiredDescriptionDefault
metaNoTool-specific context: board totals, request counts, cost notes
countYesNumber of items in this page
itemsYesResult rows. Each has "type": "job" (job_key, title, company, locations, countries, remote, posted_at, verified_open_at, age_days, long_open, apply_url, source_url, ...), "board", "company", "seed_board", "open_check" or "error" (code, message, retryable)
totalYesTotal items after filters, before paging
offsetYesOffset of the first item in this page
hasMoreYesTrue if more items exist after this page
nextOffsetYesOffset to pass for the next page, or null when done

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / ats / description
      Previous value: -"Optional filter: \"greenhouse\" | \"lever\" | \"ashby\" | \"personio\"; default all. The starter list has no Personio boards"New value: +"Optional filter: \"greenhouse\" | \"lever\" | \"ashby\" | \"personio\" | \"pinpoint\" | \"gem\"; default all. The starter list has no Personio, Pinpoint or Gem boards"
    • changedInput schema / properties / ats / enum
      Previous value: -[
-  "greenhouse",
-  "lever",
-  "ashby",
-  "personio"
-]New value: +[
+  "greenhouse",
+  "lever",
+  "ashby",
+  "personio",
+  "pinpoint",
+  "gem"
+]
  2. First observed

TDQS

A5/5.0
Behavior5/5

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

Beyond the annotations, the description discloses that the tool runs on a hosted Cloudflare Worker, inputs leave the client, the Worker is designed not to store inputs or results, and no further network call is made. It also warns that jobs_at_verification is a stale snapshot and that no APIFY_TOKEN or billing is needed. These details materially help the agent understand execution and data freshness.

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?

The description is labeled and front-loaded with WHAT, WHEN, and WHEN NOT before behavior, cost, returns, parameters, and an example. Although long, every section carries useful decision or invocation context, and there is no filler.

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?

The description covers purpose, alternatives, execution environment, privacy behavior, cost, return shape, ordering, paging caveat, filtering semantics, and an example. With annotations and an output schema already present, this leaves no important gap for correct selection or invocation.

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

Parameters5/5

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

Schema coverage is already 100%, but the description adds operational meaning: ats narrows the starter list, does not include Personio/Pinpoint/Gem, and feed ats plus slug directly into jobs_get_board. It also clarifies a subtle paging caveat: meta.by_ats counts the whole list per ATS and ignores ats, so paging totals should come from total. This is meaningfully beyond the schema.

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?

The description states a specific verb and resource: listing bundled starter company job boards verified on official ATS APIs. It also describes the returned fields and distinguishes this tool from live job retrieval, location search, and board resolution siblings. An agent can identify exactly what this tool provides 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.

Usage Guidelines5/5

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

The WHEN and WHEN NOT sections explicitly say to use this tool to pick companies or identify instant board resolutions, and they name concrete alternatives for live jobs, location search, and companies outside the list. The description also frames the list as a starting point rather than a global index, which prevents misuse.

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

All Fairquery Agent Trust & Data Safety toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources