A
license-
qualityA
maintenanceMCP server that exposes job search data from multiple boards, enabling clients to query and manage job listings via natural language.
7
MIT
Dice MCP
Server Details
Dice MCP: Search for tech jobs on Dice.com
- 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.8/5.0
Tool DescriptionsA
Average 4.8/5 across 3 of 3 tools scored.
Server CoherenceA
Disambiguation5/5
Each tool targets a distinct resource and action: search_jobs discovers job listings, get_job_details returns the full description and skills for a specific job, and get_company retrieves company details for a job. There is no overlap in purpose, and descriptions explicitly clarify when to use each tool.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case: search_jobs, get_job_details, get_company. The verbs are semantically appropriate (search for discovery, get for retrieval) and the pattern is uniform across the set.
Tool Count5/5
Three tools is a well-scoped, focused set for a read-only job search MCP. Each tool earns its place in the search → details → company flow, and the count falls comfortably within the typical 3-15 range.
Completeness4/5
The core user journey is covered: searching for jobs, viewing full job details, and looking up company information. Minor gaps exist (e.g., no company search or application submission tools), but these are explicitly outside the stated purpose, so the surface is adequate for the domain.
Available Tools
3 toolsget_companyGet CompanyARead-onlyInspect
Retrieve the name and description of the company behind a job, by job ID.
Use this tool when users want more detail about a company than search_jobs/get_job_details return (e.g. after finding a job and wanting to know more about the company that posted it). DO NOT use for: searching/discovering companies or jobs by keyword (use search_jobs instead).
LLM USAGE INSTRUCTIONS:
The typical flow is: search_jobs to find jobs -> user picks one -> offer to look up the company -> if the user agrees, call this tool with that same job_id (the same guid used for get_job_details; no separate lookup step is needed first).
Do not call this automatically right after get_job_details; ask the user first unless they already explicitly asked for company details.
Not every company has published an employer branding profile, and some profiles are marked not visible by the company. When that happens this tool does NOT raise — it returns a Company with
messageset and empty name/desc. Relay that message to the user (e.g. "Looks like that company hasn't published a public profile.") rather than treating it as an error.
Args:
job_id: The unique identifier of the job whose company to look up (required). This
must be the job's guid field from a search_jobs result, NOT its id field —
id is a different, internal identifier that this tool does not accept.
Returns: Company: Contains: - name: The company name (empty if message is set) - desc: The company description (empty if message is set) - message: Set instead of name/desc when there is no visible company profile to show; None when name/desc are populated
Raises: Exception: If the job is not found, an API call itself fails (network error, non-200 response, GraphQL errors), or input validation errors occur
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| desc | No | The company description |
| name | No | The company name |
| message | No | Set instead of name/desc when there is no visible company profile to show (e.g. the company hasn't published one, or has marked it not visible). None when name/desc are populated. |
Tool Definition Quality
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool does not raise exceptions for missing company profiles but returns a Company with a message, and explains that job_id must be guid not id, adding context beyond annotations which only mark readOnlyHint and destructiveHint.
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?
Well-structured with clear sections, but slightly verbose due to extensive LLM instructions and edge cases. Could be more concise while preserving essential details.
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?
Covers all aspects: parameter, return type, error handling, edge case of missing profile, and alignment with typical workflow, despite having only 1 parameter and no schema descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage, but the description fully explains the job_id parameter, specifying it must be the job's guid field, not its id, and that it is required, adding crucial semantic info beyond the schema.
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 clearly states the tool retrieves the company name and description by job ID, distinguishing it from siblings search_jobs and get_job_details which return job listings or details without company info.
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?
Explicitly guides when to use (after finding a job, when user wants company detail) and when not (searching/discovering), provides a typical flow, and includes LLM usage instructions with cautions about auto-calling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_job_detailsGet Job DetailsARead-onlyInspect
Retrieve a job's full description and associated skills by job ID.
Use this tool when users want more detail about a specific job than search_jobs returns (e.g. after finding a job via search_jobs and wanting its full description and skills list). DO NOT use for: searching/discovering jobs by keyword (use search_jobs instead).
LLM USAGE INSTRUCTIONS:
Only call this after the user has picked out a specific job from search_jobs results (or otherwise supplied a job's guid directly) — do not call it speculatively for every search result.
After returning job details, do NOT automatically call get_company. Instead, offer to look up the company (e.g. "Want me to pull up more info on the company?") and only call get_company, passing this same job_id, if the user says yes.
Args:
job_id: The unique identifier of the job to retrieve (required). This must be the
job's guid field from a search_jobs result, NOT its id field — id is a
different, internal identifier that this tool does not accept.
Returns: JobDetails: Contains: - description: The full job description - skills: List of Skill objects associated with the job
Raises: Exception: If the API call fails, the job is not found, or input validation errors occur
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| skills | No | Skills associated with the job |
| description | No | The job description |
Tool Definition Quality
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds that job_id must be the guid (not id) and that exceptions are raised for API failure, job not found, or input validation errors—adding value beyond annotations.
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?
The description is well-structured with sections (Args, Returns, Raises) and front-loads the main purpose. However, there is some redundancy (e.g., first two paragraphs both describe when to use), slightly reducing conciseness.
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 simple single-parameter tool with an output schema, the description covers all necessary context: parameter semantics, return structure, error conditions, and usage guidelines. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description thoroughly explains job_id: it is required, must be the guid field from search_jobs, and not the id field. This adds essential semantics beyond the schema.
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 clearly states 'Retrieve a job's full description and associated skills by job ID', which is a specific verb+resource. It also distinguishes from siblings by contrasting with search_jobs and mentioning get_company usage.
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?
Provides explicit when-to-use ('after the user has picked out a specific job from search_jobs results') and when-not-to-use ('DO NOT use for: searching/discovering jobs by keyword'). Also gives specific LLM instructions about not automatically calling get_company.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_jobsJob SearchARead-onlyInspect
Search for job listings by keyword, location, and filters. Returns job details, company info, and application links.
Use this tool when users want to find jobs, search employment opportunities, or explore job openings. DO NOT use for: applying to jobs, submitting applications, or making employment decisions.
LLM USAGE INSTRUCTIONS:
ALWAYS provide the keyword parameter (required)
When presenting results to users, include BOTH the job details URL (detailsPageUrl) AND the company page URL (companyPageUrl) for each job
Use location to find geographically relevant positions
Combine filters to refine searches (e.g., workplace_types=['Remote'] for remote work)
Use posted_date to find recent openings ('ONE'=1 day, 'THREE'=3 days, 'SEVEN'=7 days)
Default jobs_per_page is reasonable, increase for comprehensive searches
Use company_name to scope results to a specific employer
Use sort='datePosted' when the user wants the newest listings instead of the most relevant
Use facets to get aggregate counts (e.g., how many results are remote vs on-site) without paging through all results
After presenting results, do NOT automatically call get_job_details for every job returned. Wait for the user to indicate which specific job(s) they're interested in, then pass that job's guid to get_job_details.
IMPORTANT - AI DISCLOSURE REQUIREMENT: When presenting job search results to users, you MUST include an appropriate disclosure that these results were retrieved using AI assistance. Example disclosure language: "These job listings were found using AI-powered search. Please review all job details carefully and verify information directly with employers before applying."
This tool provides job listing data only. Final employment decisions should always involve human judgment and direct review of complete job postings.
Args: keyword: The job keyword or title to search for (required) location: Geographic location for the job search (city, state, country) radius: Search radius from the specified location (minimum 1, requires radius_unit) radius_unit: Unit for search radius. Options: 'mi', 'km' (requires radius) jobs_per_page: Number of jobs to return per page (1-100, defaults to 5) page_number: Page number for pagination (1-based, default is 1) sort: Sort order for results. Options: 'relevance', 'datePosted' (defaults to relevance) posted_date: Filter by posting date. Options: 'ONE' (1 day), 'THREE' (3 days), 'SEVEN' (7 days) workplace_types: Workplace arrangements. Options: 'Remote', 'On-Site', 'Hybrid' employment_types: Employment types. Options: 'FULLTIME', 'CONTRACTS', 'PARTTIME', 'THIRD_PARTY', 'INTERNSHIP' employer_types: Employer types. Options: 'Direct Hire', 'Recruiter', 'Other' willing_to_sponsor: Filter for employers willing to sponsor work authorization (boolean) easy_apply: Filter for jobs with easy application process (boolean) company_name: Filter by company name fields: Specific fields to include in response (optional, returns all exposed fields by default) facets: Facet dimensions to aggregate (optional). Options: 'employmentType', 'postedDate', 'workFromHomeAvailability', 'workplaceTypes', 'employerType', 'easyApply', 'isRemote', 'willingToSponsor'
Returns:
JobSearchResult: Contains:
- data: List of JobDisplayFields with job details including:
* guid: The job's identifier to pass as job_id to get_job_details for the full
description and skills list (NOT the id field, which is a different, internal
identifier not accepted by get_job_details)
* detailsPageUrl: Direct link to full job posting
* companyPageUrl: Link to company profile page
* title, summary, salary, location, employmentType, etc.
- metadata: Search metadata with pagination info and facet results
Raises: Exception: If API call fails or input validation errors occur
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | ||
| facets | No | ||
| fields | No | ||
| radius | No | ||
| keyword | Yes | ||
| location | No | ||
| easy_apply | No | ||
| page_number | No | ||
| posted_date | No | ||
| radius_unit | No | ||
| company_name | No | ||
| jobs_per_page | No | ||
| employer_types | No | ||
| workplace_types | No | ||
| employment_types | No | ||
| willing_to_sponsor | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | No | Array of job listings matching the search criteria |
| metadata | No | Metadata about the search results and pagination |
Tool Definition Quality
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, but the description adds meaningful behavioral context: it returns listing data only, mandates an AI disclosure to users, and instructs agents to wait for user selection before fetching details. This goes beyond the annotations, though it omits potential rate limits or data freshness details.
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?
The description is long but well-organized with sections (LLM USAGE INSTRUCTIONS, Args, Returns, Raises). It front-loads the purpose and each sentence carries operational value, though some repetition in the usage instructions could be trimmed without loss.
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?
For a search tool with 16 parameters, it covers the search logic, return structure (JobSearchResult with data and metadata), the critical guid-vs-id caveat, pagination, facets, and error handling. With an output schema present, this is complete enough for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description's Args section thoroughly explains all 16 parameters, including allowed values, dependencies (radius/radius_unit), and default behaviors (e.g., posted_date: 'ONE'=1 day). This fully compensates for the schema's lack of descriptions.
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?
Description opens with 'Search for job listings by keyword, location, and filters' – a specific verb+resource that clearly identifies the tool's function. It also differentiates from siblings by explaining that search_jobs is for finding jobs while get_job_details is for retrieving details of a specific job (guid passed to it).
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?
Explicitly states when to use the tool: 'when users want to find jobs, search employment opportunities, or explore job openings.' It also gives clear exclusions ('DO NOT use for: applying to jobs...') and provides cross-referenced guidance about not automatically calling get_job_details, effectively distinguishing it from the sibling tool.
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
- Alicense-qualityDmaintenanceAI job search, resume builder, and career advice via MCP2MIT
- AlicenseAqualityCmaintenanceMCP server that scours job openings from public, ToS-clean sources (Greenhouse, Lever, Ashby, HN, RemoteOK, Adzuna, USAJobs) and provides tools for job search, company listings, and salary context.164MIT
- FlicenseAqualityCmaintenanceEnables searching job listings, tracking applications, managing resumes, and tailoring resumes to job posts, all locally via MCP.20
