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., "@opportunity-mcp Find fully funded scholarships in Europe for Pakistani students with deadlines in the next 60 days"
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.
A Model Context Protocol server that lets any AI assistant search youth opportunities — scholarships, fellowships, internships, conferences, and exchange programs — aggregated live from leading opportunity-discovery sites.
Status: alpha (
v0.1.x). Schema, tool surface, and source list may change as adapters mature. Pin to a minor version in production.
Students who depend on third-party scholarship-aggregator sites typically open ten or more tabs, sift through dozens of irrelevant posts, and copy deadlines into a personal spreadsheet — only to miss the application window because no aggregator offers reliable deadline tracking. Opportunity MCP collapses that workflow into a single conversational query.
You: Find fully-funded master's scholarships in Europe with deadlines in the next 60 days, eligible for Pakistani citizens.
Claude: (Returns a deduplicated, structured list pulled live from the indexed sources, sorted by deadline, each linking back to the original article.)
The server runs locally over stdio, ships an SQLite + FTS5 index that refreshes every six hours via CI, and is distributed through PyPI, the official MCP Registry, and Smithery.
Related MCP server: bounty-mcp
Channel | Identifier | Status |
PyPI |
| ✅ live |
MCP Registry |
| ✅ published |
Smithery |
| ✅ published |
GitHub | source of truth | |
GitHub Releases |
| auto-published by CI |
pip install opportunity-mcp
opportunity-mcp-refresh # build the local index (one-off, ~30 seconds)Add the following to claude_desktop_config.json:
{
"mcpServers": {
"opportunities": {
"command": "opportunity-mcp"
}
}
}Restart Claude Desktop. The six tools below become available to the model.
Most clients use the same mcpServers shape. Point the command at opportunity-mcp (after pip install) or use uvx for zero-install:
{
"mcpServers": {
"opportunities": {
"command": "uvx",
"args": ["opportunity-mcp"]
}
}
}https://smithery.ai/server/sayedhusnainhader/opportunity-mcp — Smithery handles the install command for you.
git clone https://github.com/revolutionarybukhari/opportunity-mcp
cd opportunity-mcp
uv sync # or: pip install -e ".[dev]"
uv run opportunity-mcp-refresh
uv run opportunity-mcp # speaks MCP over stdioThe server exposes six tools. Each accepts JSON arguments and returns Pydantic-typed results.
Tool | Signature | Description |
|
| Full-text search across all indexed opportunities with optional filters. |
|
| Retrieve full details for a single opportunity by its ID. |
|
| Newest opportunities across all sources, sorted by post date. |
|
| Opportunities closing within |
|
| List indexed sources, item counts, and last-refresh timestamps. |
|
| Re-fetch sources on demand. Optional |
type is one of scholarship, fellowship, internship, conference, exchange, competition, grant, award, or other.
Verified live against each site's RSS feed.
Source | Mechanism | Status |
RSS | ✅ live | |
RSS | ✅ live | |
RSS | ✅ live | |
RSS | ✅ live | |
RSS | ✅ live | |
RSS | ✅ live | |
RSS | ✅ adapter live (feed currently empty upstream) | |
HTML | planned | |
HTML | planned |
Per-source robots.txt compliance, ToS notes, and CI quirks are documented in docs/SOURCES.md.
Find fully-funded master's scholarships in Europe with deadlines in the next 60 days.
What conferences are happening in Africa in the next three months?
List the ten newest internships indexed today.
Show me everything closing in the next seven days that an undergraduate could apply to.
Get full details for opportunity 7733b95a81e3239d.AI client ──MCP──▶ FastMCP server ──▶ SQLite + FTS5 ◀── refresh job ──▶ source adapters ──▶ opportunity sitesTwo clean separations of concern:
Adapters know how to read one site and produce raw Opportunity objects (Pydantic-validated).
The query engine knows nothing about sites — it searches a normalized index.
Adding a new source is typically a fifty-line pull request. See docs/ADAPTER_GUIDE.md. Full architecture rationale is in docs/ARCHITECTURE.md.
No user tracking. All queries are processed locally; nothing leaves the user's machine except the periodic source-site refresh.
All indexed data is public. Summaries are capped at 500 characters and every record links back to the originating article.
Polite identification. The HTTP User-Agent includes the project URL so site owners can reach us directly.
Conservative refresh cadence. Sources are polled at most every six hours, via CI — never on user query.
Source removals on request are honored within 24 hours, with no negotiation.
robots.txt is respected by every adapter prior to fetching.
Phase 2 — country-, level-, and language-aware extraction (currently delegated to the AI client).
Phase 3 — first HTML adapter (Youth Opportunities), broader Tier-2/Tier-4 source coverage.
Phase 4 — hosted Streamable-HTTP endpoint for clients that prefer remote MCP servers.
Phase 5 — optional weekly digest by saved profile.
Open issues with the add a source label are good first contributions.
Pull requests are welcome. The fastest way to help is to add a source we do not yet index — read docs/ADAPTER_GUIDE.md and open a PR. See docs/CONTRIBUTING.md for development setup, testing conventions, and the code-of-conduct expectations.
git clone https://github.com/revolutionarybukhari/opportunity-mcp
cd opportunity-mcp
uv sync
uv run pytest
uv run ruff check .MIT © Opportunity MCP Contributors.
Get full details for a single opportunity by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It indicates a read operation ('Get full details'), but lacks details on auth, rate limits, or response complexity. Adequate for a simple retrieval.
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 sentence, no wasted words. Efficient and 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?
Given the tool's simplicity (1 param, output schema present), the description covers the essential purpose and method. Missing guidance on behavior like error handling or caching, but sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds 'by ID' to clarify the single parameter, but does not provide further semantic detail beyond the schema.
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 verb 'Get', the resource 'full details for a single opportunity', and the method 'by ID'. It distinguishes from sibling tools like 'list_latest' and 'search_opportunities'.
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 usage when needing details of a specific opportunity, but provides no explicit when-to-use or alternatives. No guidance on when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the newest opportunities across all sources, most recent first.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions ordering (most recent first) and scope (all sources), but does not address authentication needs, rate limits, pagination, or whether the returned list is exhaustive (beyond a default limit of 20). The absence of such context limits transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded. However, it omits key information about parameters and does not structure additional details (e.g., bullet points). While not overly verbose, it lacks completeness.
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 the sibling tools and the presence of an output schema, the description should provide enough context for correct tool selection and invocation. It fails to describe the filtering capability (type) and result limit, and offers no guidance on alternative tools for different queries. This makes it incomplete for agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% parameter description coverage, and the description does not mention the 'type' or 'limit' parameters. An agent cannot infer that 'type' filters by opportunity category or that 'limit' controls result count. This is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists the newest opportunities across all sources, sorted most recent first. This distinguishes it from sibling tools like list_upcoming_deadlines (deadline-focused) and search_opportunities (search-based). However, it does not explicitly note that it returns a limited set or that it can be filtered by type.
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?
No guidance is provided on when to use this tool versus alternatives such as search_opportunities for keyword search or list_upcoming_deadlines for deadline-oriented queries. Agents are left to infer usage context from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List indexed sources, the count each contributed, and last-refresh time.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits beyond the basic operation. It fails to mention whether it is read-only, if authentication is needed, or any side effects. For a tool with no annotations, the description should provide more transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose without extraneous information. Every phrase adds value.
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 no output schema is shown (though marked present), the description adequately explains the returned data. It covers the main elements but omits potential details like sorting or pagination.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description adds meaningful context by specifying what the output includes (count and refresh time). This compensates well for the lack of parameter documentation.
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 action (list), the resource (indexed sources), and the specific details included (count each contributed, last-refresh time). It distinguishes itself from sibling tools like search_opportunities and refresh_index.
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 does not explicitly state when to use this tool versus alternatives. Usage context is implied as a simple listing, but no guidance on when not to use or when to prefer siblings like refresh_index.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List opportunities with deadlines in the next N days, soonest first.
Args: within_days: Look ahead this many days from today. Default 30. type: Optional filter by opportunity type.
| Name | Required | Description | Default |
|---|---|---|---|
| within_days | No | ||
| type | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains filtering by deadline window and sorting, but lacks details on edge cases (e.g., negative within_days, inclusiveness of today). With no annotations, more behavioral context would be helpful.
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 extremely concise: one sentence for purpose and two lines for parameters. Every word is necessary, and the 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?
Given the tool's simplicity and the presence of an output schema, the description covers the essential functionality and parameters. It could add a note on the filtering logic (e.g., inclusive of today) but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds meaning by explaining within_days as a look-ahead and type as an optional filter. However, the explanations are minimal and could mention the possible enum values for type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists opportunities with deadlines in the next N days, sorted soonest first. It uses a specific verb and resource, distinguishing it from siblings like search_opportunities and list_latest.
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 the tool is for upcoming deadlines, but it does not provide explicit guidance on when to use it versus alternatives, nor does it state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Refresh the local index by re-fetching sources.
Args: source: If provided, only refresh this source by name. Otherwise refresh all.
| Name | Required | Description | Default |
|---|---|---|---|
| source | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. 'Refresh' implies an operation that modifies local state, but the description does not disclose if it's destructive, requires permissions, or affects other users. Insufficient detail for a mutation tool.
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 brief sentences plus an Arguments section, front-loading the main action. Every sentence provides essential information with no waste.
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 parameter and no output schema, the description covers functionality and parameter semantics. However, it omits expected return value or confirmation message, which is a gap for completeness.
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 zero description coverage, so the description carries full burden. It clarifies that the 'source' parameter specifies which source to refresh (by name) and defaults to refreshing all. This adds meaning beyond the schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool refreshes the local index by re-fetching sources. It distinguishes from sibling tools by focusing on refresh rather than listing or searching, though explicit sibling differentiation is absent.
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 guidance on using the 'source' parameter to refresh a specific source vs. all. However, it does not specify when to use this tool over alternatives like list_sources or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search across all indexed opportunities.
Args: query: Natural-language search query (e.g. "fully funded master's scholarship Germany"). type: Optional filter by opportunity type (scholarship, fellowship, internship, conference, …). funded_only: If True, only return fully-funded opportunities. deadline_before: Only return opportunities with deadlines on or before this date (ISO YYYY-MM-DD). limit: Maximum number of results. Default 20.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| type | No | ||
| funded_only | No | ||
| deadline_before | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It explains the search functionality and parameters effectively but does not mention pagination, ordering, potential rate limits, or authentication requirements. The output schema exists but is not referenced, so return value behavior is implied rather than stated.
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 well-structured with a clear purpose sentence followed by a numbered list of parameters. It is relatively concise but includes a slightly verbose example for 'query.' Each sentence adds value, though the example could be considered extraneous.
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 the tool complexity (5 parameters, search with filters) and the presence of an output schema, the description covers parameter semantics thoroughly. It does not explain edge cases or output structure, but the output schema mitigates this. Overall, it provides sufficient context for an agent to select and invoke the tool appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description carries the full burden. It provides clear and meaningful explanations for all five parameters, including examples for 'query' and acceptable values for 'type' (e.g., 'scholarship, fellowship'), default values, and format for 'deadline_before' (ISO YYYY-MM-DD). This adds substantial context beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Full-text search across all indexed opportunities,' which clearly identifies the verb (search) and resource (opportunities). It distinguishes itself from sibling tools like get_opportunity (single item retrieval) and list_latest (recent listings) by focusing on text-based search with filters.
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 provides usage context by giving example queries and explaining each parameter. However, it does not explicitly state when to use this tool over alternatives or when not to use it. No mention of exclusions or prerequisites is present.
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.1get_opportunitylist_latestlist_sourceslist_upcoming_deadlinesrefresh_indexsearch_opportunitiesScored across 6 tools
Each tool has a clearly distinct purpose: getting a single opportunity, listing latest, browsing sources, upcoming deadlines, refreshing data, and full-text search. No overlap in functionality.
All tools follow a consistent verb_noun pattern (get_, list_, refresh_, search_) using snake_case, making them predictable.
With 6 tools covering core operations (retrieve, list, search, manage index) for an opportunity discovery server, the count is well-scoped and each tool serves a clear need.
The set covers key operations (retrieve, list, search, refresh) but lacks filtering options on list_latest (e.g., by type or funded status), which is a minor gap. Overall, it's adequate for the domain.
Deterministic eligibility checker for grants, jobs and scholarships in Africa.
Search US grants + federal contracts (Grants.gov + SAM.gov) from any LLM.
Public fellowship and grant search with sourced details and live filter vocabularies.
Live EU funding data in your AI: grant calls, programmes, consortium partners, VCs, incubators.
