Alion: company, startup and market intelligence

Search job postings

search_jobs

Read-onlyIdempotent

Search live (or recently closed) tech and business job postings collected from employer ATS boards, career pages and partner feeds worldwide, with strong coverage of Europe, the Gulf, Central Asia and remote roles. Every row carries the employer, role family, seniority, work mode, locations (ISO country codes; remote roles also list hiring_countries, the countries they may hire in), the stated salary or a USD estimate with its method, the required technologies, when the posting was first seen and last verified on the employer's board, and a trust verdict (ok, stale, ghost). Use it to answer "who is hiring X in Y", to monitor a company's openings, or to pull a sample for analysis. Results are sorted newest first (or by pay with sort=salary) and paginated with an opaque cursor: pass next_cursor back to continue. Filters are combined with AND; unknown filter values return an empty list with a warning telling you what was accepted. Staffing agencies and intermediaries (job boards, talent marketplaces reposting other employers' roles) are excluded unless include_agencies=true. Each row links to its Alion page (url), which is also where a candidate applies. For counts, pay percentiles or who hires most, call market_stats instead of paging. Costs 1 unit per call. Docs: https://alion.io/developers/docs

Input Schema

Name	Required	Description	Default
`city`	No	City in English, e.g. "Berlin", "Dubai", "Almaty"; "NYC", "Bay Area", "Munich/München" are understood. An unknown city is refused with suggestions.
`role`	No	A role family ("Backend", "Data Science", "DevOps", "Product", "AI/ML") or a specialisation ("Data Engineer", "Product Manager", "ML Engineer"); filters_applied.role shows what it matched. A family covers all of its specialisations; the full list is the resource alion://dictionaries/role-families.
`sort`	No	"date" = newest first (default), "salary" = highest pay first.	date
`limit`	No	Postings per page (1-50, default 20).
`query`	No	Free-text search over titles and descriptions, e.g. "python backend kubernetes". Several words are matched as a phrase first; when no posting carries the phrase, every word is required anywhere in the title or description (filters_applied.query_match says so). An exact employer name with no text match returns that employer's postings.
`cursor`	No	Opaque cursor from a previous response (next_cursor). Keep every other argument identical.
`detail`	No	"compact" returns about a third of each row (who, what, where, pay, when, trust) - use it to scan many rows; "standard" adds requirements, locations, verification facts and a 280-character description snippet.	standard
`sector`	No	A frontier-tech sector (one or a comma list): biotech, medtech, space, aerospace, semiconductors, energy, climate, defense, robotics, quantum, automotive, science - the trades of the sector at any employer and the technical, scientific and engineering roles of the companies whose core business it is (no sales or back office). Combine with role, country or technology.
`status`	No	"closed" returns postings confirmed closed on the employer board (with closed_at), useful for time-to-fill and churn analysis.	live
`company`	No	Restrict to one employer: its Alion company id, domain ("stripe.com") or exact name.
`country`	No	ISO 3166-1 alpha-2 code (preferred) or country name. Matches the office country, the posting country, or the hiring country of a remote role when the posting states it (hiring_geo_confidence structured or explicit).
`industry`	No	The industry of the posting or its employer, e.g. "Fintech", "Real Estate", "Gaming", "Healthcare" (the industries resource lists them). Every role at those employers; combine with role for one kind of job.
`seniority`	No	Seniority of the role: intern, junior, middle, senior, staff, lead or head.
`work_mode`	No	Where the work happens: on_site, hybrid or remote.
`has_equity`	No	Only postings that offer equity.
`technology`	No	A technology that must be among the requirements, e.g. "Go", "PostgreSQL", "React". A language also matches its frameworks.
`posted_since`	No	Only postings first seen after this point: an ISO date ("2026-09-01") or a relative window ("24h", "7d", "2w").
`visa_sponsor`	No	Only postings at employers listed in the official visa sponsor registers of the posting's country (UK Home Office licensed sponsors, US H-1B/PERM filers, Dutch IND recognised sponsors, Canadian LMIA employers), or whose advert offers sponsorship; adverts that rule sponsorship out are excluded.
`salary_min_usd`	No	Minimum annual pay in USD: a stated range whose top reaches it, or - when nothing is stated - an estimate whose midpoint does.
`employment_type`	No	Kind of engagement: full_time, part_time, contractor, cofounder, freelance or internship.
`include_agencies`	No	Include postings by staffing and recruiting agencies and by intermediaries (job boards, talent marketplaces).
`visa_sponsorship`	No	Only postings that state visa sponsorship.

Output Schema

Name	Required	Description
`meta`	No	Quota and credit standing after this call.
`items`	Yes
`has_more`	Yes
`returned`	Yes
`warnings`	No	Arguments that were ignored or matched nothing, with what to try instead.
`next_cursor`	No	Pass back as cursor, other arguments unchanged.
`filters_applied`	No	How each argument was understood.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 23, 2026

changedInput schema / properties / sector / description

Previous value: -"A frontier-tech sector (one or a comma list): biotech, medtech, space, aerospace, semiconductors, energy, climate, defense, robotics, quantum - the trades of the sector at any employer and the technical, scientific and engineering roles of the companies whose core business it is (no sales or back office). Combine with role, country or technology."New value: +"A frontier-tech sector (one or a comma list): biotech, medtech, space, aerospace, semiconductors, energy, climate, defense, robotics, quantum, automotive, science - the trades of the sector at any employer and the technical, scientific and engineering roles of the companies whose core business it is (no sales or back office). Combine with role, country or technology."

Changed1 schema field changedOct 23, 2026

addedInput schema / properties / sector

Added value: +{
+  "description": "A frontier-tech sector (one or a comma list): biotech, medtech, space, aerospace, semiconductors, energy, climate, defense, robotics, quantum - the trades of the sector at any employer and the technical, scientific and engineering roles of the companies whose core business it is (no sales or back office). Combine with role, country or technology.",
+  "type": "string"
+}

Changed1 schema field changedOct 20, 2026
- changedOutput schema / properties / filters_applied / properties
```
Previous value: -[]New value: +{}
```
First observedOct 15, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial behavior beyond that: newest-first default ordering, opaque cursor pagination with the requirement to keep other arguments identical, AND-combination of filters, empty-list-plus-warning on unknown filter values, default exclusion of staffing agencies and intermediaries, a per-call cost of 1 unit, and the trust verdict vocabulary (ok, stale, ghost). These are operational traits an agent cannot infer from the schema.

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

Conciseness4/5

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

Front-loads scope and row content, then ordering, pagination, filter behavior, the agency exclusion and the sibling redirect — a sensible priority order. It is a single dense block and the row-field enumeration is long, but every sentence carries operational information rather than 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?

Given 22 optional parameters, an output schema and read-only annotations, the description covers everything an agent needs to call it correctly: source coverage, ordering, pagination, filter composition, failure mode on bad values, default exclusions, cost and a docs link. Nothing material 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 baseline is 3; the description nonetheless reinforces key semantics — sort=salary changes ordering, cursor continuation contract, filter ANDing, and what include_agencies actually admits (job boards, talent marketplaces reposting other employers' roles). It adds meaning around filter interaction rather than merely restating parameters.

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 (search job postings) plus the source corpus (employer ATS boards, career pages, partner feeds) and geographic bias. It explicitly contrasts with market_stats and lists what each row contains, so an agent can tell exactly what this returns versus get_job or search_companies.

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 concrete use cases ("who is hiring X in Y", monitoring a company's openings, pulling a sample) and an explicit redirect: for counts, pay percentiles or who hires most, call market_stats instead of paging. It does not explain when to prefer get_job or search_companies, so routing among the other siblings is left implicit.

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

All Alion: company, startup and market intelligence 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?