Ein Model Context Protocol-Server, der es jedem KI-Assistenten ermöglicht, Jugendangebote – Stipendien, Fellowships, Praktika, Konferenzen und Austauschprogramme – zu durchsuchen, die live von führenden Plattformen zur Entdeckung von Möglichkeiten aggregiert werden.
Status: Alpha (
v0.1.x). Schema, Tool-Oberfläche und Quellenliste können sich mit der Reifung der Adapter ändern. Fixieren Sie in der Produktion auf eine Nebenversion.
Studierende, die auf Drittanbieter-Stipendien-Aggregatoren angewiesen sind, öffnen normalerweise zehn oder mehr Tabs, durchsuchen Dutzende irrelevanter Beiträge und kopieren Fristen in eine persönliche Tabelle – nur um dann das Bewerbungsfenster zu verpassen, weil kein Aggregator eine zuverlässige Fristenverfolgung bietet. Opportunity MCP reduziert diesen Arbeitsablauf auf eine einzige Konversationsabfrage.
Sie: Finde voll finanzierte Master-Stipendien in Europa mit Fristen in den nächsten 60 Tagen, für die pakistanische Staatsbürger infrage kommen.
Claude: (Gibt eine deduplizierte, strukturierte Liste zurück, die live aus den indizierten Quellen abgerufen, nach Frist sortiert wurde und jeweils auf den Originalartikel verlinkt.)
Der Server läuft lokal über stdio, liefert einen SQLite + FTS5-Index, der alle sechs Stunden über CI aktualisiert wird, und wird über PyPI, die offizielle MCP-Registry und Smithery verteilt.
Related MCP server: bounty-mcp
Kanal | Kennung | Status |
PyPI |
| ✅ live |
MCP Registry |
| ✅ veröffentlicht |
Smithery |
| ✅ veröffentlicht |
GitHub | Quelle der Wahrheit | |
GitHub Releases |
| automatisch durch CI veröffentlicht |
pip install opportunity-mcp
opportunity-mcp-refresh # build the local index (one-off, ~30 seconds)Fügen Sie Folgendes zu claude_desktop_config.json hinzu:
{
"mcpServers": {
"opportunities": {
"command": "opportunity-mcp"
}
}
}Starten Sie Claude Desktop neu. Die sechs unten aufgeführten Tools stehen dem Modell zur Verfügung.
Die meisten Clients verwenden dieselbe mcpServers-Form. Verweisen Sie den command auf opportunity-mcp (nach pip install) oder verwenden Sie uvx für eine Installation ohne Aufwand:
{
"mcpServers": {
"opportunities": {
"command": "uvx",
"args": ["opportunity-mcp"]
}
}
}https://smithery.ai/server/sayedhusnainhader/opportunity-mcp — Smithery übernimmt den Installationsbefehl für Sie.
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 stdioDer Server stellt sechs Tools bereit. Jedes akzeptiert JSON-Argumente und gibt Pydantic-typisierte Ergebnisse zurück.
Tool | Signatur | Beschreibung |
|
| Volltextsuche über alle indizierten Angebote mit optionalen Filtern. |
|
| Abrufen vollständiger Details für ein einzelnes Angebot anhand seiner ID. |
|
| Neueste Angebote aus allen Quellen, sortiert nach Veröffentlichungsdatum. |
|
| Angebote, die innerhalb von |
|
| Liste der indizierten Quellen, Elementanzahl und Zeitstempel der letzten Aktualisierung. |
|
| Quellen bei Bedarf neu abrufen. Das optionale |
type ist eines der folgenden: scholarship, fellowship, internship, conference, exchange, competition, grant, award oder other.
Live verifiziert gegen den RSS-Feed jeder Website.
Quelle | Mechanismus | Status |
RSS | ✅ live | |
RSS | ✅ live | |
RSS | ✅ live | |
RSS | ✅ live | |
RSS | ✅ live | |
RSS | ✅ live | |
RSS | ✅ Adapter live (Feed derzeit upstream leer) | |
HTML | geplant | |
HTML | geplant |
Die Einhaltung der robots.txt pro Quelle, ToS-Hinweise und CI-Besonderheiten sind in docs/SOURCES.md dokumentiert.
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 sitesZwei saubere Trennungen der Zuständigkeiten:
Adapter wissen, wie man eine Website liest und rohe Opportunity-Objekte (Pydantic-validiert) erstellt.
Die Abfrage-Engine weiß nichts über Websites – sie durchsucht einen normalisierten Index.
Das Hinzufügen einer neuen Quelle ist normalerweise ein Pull Request mit fünfzig Zeilen. Siehe docs/ADAPTER_GUIDE.md. Die vollständige Architektur-Begründung finden Sie in docs/ARCHITECTURE.md.
Kein Benutzer-Tracking. Alle Abfragen werden lokal verarbeitet; nichts verlässt den Computer des Benutzers außer der periodischen Aktualisierung der Quell-Website.
Alle indizierten Daten sind öffentlich. Zusammenfassungen sind auf 500 Zeichen begrenzt und jeder Datensatz verlinkt zurück zum ursprünglichen Artikel.
Höfliche Identifizierung. Der HTTP User-Agent enthält die Projekt-URL, damit Website-Betreiber uns direkt erreichen können.
Konservativer Aktualisierungsrhythmus. Quellen werden höchstens alle sechs Stunden über CI abgefragt – niemals bei einer Benutzerabfrage.
Quellenentfernungen auf Anfrage werden innerhalb von 24 Stunden ohne Verhandlung berücksichtigt.
robots.txt wird respektiert von jedem Adapter vor dem Abruf.
Phase 2 — länder-, stufen- und sprachbewusste Extraktion (derzeit an den KI-Client delegiert).
Phase 3 — erster HTML-Adapter (Youth Opportunities), breitere Abdeckung von Tier-2/Tier-4-Quellen.
Phase 4 — gehosteter Streamable-HTTP-Endpunkt für Clients, die entfernte MCP-Server bevorzugen.
Phase 5 — optionaler wöchentlicher Digest nach gespeichertem Profil.
Offene Issues mit dem Label add a source sind gute erste Beiträge.
Pull Requests sind willkommen. Der schnellste Weg zu helfen ist das Hinzufügen einer Quelle, die wir noch nicht indizieren – lesen Sie docs/ADAPTER_GUIDE.md und öffnen Sie einen PR. Siehe docs/CONTRIBUTING.md für Entwicklungseinrichtung, Testkonventionen und die Erwartungen an den Verhaltenskodex.
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.
