How do I use Unstop MCP Server?

1. Click on "Deploy 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., "@Unstop MCP Server Find online hackathons for college students with the highest prizes" 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.

Unstop MCP Server

by Abhinav-Prabhakar

Overview Schema Source Related Servers Discussions Admin

Python

Remote

Unstop MCP Server

unstop-mcp is a Python Model Context Protocol (MCP) server for discovering Unstop hackathons.

It exposes:

MCP tools for searching hackathons, fetching event details, running location-based discovery, and managing cache state
MCP resources for read-only snapshots and per-hackathon lookups
MCP prompts that help an LLM plan searches, compare hackathons, and recommend relevant events

This repository is now MCP-first. The old direct-import Python wrapper API is not the supported public interface anymore.

What It Supports

stdio transport only
Unstop hackathons only in v1
Automatic caching of open hackathons for fast repeated lookups
Detail enrichment for descriptions, rounds, contacts, registration counts, and views
Optional location-based search using geocoding
Deterministic unit tests with mocked upstream behavior
Optional live smoke tests kept separate from the default suite

Related MCP server: JobDataLake MCP Server

Requirements

Python 3.12+
uv recommended for local development
Network access for real Unstop calls

Installation

Option 1: `uv` workflow

git clone https://github.com/your-org/unstop-mcp.git
cd unstop-mcp
uv venv
source .venv/bin/activate
uv pip install -e .

Option 2: plain `pip`

git clone https://github.com/your-org/unstop-mcp.git
cd unstop-mcp
python3 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install -e .

Verify the install

unstop-mcp --help

You should see the stdio transport option.

Running The Server

Run the server locally over stdio:

unstop-mcp

Equivalent module form:

python -m unstop_mcp

The server intentionally supports only:

unstop-mcp --transport stdio

MCP Surface

Tools

`search_hackathons`

Search Unstop hackathons with filters, sorting, pagination, and optional cache usage.

Arguments:

oppstatus: open | recent | expired | closed
region: online | offline
payment: paid | unpaid
teamsize: 1 | 2 | 3
usertype: college_students | fresher | professionals | school_students
sort: prize | days_left
direction: asc | desc
search: free-text keyword search
page: >= 1
per_page: 1-100
use_cache: true | false

Returns a structured object with:

items: normalized hackathon summaries
pagination: total/current page/last page/per-page/has-more
cache: cache freshness metadata
applied_filters: the validated input used for the call

`get_hackathon_details`

Fetch full details for a single hackathon by numeric ID.

Arguments:

hackathon_id

Returns:

item: normalized detail view
cache: metadata describing current server cache state

`search_hackathons_by_location`

Find offline hackathons near a location using geocoding and radius filtering.

Arguments:

location
radius_km
region
payment
teamsize
usertype
search
sort: prize | days_left | distance
direction
page
per_page

Returns the same normalized structure as search_hackathons, plus:

location.search_location
location.search_radius_km
location.search_coordinates

`refresh_cache`

Force a rebuild of the cached open-hackathon dataset.

Returns:

cache

`get_cache_info`

Inspect cache state without rebuilding the full dataset.

Returns:

cache

Resources

`unstop://cache/info`

Read-only JSON view of cache freshness, TTL, and item counts.

`unstop://hackathons/open`

Read-only JSON snapshot of all cached open hackathons.

`unstop://hackathons/{hackathon_id}`

Read-only JSON detail view for a specific hackathon. The server serves cached data when possible and falls back to a direct detail fetch when needed.

Prompts

`find_relevant_hackathons`

Guides an LLM to gather missing user preferences, call the right search tool, and summarize the best matches.

Arguments:

user_goal

`compare_hackathons`

Guides an LLM to fetch multiple hackathons and compare them.

Arguments:

hackathon_ids

`plan_hackathon_search`

Guides an LLM on which tools and resources to call, in what order, for a discovery task.

Arguments:

user_request

Output Shape

Tool and resource results are normalized into stable JSON-friendly fields rather than returning raw upstream Unstop payloads as the primary contract.

Each hackathon item includes:

id
title
status
region
is_paid
public_url
description
prize_amount
prize_summary
filters
required_skills
organisation
address
registration
rounds
contacts
distance_km when applicable

This keeps the MCP contract predictable even if upstream response shapes vary.

Client Setup

Generic MCP client

Point your MCP client at this command:

unstop-mcp

If your client needs an absolute command path, use the one from your environment, for example:

/absolute/path/to/.venv/bin/unstop-mcp

Claude Desktop

Example claude_desktop_config.json entry:

{
  "mcpServers": {
    "unstop": {
      "command": "/absolute/path/to/.venv/bin/unstop-mcp",
      "args": []
    }
  }
}

Codex

Configure a local MCP server entry that launches:

{
  "command": "/absolute/path/to/.venv/bin/unstop-mcp",
  "args": []
}

If your Codex setup manages MCP servers through a separate config file or UI, use the same command and no extra arguments.

Development

Project layout

src/unstop_mcp/server.py: FastMCP server definition and MCP registration
src/unstop_mcp/service.py: Unstop fetching, caching, normalization, and geocoding logic
src/unstop_mcp/schemas.py: validated inputs and normalized output models
src/unstop_mcp/config.py: environment-driven runtime configuration
tests/: unit, MCP registration, stdio smoke, and optional live tests

Environment variables

These are optional:

UNSTOP_MCP_TIMEOUT
UNSTOP_MCP_MAX_RETRIES
UNSTOP_MCP_RETRY_DELAY
UNSTOP_MCP_CACHE_TTL_SECONDS
UNSTOP_MCP_DETAIL_WORKERS
UNSTOP_MCP_DETAIL_DELAY
UNSTOP_MCP_GEOCACHE_PATH
UNSTOP_MCP_USER_AGENT

How caching works

Searches for open hackathons can use an in-memory snapshot instead of hitting Unstop on every call
The snapshot is rebuilt automatically when stale
refresh_cache forces an immediate rebuild
The geocode cache is persisted to disk so repeated location lookups do not re-query the geocoder unnecessarily

Geocoding behavior

Location search depends on geopy
Offline hackathons with explicit coordinates are used directly
When coordinates are missing, the server tries multiple address variants and caches the result
Online-only hackathons are excluded from radius searches unless the query explicitly requests region="online"

Testing

Run the default test suite:

python -m pytest -q

What the default suite covers:

validation and parsing
normalized search responses
cache metadata and staleness behavior
location filtering
MCP tool/resource/prompt registration
basic end-to-end stdio startup and tool listing

Optional live smoke tests

These are excluded by default:

UNSTOP_MCP_RUN_LIVE_TESTS=1 python -m pytest -q -m live

Use live tests only when you want to verify the current Unstop integration against the real network.

Local Validation

Useful local checks:

python -m pytest -q
python -m unstop_mcp --help

If you already use an MCP Inspector, point it at the local unstop-mcp command and stdio transport to inspect registered tools, resources, and prompts interactively.

Error Handling

The server validates inputs before making upstream calls.

Common failure cases:

invalid enum values such as unsupported oppstatus or sort
empty or unresolvable location input
transient or permanent upstream Unstop failures
missing geocoding support for location search

When possible, tool failures are surfaced as clear MCP-facing validation or request errors.

Limitations

stdio only in v1
hackathons only in v1
upstream Unstop fields and availability can change
location accuracy depends on source address quality and geocoding quality
cache refresh can take longer than simple detail fetches because it enriches open hackathons in bulk

Extending The Server

If you want to add more Unstop opportunity types later, keep this split:

add new upstream fetch/parse logic in service.py
define new validated contracts in schemas.py
register new MCP surfaces in server.py

That keeps transport concerns separate from domain logic.

License

MIT

Available Tools

5 tools

get_cache_infoB

Inspect cache freshness, TTL, and item counts for the open hackathon snapshot.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It hints at read-only inspection ('inspect') but doesn't explicitly state if it's safe, non-destructive, or has any side effects. It also lacks details on rate limits, authentication needs, or what 'freshness' and 'TTL' entail in practice.

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, well-structured sentence that efficiently conveys the core purpose without unnecessary details. It's front-loaded with the key action ('inspect') and resources, making it easy to parse quickly with zero wasted words.

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 complexity (simple inspection with 0 parameters) and lack of annotations/output schema, the description is minimally adequate. It covers what the tool does but misses behavioral context (e.g., safety, side effects) and usage guidance, leaving gaps that could hinder an agent's understanding in a broader workflow.

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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a high baseline score. It could be a 5 if it explicitly noted the lack of parameters, but it's still effective as-is.

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's purpose with specific verbs ('inspect') and resources ('cache freshness, TTL, and item counts'), making it easy to understand what it does. However, it doesn't explicitly distinguish itself from sibling tools like 'refresh_cache' or 'get_hackathon_details', 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.

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 alternatives. It mentions 'open hackathon snapshot' but doesn't clarify if this is the only context or how it differs from siblings like 'refresh_cache' (which might update cache) or 'get_hackathon_details' (which might retrieve different data).

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

get_hackathon_detailsC

Fetch full details for a single Unstop hackathon by ID.

ParametersJSON Schema

Name	Required	Description	Default
`hackathon_id`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Fetch full details' which suggests a read-only operation, but it doesn't cover important aspects like authentication needs, rate limits, error handling, or what 'full details' entails (e.g., format, depth). This leaves significant gaps for an agent to 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 a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse quickly.

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?

Given the lack of annotations and output schema, the description is incomplete for a tool that fetches data. It doesn't explain what 'full details' includes, potential response formats, or error cases. For a read operation with no structured output documentation, more context is needed to guide an agent effectively.

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 description adds minimal semantics beyond the input schema, which has 0% description coverage. It clarifies that 'hackathon_id' is an integer used to fetch details for a single hackathon, but doesn't provide additional context like valid ranges or examples. With one parameter and low schema coverage, this is a baseline adequate explanation but lacks depth.

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 ('Fetch full details') and resource ('for a single Unstop hackathon by ID'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'search_hackathons' or 'search_hackathons_by_location', which likely return multiple results rather than single-item details.

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 minimal guidance by implying usage when you have a specific hackathon ID, but it doesn't explain when to use this tool versus alternatives like 'search_hackathons' for broader queries or other siblings. No explicit when-not-to-use or prerequisite information is included.

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

refresh_cacheB

Force an immediate refresh of the cached open hackathon dataset.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a write operation ('refresh') but doesn't specify permissions, side effects, or performance impacts. No details on rate limits, success/failure responses, or data consistency are included, leaving significant gaps.

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, efficient sentence with no wasted words, clearly front-loading the core action and resource. It's appropriately sized for a simple tool with no parameters.

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?

Given the tool's mutation nature (implied by 'refresh'), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like what 'refresh' entails, potential downtime, or return values, making it inadequate for safe and effective use.

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 tool has 0 parameters, and the schema description coverage is 100%, so no parameter information is needed. The description appropriately avoids redundant details, aligning with the baseline for zero-parameter tools.

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 ('Force an immediate refresh') and the target resource ('cached open hackathon dataset'), making the purpose specific and understandable. However, it doesn't explicitly distinguish this tool from its siblings like 'get_cache_info' or 'search_hackathons', which limits its 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 on when to use this tool versus alternatives, such as when cached data is stale or needs updating. It lacks context on prerequisites, exclusions, or comparisons to sibling tools, leaving usage unclear.

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

search_hackathonsC

Search Unstop hackathons with filters, sorting, pagination, and optional cache usage.

ParametersJSON Schema

Name	Required	Description	Default
`oppstatus`	No
`region`	No
`payment`	No
`teamsize`	No
`usertype`	No
`sort`	No
`direction`	No
`search`	No
`page`	No
`per_page`	No
`use_cache`	No

TDQS

C2.7/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions 'optional cache usage' but doesn't explain cache behavior, rate limits, authentication needs, or what happens when cache is enabled/disabled. This leaves significant gaps for a search tool with 11 parameters.

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 a single, efficient sentence that front-loads the core purpose. However, given the complexity (11 parameters, no schema descriptions), it might be too brief to be fully helpful, though it avoids unnecessary verbosity.

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?

For a tool with 11 parameters, 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain return values, error conditions, or the semantics of key parameters, leaving the agent with insufficient information to use the tool effectively.

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

Parameters2/5

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

Schema description coverage is 0%, so parameters like 'oppstatus', 'region', 'payment', etc., are completely undocumented in the schema. The description only generically mentions 'filters, sorting, pagination, and optional cache usage', failing to explain what each parameter means or how they interact, providing minimal compensation for the coverage gap.

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 ('Search') and resource ('Unstop hackathons'), making the purpose evident. However, it doesn't differentiate from sibling tools like 'search_hackathons_by_location', which could cause confusion about when to use each.

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 explicit guidance is provided on when to use this tool versus alternatives like 'search_hackathons_by_location'. The description mentions 'filters, sorting, pagination, and optional cache usage', but this describes capabilities rather than usage context or exclusions.

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

search_hackathons_by_locationC

Find offline Unstop hackathons within a radius of a city, address, or campus.

ParametersJSON Schema

Name	Required	Description	Default
`location`	Yes
`radius_km`	No
`region`	No
`payment`	No
`teamsize`	No
`usertype`	No
`search`	No
`sort`	No
`direction`	No
`page`	No
`per_page`	No

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool finds 'offline' hackathons, which is useful context, but doesn't address critical behavioral aspects like whether this is a read-only operation, what happens with invalid locations, rate limits, authentication requirements, or pagination behavior (despite having page/per_page parameters).

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, efficient sentence that conveys the core functionality without unnecessary words. It's appropriately sized and front-loaded with the essential information about what the tool does.

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?

For a tool with 11 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain the purpose of most parameters, doesn't describe the return format, and provides minimal behavioral context. The agent would struggle to use this tool effectively without additional information.

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

Parameters2/5

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

The description mentions 'radius' and 'city, address, or campus' which partially explains the 'location' and 'radius_km' parameters. However, with 11 total parameters and 0% schema description coverage, the description fails to explain the purpose of the other 9 parameters (region, payment, teamsize, usertype, search, sort, direction, page, per_page), leaving most parameters undocumented.

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's purpose: 'Find offline Unstop hackathons within a radius of a city, address, or campus.' It specifies the verb ('Find'), resource ('offline Unstop hackathons'), and scope ('within a radius'). However, it doesn't explicitly differentiate from the sibling 'search_hackathons' tool, which appears to be a more general search function.

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 minimal usage guidance. It implies this tool should be used for location-based searches ('within a radius of a city, address, or campus'), but offers no explicit comparison to the sibling 'search_hackathons' tool, no guidance on when not to use it, and no mention of prerequisites or alternatives.

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.

5 tool updatesv0.1.0Mar 21, 2026
- First observedget_cache_info
- First observedget_hackathon_details
- First observedrefresh_cache
- First observedsearch_hackathons
- First observedsearch_hackathons_by_location

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.3/5.0

Scored 2026-04-13 07:15 across 5 tools

Disambiguation4/5

Most tools have distinct purposes: get_cache_info inspects cache state, get_hackathon_details fetches a single hackathon, refresh_cache updates the cache, and search_hackathons searches with filters. However, search_hackathons and search_hackathons_by_location could cause some confusion as both search hackathons, though the latter is location-specific.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (e.g., get_cache_info, search_hackathons, refresh_cache). The naming is uniform and predictable, making it easy for an agent to understand the action and target.

Tool Count5/5

With 5 tools, the server is well-scoped for managing hackathon data and cache operations. Each tool serves a clear purpose without being overly sparse or bloated, fitting typical MCP server ranges.

Completeness4/5

The tools cover core operations for hackathon data (search, get details) and cache management (info, refresh), but there are minor gaps such as no explicit tool for creating or updating hackathon data, which might be outside the server's read-only scope. Overall, it supports common workflows effectively.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

CraloOAuth
ai.cralo
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
Agent Orchestration Developer Tools
1
toolfound A
com.toolfound
Agent-native launch platform and tool directory: search, alternatives, trending, launch via MCP.
Agent Orchestration Developer Tools Search
131
Singularity - MCP Discovery & Security Gateway AOAuth
io.github.gaurav-kumar-sinha-060705
Find, vet, and run MCP tools through a secure audited gateway with prompt-injection risk scoring
Security Developer Tools
511
geoOAuth
co.thinair
Geocoding, routing, isochrones, traffic, weather, and place search for AI agents. 19 MCP tools.
Location Services Weather Services Travel & Transportation
2

Related MCP Servers

Cerebral Valley MCP Server
Search Social Media
cerebralvalley
F
license
Not graded
quality
D
maintenance
Enables discovery and submission of AI community events, hackathons, and meetups through search by location, type, and date range, plus newsletter subscription capabilities.
Updated 10 months ago (2025-12-03 23:15 UTC)
-
JobDataLake MCP Server
Search Research & Data
echojobsio
A
license
A
quality
B
maintenance
Enables searching over 1 million enriched job listings from 20,000+ companies directly from MCP-compatible AI tools. Provides tools for job search, company profiles, and AI-powered similar job recommendations with real-time data updates.
Updated a month ago (2026-08-23 23:27 UTC)
4
86 npm
2
MIT
Microsoft Events MCP Server
Search Developer Tools
trsdn
A
license
A
quality
C
maintenance
Enables AI assistants to search, filter, and analyze Microsoft events (conferences, workshops, webinars) using the Microsoft Events API.
Updated a month ago (2026-08-20 22:43 UTC)
4
2
MIT
devpost-mcp-server
Search Research & Data
RohanMuppa
F
license
Not graded
quality
D
maintenance
Enables searching and analyzing Devpost hackathons, winning projects, and tech stack trends for hackathon preparation.
Updated 6 months ago (2026-03-26 18:21 UTC)
-

Unstop MCP Server

What It Supports

Requirements

Installation

Option 1: uv workflow

Option 2: plain pip

Verify the install

Running The Server

MCP Surface

Tools

search_hackathons

get_hackathon_details

search_hackathons_by_location

refresh_cache

get_cache_info

Resources

unstop://cache/info

unstop://hackathons/open

unstop://hackathons/{hackathon_id}

Prompts

find_relevant_hackathons

compare_hackathons

plan_hackathon_search

Output Shape

Client Setup

Generic MCP client

Claude Desktop

Codex

Development

Project layout

Environment variables

How caching works

Geocoding behavior

Testing

Optional live smoke tests

Local Validation

Error Handling

Limitations

Extending The Server

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Option 1: `uv` workflow

Option 2: plain `pip`

`search_hackathons`

`get_hackathon_details`

`search_hackathons_by_location`

`refresh_cache`

`get_cache_info`

`unstop://cache/info`

`unstop://hackathons/open`

`unstop://hackathons/{hackathon_id}`

`find_relevant_hackathons`

`compare_hackathons`

`plan_hackathon_search`