Сервер протокола контекста модели (MCP), который позволяет любому ИИ-ассистенту искать молодежные возможности — стипендии, гранты, стажировки, конференции и программы обмена — агрегированные в режиме реального времени с ведущих сайтов по поиску возможностей.
Статус: альфа (
v0.1.x). Схема, набор инструментов и список источников могут измениться по мере доработки адаптеров. В продакшене рекомендуется фиксировать минорную версию.
Студенты, которые зависят от сторонних сайтов-агрегаторов стипендий, обычно открывают десять или более вкладок, просматривают десятки нерелевантных публикаций и копируют сроки подачи заявок в личную таблицу — только для того, чтобы пропустить окно подачи, потому что ни один агрегатор не предлагает надежного отслеживания сроков. Opportunity MCP сводит этот рабочий процесс к одному диалоговому запросу.
Вы: Найди полностью финансируемые магистерские стипендии в Европе со сроком подачи в ближайшие 60 дней, доступные для граждан Пакистана.
Claude: (Возвращает дедуплицированный структурированный список, полученный в реальном времени из проиндексированных источников, отсортированный по сроку подачи, с ссылками на оригинальные статьи.)
Сервер работает локально через stdio, поставляется с индексом SQLite + FTS5, который обновляется каждые шесть часов через CI, и распространяется через PyPI, официальный реестр MCP и Smithery.
Related MCP server: bounty-mcp
Канал | Идентификатор | Статус |
PyPI |
| ✅ работает |
MCP Registry |
| ✅ опубликовано |
Smithery |
| ✅ опубликовано |
GitHub | источник истины | |
GitHub Releases | снимки | автопубликация через CI |
pip install opportunity-mcp
opportunity-mcp-refresh # build the local index (one-off, ~30 seconds)Добавьте следующее в claude_desktop_config.json:
{
"mcpServers": {
"opportunities": {
"command": "opportunity-mcp"
}
}
}Перезапустите Claude Desktop. Шесть инструментов, описанных ниже, станут доступны модели.
Большинство клиентов используют ту же структуру mcpServers. Укажите command для opportunity-mcp (после pip install) или используйте uvx для установки без настройки:
{
"mcpServers": {
"opportunities": {
"command": "uvx",
"args": ["opportunity-mcp"]
}
}
}https://smithery.ai/server/sayedhusnainhader/opportunity-mcp — Smithery выполнит команду установки за вас.
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 stdioСервер предоставляет шесть инструментов. Каждый принимает аргументы в формате JSON и возвращает результаты, типизированные через Pydantic.
Инструмент | Сигнатура | Описание |
|
| Полнотекстовый поиск по всем проиндексированным возможностям с дополнительными фильтрами. |
|
| Получение полной информации об одной возможности по её ID. |
|
| Новейшие возможности по всем источникам, отсортированные по дате публикации. |
|
| Возможности, срок подачи которых истекает в течение |
|
| Список проиндексированных источников, количество элементов и временные метки последнего обновления. |
|
| Повторная выборка источников по запросу. Опциональный аргумент |
type может принимать значения: scholarship, fellowship, internship, conference, exchange, competition, grant, award или other.
Проверены в реальном времени на соответствие RSS-ленте каждого сайта.
Источник | Механизм | Статус |
RSS | ✅ работает | |
RSS | ✅ работает | |
RSS | ✅ работает | |
RSS | ✅ работает | |
RSS | ✅ работает | |
RSS | ✅ работает | |
RSS | ✅ адаптер работает (лента в данный момент пуста на стороне источника) | |
HTML | запланировано | |
HTML | запланировано |
Соблюдение robots.txt для каждого источника, примечания об условиях использования (ToS) и особенности CI задокументированы в 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 sitesДва четких разделения ответственности:
Адаптеры знают, как читать сайт и создавать «сырые» объекты Opportunity (проверенные через Pydantic).
Механизм запросов ничего не знает о сайтах — он ищет по нормализованному индексу.
Добавление нового источника обычно представляет собой pull-request на пятьдесят строк. См. docs/ADAPTER_GUIDE.md. Полное обоснование архитектуры приведено в docs/ARCHITECTURE.md.
Никакого отслеживания пользователей. Все запросы обрабатываются локально; с компьютера пользователя ничего не уходит, кроме периодического обновления данных с сайтов-источников.
Все проиндексированные данные являются публичными. Краткие описания ограничены 500 символами, и каждая запись содержит ссылку на исходную статью.
Вежливая идентификация. HTTP-заголовок User-Agent включает URL проекта, чтобы владельцы сайтов могли связаться с нами напрямую.
Консервативный график обновления. Источники опрашиваются не чаще, чем раз в шесть часов, через CI — никогда не во время запроса пользователя.
Удаление источников по запросу выполняется в течение 24 часов без каких-либо переговоров.
robots.txt соблюдается каждым адаптером перед выполнением запроса.
Фаза 2 — извлечение данных с учетом страны, уровня и языка (в настоящее время делегировано ИИ-клиенту).
Фаза 3 — первый HTML-адаптер (Youth Opportunities), более широкое покрытие источников уровня Tier-2/Tier-4.
Фаза 4 — размещенная конечная точка Streamable-HTTP для клиентов, предпочитающих удаленные MCP-серверы.
Фаза 5 — опциональная еженедельная рассылка по сохраненному профилю.
Открытые задачи с меткой add a source — отличный способ сделать первый вклад.
Pull-requests приветствуются. Самый быстрый способ помочь — добавить источник, который мы еще не индексируем — прочитайте docs/ADAPTER_GUIDE.md и откройте PR. См. docs/CONTRIBUTING.md для настройки разработки, соглашений о тестировании и ожиданий относительно кодекса поведения.
git clone https://github.com/revolutionarybukhari/opportunity-mcp
cd opportunity-mcp
uv sync
uv run pytest
uv run ruff check .MIT © Участники Opportunity MCP.
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.
