Search 1M+ enriched job listings from 20,000+ companies. Filter by skills, salary, location, seniority, remote type, and more. Free — 500 calls/day, no signup required.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
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.
Average 4/5 across 5 of 5 tools scored. Lowest: 3.3/5.
Each tool has a clearly distinct purpose with no overlap: find_similar_jobs is for AI-based similarity discovery, get_company retrieves company profiles, get_filter_options provides metadata for filtering, get_job fetches detailed job listings, and search_jobs handles broad search queries. The descriptions clearly differentiate their functions, eliminating any ambiguity.
All tool names follow a consistent verb_noun pattern with snake_case (e.g., find_similar_jobs, get_company, get_filter_options, get_job, search_jobs). The verbs are appropriate and descriptive (find, get, search), and there are no deviations in naming conventions, making the set predictable and readable.
With 5 tools, the count is well-scoped for a job data domain, covering core operations like search, retrieval, filtering, and discovery without being overwhelming. Each tool serves a specific, necessary function, and there are no redundant or trivial additions, making the set efficient and focused.
The tool surface provides comprehensive coverage for job search and discovery, including search, detailed retrieval, company profiles, filtering options, and similarity-based recommendations. Minor gaps might include update or delete operations for job data, but these are likely unnecessary for a read-only data lake, and the tools support key agent workflows effectively.
find_similar_jobsAFind jobs similar to a given job listing using AI vector similarity. Great for "more like this" discovery.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | Job handle or ID to find similar jobs for | |
| per_page | No | Number of results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds the behavioral detail of using AI vector similarity, which goes beyond annotations, but it does not describe output format, ordering, or any limitations. This is acceptable given the annotations, but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core action and purpose. No fluff or repetition; every phrase earns its place. The "Great for" qualifier is slightly marketing-flavored but still concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with read-only annotations and no output schema, the description adequately conveys the tool's purpose and core behavior. It could mention that it returns a list of similar jobs, but the intent is clear enough for an agent to select and invoke correctly. Slight gap in not describing the response shape, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters already documented (job_id and per_page). The description does not add new meaning beyond reinforcing the similarity context. Baseline 3 is appropriate since the schema carries the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it finds jobs similar to a given listing using AI vector similarity, with a specific verb and resource. It distinguishes from siblings like search_jobs (filtered search) and get_job (exact retrieval) by emphasizing the similarity/more-like-this use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase "Great for 'more like this' discovery" provides a clear context for when to use this tool, implying it is the go-to for finding analogous job listings. However, it does not explicitly name alternative tools or exclusion criteria, though sibling distinction is reasonably clear from the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_companyAGet company profile including open job count, industry, size, and career page URL.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Company domain (e.g. "stripe.com") or handle |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the specific output fields but does not disclose behaviors like behavior when a company is not found or data incompleteness. This is adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that concisely states the purpose and key return fields. No wasted words, ideal for quick agent parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, one-parameter tool with annotations and a clear output field list, the description is largely sufficient. It conveys the core function and expected return data. It could be more complete with error behavior, but it is not a critical gap for such a focused tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single parameter 'company' with a clear description and example. The description adds no additional parameter semantics beyond what the schema provides, matching the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('company profile') and lists the exact fields returned (open job count, industry, size, career page URL). This clearly distinguishes it from sibling tools like get_job or search_jobs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the tool's purpose clear enough to infer when to use it (when company-level information is needed). However, it does not explicitly mention alternatives or exclusions, though sibling tools like get_job or search_jobs are contextually different.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_filter_optionsAGet available filter values (seniority levels, job functions, skills, etc.) with job counts. Useful for discovering what values to use in search filters.
| Name | Required | Description | Default |
|---|---|---|---|
| facets | No | Comma-separated facet fields to retrieve | seniority,job_function,remote_type,employment_type,required_skills |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds that results include job counts and covers various value categories, but it does not disclose additional behavioral details such as pagination or dynamic nature beyond what openWorldHint already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary function and followed by a concise usage note. Every word adds value, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, optional-parameter read-only tool with annotations and no output schema, the description fully covers purpose, usage, and parameter semantics. It is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter schema covers 100% with 'Comma-separated facet fields to retrieve', so baseline is 3. The description adds meaningful examples (seniority levels, job functions, skills) and connects them to 'search filters', enriching the semantic understanding of what the facets parameter accepts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get available filter values (seniority levels, job functions, skills, etc.) with job counts', naming a specific resource and purpose. It distinguishes itself from sibling tools like search_jobs and get_job by focusing on filter-value discovery rather than job retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Useful for discovering what values to use in search filters', which gives a clear context for when to use the tool. It does not explicitly name alternatives or exclusion criteria, but the intended usage before searching is implied and sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_jobAGet full details for a specific job listing including description, requirements, salary, and apply link. Use the job_handle ID from search_jobs results.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | Job handle from search results (e.g. "dropbox-senior-full-stack-software-engineer-d3f1k") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the description does not need to over-explain safety. It adds that the response includes specific fields but does not address potential edge cases (e.g., missing ID, errors). With annotations covering the safety profile, a score of 3 is fair.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the tool's purpose, key fields, and the ID source without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter fetch tool with strong annotations and no output schema, the description covers the essential aspects: what it returns, how to get the ID, and the resource. It is complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a description with an example for job_id. The description adds context by specifying that the ID comes from search_jobs results, reinforcing the semantic source of the parameter beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets full details for a specific job listing, listing specific fields (description, requirements, salary, apply link). It also specifies the resource is a job listing, distinguishing it from siblings like search_jobs and get_company.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context on when to use the tool: after obtaining a job_handle from search_jobs results. It does not explicitly state alternatives or exclusions, but the sequencing guidance is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_jobsASearch 1M+ job listings from 20K+ companies. Supports keyword search, AI semantic search, filters for location, salary, remote type, seniority, skills, and more.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| query | No | Keyword search (title, company, skills). Use * for all jobs. | |
| skills | No | Comma-separated required skills, e.g. "Python,AWS,Kubernetes" | |
| company | No | Company domain filter, e.g. "stripe.com" | |
| sort_by | No | Sort: "posted_at:desc" (newest, default), "posted_at:asc" (oldest), "salary_max_usd:desc" (highest paid), "salary_min_usd:asc" (lowest paid) | |
| location | No | Location filter, e.g. "Remote", "San Francisco", "Germany" | |
| per_page | No | Results per page (max 100) | |
| countries | No | Comma-separated ISO country codes, e.g. "US,GB,DE" | |
| seniority | No | Comma-separated: Entry, Mid Level, Senior, Staff, Principal, Manager, Internship, Director, Lead, C Level | |
| salary_max | No | Maximum annual salary in USD | |
| salary_min | No | Minimum annual salary in USD | |
| remote_type | No | Remote work policy | |
| job_function | No | ||
| posted_within | No | Time window: "24h", "7d", "30d" — only jobs posted within this period | |
| semantic_query | No | AI semantic search. Works best with job-title-like queries (e.g. "machine learning engineer", "senior devops"). Supported for remote + tech jobs only. | |
| employment_type | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, covering the safety profile. The description adds useful scale information and the availability of AI semantic search, but does not disclose limitations like semantic search being restricted to remote/tech jobs or pagination behavior. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and key capabilities. Every word contributes, and the 'and more' is a minor vagueness that doesn't hurt conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 16 parameters and no output schema, the description is fairly high-level. It doesn't mention pagination, output format, or how to combine with sibling tools, but annotations and schema descriptions fill many gaps. Adequate but could provide more orientation for a complex search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 81% schema description coverage, the schema already explains most parameters. The description's mention of filters (location, salary, remote type, seniority, skills) adds no new meaning beyond the schema, so it stays at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches job listings, giving scale (1M+ jobs, 20K+ companies) and mentioning keyword and semantic search. It doesn't explicitly differentiate from sibling tools like find_similar_jobs, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the main job search tool by listing its capabilities, but it gives no explicit guidance on when to use it versus find_similar_jobs, get_filter_options, or get_job. There are no stated exclusions or alternative recommendations.
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.
No comments yet. Be the first to start the discussion!
