Which integrations are available for this server?

Allows filtering job listings based on US visa sponsorship availability. Provides tools for searching YC startup job listings, retrieving company profiles and job details, and filtering jobs by skills.

How do I use workatastartup-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@workatastartup-mcp Find remote machine learning jobs at YC startups that sponsor visas." 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.

de en es ja ko ru

workatastartup-mcp

by MIt9

Overview Schema Related Servers Score Discussions

Python

Remote

Work at a Startup MCP Server 🚀

PyPI version MIT License Python 3.10+ MCP Specification

A Model Context Protocol (MCP) server for querying Y Combinator jobs and companies via Work at a Startup.

This MCP server equips AI assistants (Claude Desktop, Cursor, Gemini CLI, Antigravity) with direct access to search YC startups, explore active job listings, inspect tech stacks, filter by required skills, salary ranges, equity, and US visa sponsorship status.

🛠️ Features & Available Tools

The server provides 4 FastMCP tools:

search_jobs: Search YC startup job listings with advanced filters.
- query (str): Search term (e.g. "backend", "AI agent", "Rust").
- role (Optional[str]): Functional role ("eng", "design", "product", "ops", "sales", "marketing").
- eng_type (Optional[str]): Engineering specialization ("be", "fe", "fs", "ml", "mobile").
- job_type (Optional[str]): Employment type (e.g. "fulltime", "contract").
- min_experience (Optional[int]): Maximum required experience level in years (min_experience <= N).
- max_team_size (Optional[int]): Maximum company team size (company_team_size <= N).
- batch (Optional[str]): YC Batch (e.g. "W24", "S23").
- remote (bool): Filter for remote positions (True / False).
- visa (bool): Filter for US visa sponsorship (True / False).
- page (int): Page index (default 0).
- limit (int): Number of companies per page (default 10).
get_company_details: Fetch detailed YC company profile & open roles.
- company_id (int): Unique YC company ID.
- Returns: YC Batch, website, team size, location, founders, tech stack description, and active open job listings.
get_job_details: Retrieve full details for a specific job listing.
- job_id (int): Unique job ID.
- Returns: Full job description (Markdown), role type, experience level, salary range, equity range, visa status, required skills, and direct application URL.
filter_jobs_by_skills: Filter active jobs matching a list of target technologies/skills.
- skills (List[str]): List of skills/technologies (e.g., ["Python", "PyTorch", "PostgreSQL"]).
- limit (int): Maximum number of matching jobs to return (default 10).

Related MCP server: workatastartup-mcp

💻 Quick Start & Installation

Option 1: Using `uvx` or `pipx` (Recommended)

Run instantly without cloning or manually installing:

uvx workatastartup-mcp

Option 2: Using `pip`

pip install workatastartup-mcp
workatastartup-mcp

Option 3: Development / Source Installation

git clone https://github.com/MIt9/workatastartup-mcp.git
cd workatastartup-mcp

python3 -m venv .venv
source .venv/bin/activate
pip install -e .

⚙️ Configuration for MCP Clients

Claude Desktop

Add to your claude_desktop_config.json:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "workatastartup": {
      "command": "uvx",
      "args": [
        "workatastartup-mcp"
      ]
    }
  }
}

Cursor / VS Code / Gemini CLI / Antigravity

{
  "mcpServers": {
    "workatastartup": {
      "command": "uvx",
      "args": [
        "workatastartup-mcp"
      ]
    }
  }
}

🧪 Running Tests

# Run unit & integration tests
.venv/bin/pytest

# Run fast unit tests only (skip live API calls)
.venv/bin/pytest -m "not integration"

📜 License

Distributed under the MIT License.

Available Tools

4 tools

filter_jobs_by_skillsC

Filter jobs by list of required skills.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`skills`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations and a minimal description, the behavioral impact is completely undisclosed. The tool could be a read-only filter or perform hidden side effects; the description gives no information about permissions, errors, return format, or side effects.

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 a single, compact sentence with no redundancy or unnecessary words. It is extremely concise and well-structured for a tool of this simplicity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description lacks essential context for an agent to use the tool correctly: it does not specify the output format, error handling, pagination details, or how it differs from 'search_jobs'. Without such information, the tool is not fully usable in a real workflow.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only the 'skills' parameter is partially explained by the description ('list of required skills'), but 'limit' is not mentioned at all. The description does not clarify what the limit controls (e.g., max results, pagination), so the meaning of this parameter is left entirely to inference.

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 action (filter), the resource (jobs), and the criterion (by list of required skills). It is specific enough to understand the basic purpose, but it does not explicitly differentiate from the sibling tool 'search_jobs', so it loses one point for lacking that distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus the alternative 'search_jobs'. It implies a filtering use case, but does not give explicit conditions or preferences, leaving the agent to infer the appropriate context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_company_detailsB

Get full company details by ID.

ParametersJSON Schema

Name	Required	Description	Default
`company_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the burden. It only says 'Get' which implies read-only, but does not disclose error behavior, authentication requirements, rate limits, or what 'full details' includes. Minimal behavioral context is given.

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 one sentence, front-loaded, with no filler. It efficiently states the purpose and parameter context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (get by ID) and the presence of an output schema (though not shown), the description is minimal. It lacks any edge-case or error behavior, but for a basic retrieval it may be sufficient. However, it doesn't mention return format or any other context.

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 0%, so the description should compensate. It does say 'by ID' which aligns with the parameter, but it does not add any format constraints, requiredness, or examples beyond what the schema already shows. For a single self-explanatory parameter, this is adequate but not enriching.

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 states a specific verb ('Get') and resource ('full company details') keyed by ID. It is clearly distinct from the siblings (jobs-related), so an agent can immediately identify its purpose without ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance on when to use this tool versus alternatives. While the sibling tools are about jobs)Skip the clear differentiation, there is no explicit statement of when this tool is appropriate or what it is not for.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_job_detailsA

Get job details by ID.

ParametersJSON Schema

Name	Required	Description	Default
`job_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations are absent, so the description carries the burden. 'Get' implies a read operation, which is safe, but the description doesn't disclose any return format, error behavior, or access requirements. It's a simple read, so the lack of detail is not critical, but it could be more transparent about the output structure.

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 a single sentence, extremely concise and direct. It provides the necessary information without any fluff. The purpose is front-loaded with the verb and resource.

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 simplicity (one parameter, no output schema specifics), the description is sufficiently complete. The agent likely knows what job details are (e.g., title, status, maybe timestamps) from the output schema (not provided to me but present in the actual definition). Since there is an output schema, the description doesn't need to explain return values. The only gap is the lack of differentiation from sibling tools.

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 schema description coverage is 0%, meaning the schema doesn't explain what 'job_id' is beyond its type. The description adds the meaning that the tool retrieves details based on this ID, which is essential. Since there is only one parameter and a clear description, the agent understands what to provide. However, it doesn't go beyond that basic meaning.

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 states a specific verb ('Get') and resource ('job details') with a clear parameter (by ID). It clearly identifies what the tool does. However, it does not distinguish this from sibling tools like 'get_company_details' or 'search_jobs', though the focus on 'job details' is somewhat distinctive.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. The description doesn't mention that this is for fetching a single job's details, while 'search_jobs' is for querying, or 'filter_jobs_by_skills' for filtering. No exclusions, but also no clear context to differentiate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_jobsC

Search YC startup jobs on WorkAtAStartup.

ParametersJSON Schema

Name	Required	Description	Default
`page`	No
`role`	No
`visa`	No
`batch`	No
`limit`	No
`query`	No
`remote`	No
`eng_type`	No
`job_type`	No
`max_team_size`	No
`min_experience`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Search' and does not mention pagination, filter interactions, or any operational behavior beyond what the name itself 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler, which is concise. However, the brevity crosses into under-specification because it omits nearly all operational detail needed to use the tool effectively.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 11 parameters, no annotations, and zero parameter descriptions, yet the description only identifies the domain. The output schema covers return values, but usage criteria, parameter semantics, and sibling differentiation are all unaddressed, making the tool difficult to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description names none of the 11 parameters such as query, remote, limit, or page. The agent receives no semantic help beyond parameter titles and defaults, which is insufficient for such a parameter-heavy tool.

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 uses a specific verb ('Search') and a clear resource ('YC startup jobs on WorkAtAStartup'), so an agent knows what the tool does. It does not explicitly contrast it with filter_jobs_by_skills, whose purpose could overlap, so it does not fully achieve sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance about when to use this tool versus siblings like filter_jobs_by_skills or get_job_details. It states neither preconditions, exclusions, nor conditions that would help route an agent to the correct tool.

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. Dates show when Glama detected each change.

4 tool updatesv0.1.2Aug 23, 2026
- First observedfilter_jobs_by_skills
- First observedget_company_details
- First observedget_job_details
- First observedsearch_jobs

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.9/5.0

Disambiguation4/5

Most tools are clearly separated by entity type and action, but 'search_jobs' and 'filter_jobs_by_skills' overlap in the job search space. A clear distinction between broad search and skill-based filtering exists, though not immediately obvious.

Naming Consistency2/5

Tool names mix verb_noun forms inconsistently: 'search_jobs' and 'get_company_details' use different verb styles, and 'filter_jobs_by_skills' is phrased much more verbosely than the others. A consistent pattern like 'list_jobs', 'get_job_details', 'get_company_details', and 'filter_jobs_by_skills' would be more predictable.

Tool Count5/5

Four tools is an appropriate, focused scope for a job board integration. Each tool covers a core function without bloat.

Completeness3/5

The surface covers searching jobs, filtering by skills, and retrieving company and job details, which handles primary browsing workflows. However, there are no tools for application-related actions or locating companies/jobs, leaving some workflow gaps.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

TheirStackOAuth
com.theirstack
Search job postings, companies, and technology stacks across 10M+ companies.
Search Research & Data Marketing
2
Career RiftOAuth
com.careerrift
Manage job applications — jobs, companies, boards, notes, and profile — from your AI client.
CRM Project Management
2
Trackly CLIOAuth
io.github.trackly-app
AI job search for Claude, ChatGPT, Cursor. 170K+ jobs, 3,800+ companies. OAuth or stdio.
Search Research & Data
23
remoet-mcpOAuth
io.github.remoet-labs
Job platform for AI agents. Track tech jobs from companies that match your stack.
Search Research & Data
22

Related MCP Servers

recruiting-jobs-mcp
Web Scraping Search Research & Data
emily397
F
license
Not graded
quality
C
maintenance
Enables AI agents to pull live job listings from major ATS platforms (Greenhouse, Lever, Ashby, Workable), Hacker News hiring threads, and detect hiring signals on company career pages.
Updated 3 months ago (2026-06-18 05:15 UTC)
-
workatastartup-mcp
Web Scraping
moutasem-isentemiz
A
license
A
quality
B
maintenance
Enables reading Y Combinator's Work at a Startup job postings and company details through a logged-in session, providing structured data to AI assistants.
Updated a month ago (2026-08-09 20:44 UTC)
2
MIT
remoote-mcp
Search
asmisha
A
license
Not graded
quality
C
maintenance
Enables AI agents to search and explore remote job listings, salary stats, and popular roles, and supports token-authenticated actions like job alerts and apply redirects.
Updated a month ago (2026-08-08 05:55 UTC)
MIT
Apify Wellfound Jobs API MCP
Search E-commerce & Retail
johnisanerd
F
license
Not graded
quality
B
maintenance
Enables searching and retrieving startup job listings from Wellfound with salary, equity, and company signals like Y Combinator backing, funding stage, and remote status.
Updated a day ago (2026-09-05 05:11 UTC)
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/MIt9/workatastartup-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Work at a Startup MCP Server 🚀

🛠️ Features & Available Tools

💻 Quick Start & Installation

Option 1: Using uvx or pipx (Recommended)

Option 2: Using pip

Option 3: Development / Source Installation

⚙️ Configuration for MCP Clients

Claude Desktop

Cursor / VS Code / Gemini CLI / Antigravity

🧪 Running Tests

📜 License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Option 1: Using `uvx` or `pipx` (Recommended)

Option 2: Using `pip`