Un servidor del Protocolo de Contexto de Modelos (MCP) que permite a cualquier asistente de IA buscar oportunidades para jóvenes —becas, programas de investigación, pasantías, conferencias y programas de intercambio— agregadas en tiempo real desde los principales sitios de descubrimiento de oportunidades.
Estado: alfa (
v0.1.x). El esquema, la interfaz de herramientas y la lista de fuentes pueden cambiar a medida que los adaptadores maduren. Fije una versión menor en producción.
Los estudiantes que dependen de sitios de agregación de becas de terceros suelen abrir diez o más pestañas, revisar docenas de publicaciones irrelevantes y copiar las fechas límite en una hoja de cálculo personal, solo para perder el plazo de solicitud porque ningún agregador ofrece un seguimiento fiable de las fechas límite. Opportunity MCP reduce ese flujo de trabajo a una única consulta conversacional.
Tú: Busca becas de máster totalmente financiadas en Europa con fechas límite en los próximos 60 días, para las que sean elegibles los ciudadanos paquistaníes.
Claude: (Devuelve una lista estructurada y sin duplicados extraída en tiempo real de las fuentes indexadas, ordenada por fecha límite, con enlaces al artículo original.)
El servidor se ejecuta localmente a través de stdio, incluye un índice SQLite + FTS5 que se actualiza cada seis horas mediante CI, y se distribuye a través de PyPI, el Registro oficial de MCP y Smithery.
Related MCP server: bounty-mcp
Canal | Identificador | Estado |
PyPI |
| ✅ activo |
Registro MCP |
| ✅ publicado |
Smithery |
| ✅ publicado |
GitHub | fuente de verdad | |
GitHub Releases | instantáneas | auto-publicado por CI |
pip install opportunity-mcp
opportunity-mcp-refresh # build the local index (one-off, ~30 seconds)Añada lo siguiente a claude_desktop_config.json:
{
"mcpServers": {
"opportunities": {
"command": "opportunity-mcp"
}
}
}Reinicie Claude Desktop. Las seis herramientas siguientes estarán disponibles para el modelo.
La mayoría de los clientes utilizan la misma estructura mcpServers. Apunte el command a opportunity-mcp (después de pip install) o utilice uvx para una instalación cero:
{
"mcpServers": {
"opportunities": {
"command": "uvx",
"args": ["opportunity-mcp"]
}
}
}https://smithery.ai/server/sayedhusnainhader/opportunity-mcp — Smithery gestiona el comando de instalación por usted.
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 stdioEl servidor expone seis herramientas. Cada una acepta argumentos JSON y devuelve resultados tipados con Pydantic.
Herramienta | Firma | Descripción |
|
| Búsqueda de texto completo en todas las oportunidades indexadas con filtros opcionales. |
|
| Recupera los detalles completos de una sola oportunidad por su ID. |
|
| Oportunidades más recientes de todas las fuentes, ordenadas por fecha de publicación. |
|
| Oportunidades que cierran en |
|
| Lista las fuentes indexadas, el recuento de elementos y las marcas de tiempo de la última actualización. |
|
| Vuelve a obtener las fuentes bajo demanda. El argumento opcional |
type es uno de scholarship, fellowship, internship, conference, exchange, competition, grant, award o other.
Verificadas en tiempo real contra el feed RSS de cada sitio.
Fuente | Mecanismo | Estado |
RSS | ✅ activo | |
RSS | ✅ activo | |
RSS | ✅ activo | |
RSS | ✅ activo | |
RSS | ✅ activo | |
RSS | ✅ activo | |
RSS | ✅ adaptador activo (feed actualmente vacío en origen) | |
HTML | planificado | |
HTML | planificado |
El cumplimiento de robots.txt por fuente, las notas de los Términos de Servicio y las peculiaridades de CI están documentados en 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 sitesDos separaciones claras de responsabilidades:
Los adaptadores saben cómo leer un sitio y producir objetos Opportunity crudos (validados por Pydantic).
El motor de consultas no sabe nada sobre los sitios; busca en un índice normalizado.
Añadir una nueva fuente suele ser una solicitud de extracción (pull request) de cincuenta líneas. Consulte docs/ADAPTER_GUIDE.md. La justificación completa de la arquitectura se encuentra en docs/ARCHITECTURE.md.
Sin seguimiento de usuario. Todas las consultas se procesan localmente; nada sale de la máquina del usuario excepto la actualización periódica del sitio de origen.
Todos los datos indexados son públicos. Los resúmenes están limitados a 500 caracteres y cada registro enlaza con el artículo original.
Identificación educada. El User-Agent HTTP incluye la URL del proyecto para que los propietarios de los sitios puedan contactarnos directamente.
Cadencia de actualización conservadora. Las fuentes se consultan como máximo cada seis horas, a través de CI, nunca durante la consulta del usuario.
Las eliminaciones de fuentes bajo petición se cumplen en un plazo de 24 horas, sin negociación.
Se respeta robots.txt por cada adaptador antes de realizar la obtención.
Fase 2 — extracción consciente del país, nivel e idioma (actualmente delegada al cliente de IA).
Fase 3 — primer adaptador HTML (Youth Opportunities), cobertura más amplia de fuentes de Nivel 2/Nivel 4.
Fase 4 — punto final HTTP alojado y transmitible para clientes que prefieren servidores MCP remotos.
Fase 5 — resumen semanal opcional por perfil guardado.
Los problemas abiertos con la etiqueta add a source son buenas primeras contribuciones.
Las solicitudes de extracción son bienvenidas. La forma más rápida de ayudar es añadir una fuente que aún no indexamos: lea docs/ADAPTER_GUIDE.md y abra una PR. Consulte docs/CONTRIBUTING.md para la configuración de desarrollo, convenciones de prueba y expectativas del código de conducta.
git clone https://github.com/revolutionarybukhari/opportunity-mcp
cd opportunity-mcp
uv sync
uv run pytest
uv run ruff check .MIT © Colaboradores de 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.
