Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@kcdevs-mcp Find senior backend jobs in Kansas City paying over $130k"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server for the Kansas City software-developer job market. It lets AI assistants (Claude, Cursor, Windsurf, ChatGPT, etc.) search live KC dev jobs, look up hiring companies, and pull real salary and demand statistics.
Powered by kcdevs.com. All data is served remotely — nothing runs locally and no API key is required.
{
"mcpServers": {
"kcdevs": {
"command": "npx",
"args": ["-y", "kcdevs-mcp"]
}
}
}The same server can run as a remote HTTP endpoint, so clients that support remote MCP can connect without installing anything:
MCP_TRANSPORT=http PORT=8080 npx kcdevs-mcp
# → POST http://localhost:8080/mcp (stateless JSON-RPC)
# → GET http://localhost:8080/healthRelated MCP server: @career-now/mcp
search_jobsSearch live KC-area developer jobs (and KC-based remote roles).
Param | Type | Description |
| string | Keyword (title, company, description). |
| enum |
|
| string | Skill slug, e.g. |
| enum |
|
| enum |
|
| number | Minimum advertised salary in USD. |
| enum |
|
| enum |
|
| number | 1–50 (default 25). |
get_jobFull detail of one job by its id (slug from search_jobs) — description, salary, skills, apply link.
list_companiesKC companies with open developer roles, ordered by number of openings.
get_companyOne company by its id (slug from list_companies) — overview, HQ, typical roles, top-hired skills,
and current open roles.
market_statsLive snapshot of the KC developer job market: active jobs, companies hiring, median + interquartile advertised salary (USD, suppressed under 20 data points), demand by category, most in-demand skills, and the remote/hybrid/on-site mix.
Example agent uses: "Find senior backend jobs in Kansas City paying over $130k," "Which KC companies are hiring React developers?", "What's the median developer salary in Kansas City right now?"
KCDEVS_API_BASE — override the job-data API base (default https://kcdevs.com).
MCP_TRANSPORT — stdio (default) or http.
PORT / MCP_PATH — port and path for HTTP mode (default 8080 / /mcp).
Backed by the public read-only API at https://kcdevs.com/api/v1 (/jobs, /companies, /stats).
Read-only; per-IP rate limited.
MIT
Fetch one KC company by its id (slug, from list_companies): overview, headquarters, typical roles, the skills it hires for most, and its current open roles.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The company id/slug returned by list_companies. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description itself must convey the operation's nature. 'Fetch' clearly communicates a read-only actionaging non-destructive, and the description enumerates exactly what is returned. It does not mention error conditions or rate limits, but for a simple fetch these are minor.
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?
Single dense sentence that states the action, the key parameter, and the return contents. No wasted words.
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?
The tool has one parameter, no annotations, and no output schema. The description covers the input source, the action, and the full list of returned fields, which is sufficient for an agent to decide to call it and interpret the result.
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 already describes the id parameter, and the description reinforces it as a slug from list_companies. This adds useful sourcing context beyond the schema's description without being redundant.
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?
Description uses a specific verb+resource ('Fetch one KC company by its id') and names the exact returned fields (overview, headquarters, typical roles, skills, open roles). This clearly distinguishes it from siblings like list_companies (plural listing) and get_job (job-specific).
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?
Description explicitly states the input is the slug from list_companies, teaching the agent that get_company is the follow-up to a list operation. It does not explicitly mention exclusions or alternatives, but the id provenance and singular scope imply the right usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the full detail of one Kansas City developer job by its id (slug, from search_jobs). Returns the complete description, salary, skills, and apply link.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The job id/slug returned by search_jobs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. The description states it 'Returns the complete description, salary, skills, and apply link,' which gives some insight into the response content. However, it does not mention any potential side effects (though this is a read operation, it's not explicitly stated), authentication requirements, or rate limits. It adds value by detailing the return fields but is minimal on other behavioral aspects, so a 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 two sentences with no redundant words. The first sentence states the purpose and the input source; the second sentence lists the return fields. It is well-structured and front-loaded with the action, making it easy for an agent to quickly understand the tool. No filler or irrelevant details, earning a top score.
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 tool with one required parameter that is fully described in the schema, and with siblings like search_jobs that provide the id, the description is complete for an agent to call it correctly. The return fields are described, and the input source is clear. No output schema exists but the description covers the key return elements. There are no obvious gaps that would prevent correct invocation.
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 has 100% coverage (the parameter 'id' is described as 'The job id/slug returned by search_jobs'). The description reiterates this by saying 'from search_jobs,' adding no additional semantic detail beyond what the schema already provides. The description does not clarify the format of the id (e.g., string length, URL encoding) or provide examples sums. With high schema coverage, the baseline is 3, and the description adds negligible extra value, so 3 is justified.
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 purpose: 'Fetch the full detail of one Kansas City developer job by its id.' It identifies the specific resource (a job listing) and the action (fetch full detail), and distinguishes itself from siblings like search_jobs by noting the id comes from search_jobs. This is specific and unambiguous, earning a top 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 when to use this tool: after search_jobs has returned a job id/slug, as it says 'from search_jobs.' It also names the source of the id, which is the primary context. However, it does not explicitly state when not to use it or mention alternatives (e.g., if you need multiple jobs, use search_jobs instead). It provides clear context but lacks explicit exclusions, so a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Kansas City companies that currently have open developer roles, ordered by number of open jobs. Returns each company with its open-role count and a link.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure. It clearly states the result is read-only, sorted by open role count, and includes company plus count/link. It could additionally disclose limits/pagination, but it is transparent for a simple list operation.
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 concise sentences: the first states the action and ordering, the second states the returned fields. No filler and the key purpose is front-loaded.
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 zero-parameter read-only list endpoint, the description covers purpose, sort order, and output fields. It could specify the destination or form of the link and any pagination/limit, but the core call context is clear.
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 tool has zero parameterspublications, so no parameter meaning is needed; baseline of 4 is appropriate because there is nothing ambiguous for the agent to resolve.
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?
Names a specific resource (Kansas City companies with open developer roles), a concrete action (list), and defines the output. The sibling tools like get_job and search_jobs are clearly distinct because this one returns companies, not individual 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 intended use is strongly implied by the description: call this when you want companies hiring developers in Kansas City. However, there is no explicit guidance on when to choose this over siblings such as search_jobs or get_company.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a live snapshot of the Kansas City software-developer job market: number of active jobs, companies hiring, median and interquartile advertised salary (USD, suppressed under 20 data points), demand by category, the most in-demand skills, and the remote/hybrid/on-site mix. Sourced from kcdevs.com.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses a key behavioral trait: salary statistics are suppressed under 20 data points, and it states the data is live and sourced from kcdevs.com. This goes beyond a mere operation name and informs the agent of data-quality caveats.
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?
A single, well-structured sentence that front-loads the core purpose and then lists the return contents in a colon-delimited list. Every clause adds value; there is no filler 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?
Given there is no output schema, the description fully specifies the return payload: active job count, hiring companies, salary statistics (with suppression rule), demand by category, in-demand skills, and location mix. This is sufficient for an agent to know exactly what it will receive, plus the data source for trust.
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 tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to add about parameter meaning, and it does not attempt to invent any.
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 states a specific verb ('Get'), a precise resource ('live snapshot of the Kansas City software-developer job market'), and enumerates the exact data points it returns. It is clearly distinct from sibling tools (get_job, list_companies, search_jobs, get_company) which target individual records, while this targets aggregate market statistics.
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 gives clear context: it is a market-level snapshot, implying use when aggregate statistics are needed rather than individual jobs or companies. However, it does not explicitly name alternatives or state when not to use it, so it falls short of the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search live software-developer and tech jobs in the Kansas City area (and KC-based remote roles). Filter by keyword, category, skill, experience level, remote type, minimum salary, and how recently posted. Returns matching roles with company, location, salary, and a link to apply. Data is live from kcdevs.com.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Free-text keyword (matches title, company, description). | |
| sort | No | Sort order (default newest). | |
| skill | No | Skill slug, e.g. "react", "python", "aws". | |
| remote | No | Work arrangement. | |
| category | No | Job category to filter by. | |
| per_page | No | Results per page (max 50). | |
| experience | No | Experience level. | |
| salary_min | No | Minimum advertised salary in USD (e.g. 120000). | |
| posted_within | No | Only jobs first seen within this window. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It goes beyond the schema by disclosing the data source ('Data is live from kcdevs.com' — implying freshness and external origin) and describing the return shape (company, location, salary, apply link). For a search tool this is solid behavioral context, though it doesn't address pagination mechanics or result limits beyond the per_page schema field.
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?
Three sentences with zero waste: scope first, then filters, then return shape and data source. Front-loaded with the core purpose before enumerating filter options. Every sentence earns its place and nothing is redundant with the schema.
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 search tool with a rich 9-parameter schema at 100% coverage, the description covers the essential non-schema facts: geographic scope, live data source, and return fields. Minor gaps include unspecified pagination behavior and no mention of how results are ordered when no sort is given (beyond the schema default 'newest'). These are small against the overall coverage.
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 coverage is 100% — all 9 parameters have descriptions. The description recapitulates the filter dimensions (keyword, category, skill, experience, remote type, salary, recency) but adds no meaning beyond the schema's own parameter descriptions. Baseline 3 applies because the schema already does the heavy lifting; the description merely confirms the dimensions without adding syntax, defaults, or interaction notes.
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 states a specific verb (search) and a clearly bounded resource (live software-developer/tech jobs in the Kansas City area and KC-based remote roles). It lists the filter dimensions, making the tool's scope unmistakable and differentiating it from siblings like get_job (single job) and market_stats (aggregate stats) without needing to open any schema.
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 establishes a clear geographic scope (Kansas City, KC-based remote) and a live-data source, which helps an agent decide when this tool applies. However, it gives no explicit exclusions and never references alternatives — it doesn't say 'for a single job use get_job' or 'for company details use get_company.' The context implies the right usage but doesn't spell out the decision boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_companyget_joblist_companiesmarket_statssearch_jobsScored across 5 tools
Each tool targets a distinct resource/action: job detail, job search, company list, company detail, and market aggregate. No overlapping purposes.
Most tools follow a clear verb_noun pattern (get_job, search_jobs, list_companies, get_company). market_stats breaks the pattern by using a noun phrase instead of get_market_stats, a minor inconsistency.
Five tools is well-scoped for a job-board MCP, covering search, detail, company lookup, and market overview without unnecessary surface area.
The read-only domain is fully covered: job search/detail, company list/detail, and market statistics. There are no obvious dead ends or missing operations for the stated purpose.
Search job postings, companies, and technology stacks across 10M+ companies.
Job search for Claude, ChatGPT, Cursor. 250K+ jobs, 5,400+ companies. OAuth or stdio.
Tech job market intelligence: jobs, companies, salaries, skill velocity, hiring trends.
Job platform for AI agents. Track tech jobs from companies that match your stack.
