F
licenseNot graded
qualityD
maintenanceEnables searching for jobs in Russia and remote positions from AI assistants using multiple job platforms (hh.ru, Trudvsem, SuperJob, and remote job aggregators).
1
-
Finder Jobs
by work.finder
Server Details
Live job vacancies and salary stats: Russia, Belarus, Kazakhstan, Germany, France and more.
If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
A3.9/5.0
Scored across 4 tools
Disambiguation5/5
Each tool has a clearly distinct role: searching vacancies, retrieving a specific vacancy, listing supported countries, and providing salary statistics. There is no meaningful overlap between the tools, and the dependency between search_vacancies and get_vacancy is explained via the Finder id.
Naming Consistency4/5
Three tools follow a clear snake_case verb_noun pattern (get_vacancy, list_countries, search_vacancies), while salary_stats uses a noun_noun pattern. This is a minor deviation, but the overall naming remains readable and predictable.
Tool Count5/5
Four tools are well-scoped for a job vacancy search service: discovery, detail lookup, country metadata, and salary analytics. Each tool earns its place without redundancy.
Completeness4/5
The core read-only workflow is covered: list countries, search vacancies, get vacancy details, and view salary stats. Some advanced filtering or pagination options may be missing, but agents can still accomplish typical job-search tasks.
Available Tools
4 toolsget_vacancyGet vacancyARead-onlyIdempotentInspect
Get details of one vacancy by its Finder id (from search_vacancies). For Russia pass country="ru" (ids from finder.work): title, employer, city, salary, description (up to 1500 chars) and the finder.work page url where the user can apply.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Vacancy id from search_vacancies results | |
| country | No | Pass 'ru' for Russian (finder.work) vacancies; leave empty for other countries |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| id | No | |
| url | No | |
| city | No | |
| error | No | |
| title | No | |
| active | No | |
| salary | No | |
| country | No | |
| excerpt | No | |
| employer | No | |
| posted_at | No | |
| workplace | No | |
| experience | No | |
| description | No | |
| employment_type | No |
TDQS
A3.9/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds useful substance about the returned payload (title, employer, city, salary, description capped at 1500 chars, and an apply URL), though an output schema exists, so this is additive but modest.
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?
A single dense sentence that front-loads the core action and id source, with the Russia-specific rule and return contents following. Slightly packed, but every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema, annotations, and fully documented params, the description only needs to add the id provenance and country nuance, which it does. Minor gaps remain (no error behavior for an invalid id, no explicit statement that country only affects Russian listings' source), keeping it from a 5.
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%, so both parameters are already documented in the schema; the description merely restates the id origin and the 'ru' country rule. Baseline 3 is appropriate since the schema does the heavy lifting.
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 (get details of ONE vacancy) and implicitly contrasts with the sibling search_vacancies by naming it as the id source, so an agent can tell retrieval-by-id apart from search. The scope is unambiguous.
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?
It gives the prerequisite (id must come from search_vacancies) and the conditional rule for the country parameter ('ru' for Russia, empty otherwise), which is clear usage context. It does not state when NOT to use it or name an alternative retrieval path, so it falls 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.
list_countriesList countriesARead-onlyIdempotentInspect
List countries supported by Finder with their ISO code and site url.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| countries | Yes |
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is fully covered by structured data. The description adds only the returned fields, which the output schema also covers, so it contributes little beyond 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?
A single front-loaded sentence stating the resource and its returned fields, with no filler or redundant restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, complete annotations, and an output schema, the description only needs to state the resource and scope, which it does. Only the intended use case is left implicit.
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?
The tool takes no parameters, so there is nothing for the description to disambiguate. Baseline for zero-parameter tools is a 4.
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?
Specific verb (List) + resource (countries) with scope qualifier ('supported by Finder') and an inventory of what each entry contains (ISO code, site url). Siblings are all vacancy-related, so no plausible confusion exists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use statement. For a zero-argument reference-lookup tool the usage is largely self-evident, but the description never says what the list is needed for (e.g., resolving country codes before a search).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
salary_statsSalary statisticsARead-onlyIdempotentInspect
Salary statistics (25th/50th/75th percentile, sample size) from active vacancies on Finder. country: ISO code; profession: name in local language (e.g. 'Бухгалтер', 'Programmierer'); empty = all jobs; city optional. Returns the matching Finder salary page url when available.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Optional city name as written locally | |
| country | Yes | Country ISO code: ru (Russia, finder.work), by, kz, kg, de, fr, be, ch, se, id | |
| profession | No | Profession in local language, e.g. 'Бухгалтер', 'Programmierer'. Empty = all jobs |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| p25 | No | |
| p75 | No | |
| url | No | |
| city | No | |
| mean | No | |
| error | No | |
| median | No | |
| period | No | |
| source | No | |
| country | No | |
| currency | No | |
| profession | No | |
| sample_size | No | |
| range_1sigma | No |
TDQS
A3.5/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds that statistics come only from active vacancies and that a Finder salary page URL is returned when available, which is useful but modest added context.
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?
Compact and front-loaded: the returned metrics and source lead the sentence, with parameter hints trailing. A couple of clauses duplicate schema text, but there is little waste overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and annotations covering the read-only/idempotent profile, the description need not explain return values; noting the conditional salary-page URL suffices. For a 3-parameter read tool it is essentially complete, though sibling routing remains unaddressed.
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%, so the schema already documents country ISO codes, local-language profession names, and the optional city. The description largely restates these semantics ('country: ISO code', 'profession: name in local language', 'empty = all jobs') without adding format or edge-case detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the specific resource and metric set (25th/50th/75th percentile, sample size) and the source population (active vacancies on Finder), which is precise enough for an agent to know what it retrieves. It does not explicitly differentiate itself from siblings like search_vacancies or get_vacancy, 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (aggregate salary data for a country/profession) and gives filling guidance ('empty = all jobs', 'city optional'), but never states when to choose this over search_vacancies or get_vacancy. Usage is inferred rather than instructed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_vacanciesSearch vacanciesARead-onlyIdempotentInspect
Search active job vacancies on Finder. country: ISO code (ru, by, kz, kg, de, fr, be, ch, se, id; ru = finder.work, Russia).
query: job title / keywords in any language (e.g. 'бухгалтер', 'python developer'). city: city name as written
locally (e.g. 'Минск', 'Алматы', 'Berlin'). Returns up to limit (≤20) newest matches with links to finder.work.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City name as written locally, e.g. 'Минск', 'Алматы', 'Berlin'. Empty = whole country | |
| limit | No | Max results, 1-20 (default 10) | |
| query | No | Job title or keywords in any language, e.g. 'бухгалтер', 'python developer'. Empty = newest vacancies | |
| country | Yes | Country ISO code: ru (Russia, finder.work), by, kz, kg, de, fr, be, ch, se, id |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| count | No | |
| error | No | |
| total | No | |
| country | No | |
| results | No | |
| listing_url | No |
TDQS
A3.5/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, covering the safety profile. The description adds the useful detail that results are capped at ≤20 newest matches with links to finder.work, but nothing about rate limits or auth.
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?
Compact and front-loaded, leading with the core purpose before parameter hints. Some sentences duplicate the schema descriptions, but there is little waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be explained. The description covers the searchable fields and result cap, leaving only minor gaps (no explicit alternative routing).
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 coverage is 100%, so all four parameters are already documented in the schema. The description largely restates country ISO codes, local-language query/city examples that duplicate the schema, adding no syntax beyond it. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb+resource: 'Search active job vacancies on Finder.' The agent can distinguish this from get_vacancy (single fetch) by the search semantics, 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage via required country and the note that empty query returns newest vacancies, but gives no explicit when-to-use/when-not guidance or routing against siblings like get_vacancy or list_countries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
4 tool updates
- Changed
get_vacancy3 fields changed- added
Input schema / properties / countryAdded value: +{ + "default": "", + "description": "Pass 'ru' for Russian (finder.work) vacancies; leave empty for other countries", + "title": "Country", + "type": "string" +} - added
Input schema / properties / id / descriptionAdded value: +"Vacancy id from search_vacancies results" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "active": { + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Active" + }, + "city": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "City" + }, + "country": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Country" + }, + "description": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Description" + }, + "employer": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Employer" + }, + "employment_type": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Employment Type" + }, + "error": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Error" + }, + "excerpt": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Excerpt" + }, + "experience": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Experience" + }, + "id": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Id" + }, + "posted_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Posted At" + }, + "salary": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Salary" + }, + "title": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Title" + }, + "url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Url" + }, + "workplace": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Workplace" + } + }, + "title": "VacancyDetails", + "type": "object" +}
- Changed
list_countries1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$defs": { + "Country": { + "properties": { + "code": { + "description": "Country ISO code to pass as `country`", + "title": "Code", + "type": "string" + }, + "name": { + "description": "Country name", + "title": "Name", + "type": "string" + }, + "url": { + "description": "Finder site for the country", + "title": "Url", + "type": "string" + } + }, + "required": [ + "code", + "name", + "url" + ], + "title": "Country", + "type": "object" + } + }, + "properties": { + "countries": { + "items": { + "$ref": "#/$defs/Country" + }, + "title": "Countries", + "type": "array" + } + }, + "required": [ + "countries" + ], + "title": "CountryList", + "type": "object" +}
- Changed
salary_stats4 fields changed- added
Input schema / properties / city / descriptionAdded value: +"Optional city name as written locally" - added
Input schema / properties / country / descriptionAdded value: +"Country ISO code: ru (Russia, finder.work), by, kz, kg, de, fr, be, ch, se, id" - added
Input schema / properties / profession / descriptionAdded value: +"Profession in local language, e.g. 'Бухгалтер', 'Programmierer'. Empty = all jobs" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "city": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "City" + }, + "country": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Country" + }, + "currency": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Currency" + }, + "error": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Error" + }, + "mean": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Mean" + }, + "median": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Median" + }, + "p25": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ], + "default": null, + "title": "P25" + }, + "p75": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ], + "default": null, + "title": "P75" + }, + "period": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Period" + }, + "profession": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Profession" + }, + "range_1sigma": { + "anyOf": [ + { + "items": { + "type": "number" + }, + "type": "array" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Range 1Sigma" + }, + "sample_size": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Sample Size" + }, + "source": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Source" + }, + "url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Url" + } + }, + "title": "SalaryStats", + "type": "object" +}
- Changed
search_vacancies5 fields changed- added
Input schema / properties / city / descriptionAdded value: +"City name as written locally, e.g. 'Минск', 'Алматы', 'Berlin'. Empty = whole country" - added
Input schema / properties / country / descriptionAdded value: +"Country ISO code: ru (Russia, finder.work), by, kz, kg, de, fr, be, ch, se, id" - added
Input schema / properties / limit / descriptionAdded value: +"Max results, 1-20 (default 10)" - added
Input schema / properties / query / descriptionAdded value: +"Job title or keywords in any language, e.g. 'бухгалтер', 'python developer'. Empty = newest vacancies" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$defs": { + "VacancyCard": { + "properties": { + "city": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "City of the vacancy", + "title": "City" + }, + "country": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Country code (search results) or country name (get_vacancy)", + "title": "Country" + }, + "employer": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Employer name", + "title": "Employer" + }, + "employment_type": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Employment type, e.g. full_time, part_time, contract", + "title": "Employment Type" + }, + "excerpt": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Short description excerpt (≤200 chars)", + "title": "Excerpt" + }, + "id": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "description": "Finder vacancy id (use with get_vacancy)", + "title": "Id" + }, + "posted_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Publication date, YYYY-MM-DD", + "title": "Posted At" + }, + "salary": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Advertised salary range with currency, e.g. '2 000–2 500 BYN'", + "title": "Salary" + }, + "title": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Job title", + "title": "Title" + }, + "url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Vacancy page on finder.work where the user can read more and apply", + "title": "Url" + }, + "workplace": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Workplace type: onsite, remote, hybrid", + "title": "Workplace" + } + }, + "title": "VacancyCard", + "type": "object" + } + }, + "properties": { + "count": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Count" + }, + "country": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Country" + }, + "error": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Error" + }, + "listing_url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Listing Url" + }, + "results": { + "anyOf": [ + { + "items": { + "$ref": "#/$defs/VacancyCard" + }, + "type": "array" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Results" + }, + "total": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Total" + } + }, + "title": "SearchResult", + "type": "object" +}
4 tool updates
- First observed
get_vacancy - First observed
list_countries - First observed
salary_stats - First observed
search_vacancies
Related MCP Connectors
Live job ads from StepStone, XING, Welcome to the Jungle, Naukri, JobStreet and more.
Live job ads from StepStone, XING, Welcome to the Jungle, Naukri, JobStreet and more.
Live job vacancies: Germany (Arbeitsagentur), Sweden (Platsbanken) and global tech ATS jobs.
Search live job openings in many countries and languages, and read a full job ad.
Related MCP Servers
- AlicenseAqualityBmaintenanceRussian payroll calculator (2025-2026 rules): net/gross salary with progressive 13-22% income tax, employer contributions incl. SME/IT tariffs, vacation pay, sick pay and unused-vacation compensation. Fully local, no API key.27MIT
- FlicenseNot gradedqualityCmaintenanceEnables querying real disclosed salary data across 20 regions, with tools to search jobs, retrieve salary statistics, and find similar roles.-
- AlicenseNot gradedqualityBmaintenanceAI Job search over 3.5M+ live US jobs2MIT
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.