A
licenseA
qualityD
maintenanceSearch Recruiter Roles: live recruiter jobs, companies, sectors, locations, and market stats.
7
30
1
MIT
Hosco Hospitality Jobs
by com.hosco
Server Details
Search Hosco's live hospitality jobs across Spain, Italy, France, the UK and Switzerland.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
100% free. Your data is private.
Tool Definition Quality
A4.2/5.0
Tool DescriptionsA
Average 4.2/5 across 3 of 3 tools scored.
Server CoherenceA
Disambiguation5/5
Each tool has a clearly distinct purpose: list for recent jobs, search for ranked semantic matches, and details for full job information. The descriptions explicitly clarify when to use list vs search, eliminating ambiguity.
Naming Consistency4/5
All tool names follow a predictable pattern with a '-tool' suffix, but 'job-details-tool' uses a noun-noun structure while the others use verb-noun. This minor inconsistency is easy to parse and still readable.
Tool Count4/5
With only 3 tools, the set is minimal but well-scoped for a job discovery server. It covers the essential retrieval operations without unnecessary bloat, though slightly on the lower end.
Completeness4/5
The core workflow of list/search then get details is fully covered. Potential gaps like applying or filtering by specific attributes are not needed for the apparent read-only job board purpose, so no significant dead ends.
Available Tools
3 toolsjob-details-toolJob Details ToolARead-onlyIdempotentInspect
Fetch the full details of a single Hosco job by its slug or numeric id. Use this after a search/list result to retrieve the full description, requirements, benefits, and all other available fields.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | The numeric job id. Provide either slug or id. | |
| slug | No | The job slug (preferred lookup key — present in search/list results). |
Tool Definition Quality
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint and idempotentHint, covering safety. The description adds meaningful context about what the response contains (full description, requirements, benefits, all fields), going beyond the annotations without contradiction.
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?
Two sentences, front-loaded with the core action and resource. The second sentence gives practical usage context. No wasted words.
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?
For a simple read-only detail fetch, the description provides sufficient context about purpose, usage, and return content. Annotations cover safety and idempotency. It doesn't mention error cases, but that is not critical for this tool.
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 (id and slug) are already well documented. The description adds minimal extra meaning beyond restating that either slug or numeric id can be used, matching the baseline.
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 uses a specific verb ('Fetch') and clearly identifies the resource ('full details of a single Hosco job'). It distinguishes itself from list/search siblings by focusing on retrieving one job's details, including description, requirements, and benefits.
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 explicitly states to use this after a search/list result, providing a clear when-to-use context. While it doesn't name alternatives directly, the intended workflow is unambiguous and the sibling tools are implicitly distinguished.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list-jobs-toolList Jobs ToolARead-onlyIdempotentInspect
List the most recently published Hosco jobs, paginated. Use this when no semantic search is needed — for natural-language search, use the search jobs tool instead.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size (1–50, default 10). | |
| offset | No | Pagination offset (default 0). |
Tool Definition Quality
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is known. The description adds context about ordering ('most recently published') and pagination, which goes beyond the annotations and helps the agent understand the tool's behavior.
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 two sentences long, front-loaded with the primary action, and every word earns its place. It avoids fluff and clearly communicates the tool's function and when to use it.
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 tool's simplicity, the annotations covering safety, and the schema covering parameters, the description is sufficient for an agent to select and invoke the tool correctly. No critical information is missing.
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?
The schema already provides 100% coverage with descriptions for both limit and offset. The description does not add parameter-specific semantics beyond what the schema offers, so the baseline of 3 is appropriate.
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 uses a specific verb ('List') and resource ('Hosco jobs') with a clear scope ('most recently published, paginated'). It also distinguishes itself from the sibling search tool by explicitly noting the difference, making the purpose unambiguous.
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 description explicitly states when to use this tool ('when no semantic search is needed') and directs users to the alternative ('use the search jobs tool instead') for natural-language queries. This is clear, actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search-jobs-toolSearch Jobs ToolARead-onlyIdempotentInspect
Semantic + structured search over Hosco hospitality jobs. Mirrors the smart filtering and ranking from hosco-v2: hard-excludes private/expired/inactive postings, supports visibility/promotion/external filters, configurable language matching (subset/any/all), and the v2 "suggested" ordering (relevance → Hosco-native → VIP → freshness). Returns ranked matches with relevance scores.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City name (exact match against hosco_location.locality). | |
| sort | No | Ordering: "suggested" (default — relevance, then Hosco-native, then VIP, then freshness), "posted" (newest activation date), "update_date" (most recently updated), "title" (alphabetical). | |
| limit | No | Page size (1–50, default 10). | |
| query | No | Natural-language search (e.g. "sommelier in Paris fine dining"). When provided, ranks by semantic similarity. When omitted, returns latest jobs filtered + sorted by the structured options. | |
| offset | No | Pagination offset (default 0). | |
| country | No | ISO-3166 alpha-2 country code, e.g. FR, GB, ES. | |
| languages | No | Candidate language codes, e.g. ["en","fr"]. Matched against the job's mandatory fluency requirement ("Require fluency in" in hosco-v2), not the language the ad is written in. Combined with languages_mode. | |
| department | No | Hosco category code, e.g. f-b-kitchen, housekeeping, sommelier, reception. | |
| posted_after | No | ISO date; only return jobs published on or after this date. | |
| visibilities | No | Visibility tiers to include: public, targeted, lite, prime (private is never returned on this public surface). | |
| contract_type | No | One of: internship (students only), professional (professionals only), open (both). | |
| hide_external | No | Hide jobs sourced from external aggregators (Hosco-native only). | |
| only_external | No | Only return jobs sourced from external aggregators. | |
| languages_mode | No | How to interpret `languages`: "all" (job must require every code; default), "any" (job requires at least one of them), "subset" (job's required languages must all be in the provided list — i.e. the candidate speaks them all). | |
| promotion_types | No | Filter to specific promotion statuses: 0=disabled, 1=prime, 2=lite-basic, 4=lite-full. Status 3 (private) is always excluded. | |
| content_language | No | Language code the job ad itself is written in (auto-detected), e.g. "en", "fr". Use this to only show postings the candidate can actually read — unrelated to the languages filter below. | |
| experience_years_max | No | Maximum years of experience the candidate has — only show jobs requiring less than or equal to this. |
Tool Definition Quality
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the readOnly and idempotent annotations by disclosing that private, expired, and inactive postings are hard-excluded, and by explaining the default ordering logic. This provides useful insights into how the tool behaves beyond what annotations offer.
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 two sentences, front-loaded with the core purpose, and every clause provides meaningful detail about filtering, ranking, and exclusions. There is no filler or redundant 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?
Given the tool's complexity (17 optional parameters, no output schema), the description covers key behaviors including exclusions, filtering, ranking, and return type. It does not specify the full return payload structure, but the detailed schema compensates, making the description sufficiently complete.
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?
The input schema already contains detailed descriptions for all 17 parameters (100% coverage). The description adds a high-level summary of filtering capabilities and the default 'suggested' ordering, but these are already captured in the schema descriptions, so the added value is marginal.
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?
The description clearly states the tool performs semantic and structured search over Hosco hospitality jobs and returns ranked matches with relevance scores. However, it does not explicitly contrast this with sibling tools like list-jobs-tool or job-details-tool, making sibling differentiation implicit rather than explicit.
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 description provides clear context for when to use the tool—for semantic or structured search with filtering and ranking—by detailing supported filters and ordering options. It does not explicitly state alternatives or exclusions, but the context is strong enough for an agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Servers
- AlicenseAqualityCmaintenanceSearch current remote / work-from-home jobs by category, region, perk, or company — with ready-to-apply links.5MIT
- Alicense-qualityBmaintenanceSearch live startup.jobs listings with filters for role, location, and employment type, plus get job details, company profiles, hiring trends, and salary benchmarks.MIT
easyhire-jobsofficial
Alicense-qualityCmaintenanceRead-only MCP server for the public EasyHire job board. Enables searching job openings, retrieving full postings, filtering by criteria, and listing countries with open roles.MIT