Cerulean Jobs

Fetch a listing

fetch

Read-onlyIdempotent

Use this when someone asks about one specific Cerulean listing — its responsibilities, qualifications, skills, experience, education, pay when the employer states it, benefits or required languages — and its id or Cerulean URL is known. Returns that one listing in full as text, with its url and structured details. It does not search. An unknown or closed listing is an error.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`id`	Yes	The listing's id, as every result carries it, or its URL on a Cerulean site.
`locale`	No	The user's language and region, as a BCP 47 tag: fr-CH for someone writing French in Geneva, say. It sets the language of titles and descriptions, and adds localizedUrl, the listing on that locale's Cerulean site, where the site carries it. It does not filter: country and location do. Cerulean's sites are en: ceruleanjobs.com, English, worldwide; fr-FR: cerulean.fr, French, France; fr-CH: ceruleanjobs.ch, French, Switzerland; de-CH: ceruleanjobs.ch, German, Switzerland; en-CA: ceruleanjobs.ca, English, Canada; fr-CA: ceruleanjobs.ca, French, Canada; de-DE: ceruleanjobs.de, German, Germany; en-GB: ceruleanjobs.co.uk, English, UK; es-ES: cerulean.es, Spanish, Spain; it-IT: ceruleanjobs.it, Italian, Italy. Any other tag takes its language's site, so fr-BE reads as fr-FR and en-US as en; another language reads as en. Defaults to en.

Output Schema

TableJSON Schema

Name	Required	Description
`id`	Yes
`url`	Yes	The listing on ceruleanjobs.com, where a candidate reads it in full and applies.
`text`	Yes	The whole listing as text: its summary, responsibilities, qualifications, skills, experience, education, pay where stated, benefits and languages.
`title`	Yes
`metadata`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 25, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the readOnlyHint, idempotentHint, and non-destructive annotations, the description discloses that unknown or closed listings produce an error and that the tool returns the full listing as text with URL and structured details. These are non-obvious behavioral details useful for agent invocation, and nothing contradicts 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.

Conciseness5/5

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

The description is front-loaded with the exact usage trigger, then states the return payload, the non-search behavior, and the error condition. Every sentence earns its place; no filler or redundant restating of the title.

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?

Given the rich parameter schema, output schema, and annotation coverage, the description covers all remaining decision-relevant context: when to use it, what it returns, what it does not do, and how errors behave. The agent has enough to invoke it correctly.

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

Parameters3/5

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

Schema description coverage is 100%, and the schema already explains id and locale in detail including locale-specific site mappings. The description reinforces that id can be a URL, but it does not meaningfully add 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.

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: fetching one specific Cerulean listing when its id or URL is known, and returns it in full. It explicitly distinguishes itself from searching ('It does not search.'), which separates it from the sibling tools search and find_similar_jobs.

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?

The trigger is explicit: use when someone asks about one specific listing with a known id or URL. It also gives an exclusion ('It does not search.') and an error condition for unknown or closed listings. It does not explicitly name search or find_similar_jobs as alternatives, but the contrast is clear enough.

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

All Cerulean Jobs tools Inspect

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

Need Help?