주요 기회 탐색 사이트에서 실시간으로 집계된 장학금, 펠로우십, 인턴십, 컨퍼런스, 교환 프로그램 등 청년 기회를 모든 AI 어시스턴트가 검색할 수 있게 해주는 모델 컨텍스트 프로토콜(MCP) 서버입니다.
상태: 알파 (
v0.1.x). 어댑터가 성숙해짐에 따라 스키마, 도구 인터페이스 및 소스 목록이 변경될 수 있습니다. 프로덕션 환경에서는 마이너 버전을 고정하여 사용하세요.
타사 장학금 집계 사이트에 의존하는 학생들은 일반적으로 10개 이상의 탭을 열고, 수십 개의 관련 없는 게시물을 걸러내며, 마감일을 개인 스프레드시트에 복사해야 합니다. 하지만 어떤 집계 사이트도 신뢰할 수 있는 마감일 추적 기능을 제공하지 않아 지원 시기를 놓치기 일쑤입니다. Opportunity MCP는 이러한 워크플로우를 단일 대화형 쿼리로 통합합니다.
사용자: 파키스탄 시민이 지원할 수 있는, 마감일이 60일 이내인 유럽의 전액 장학금 석사 과정을 찾아줘.
Claude: (인덱싱된 소스에서 실시간으로 가져온 중복 제거된 구조화된 목록을 마감일 순으로 반환하며, 각 항목은 원본 기사로 연결됩니다.)
이 서버는 stdio를 통해 로컬에서 실행되며, CI를 통해 6시간마다 새로 고쳐지는 SQLite + FTS5 인덱스를 제공합니다. 또한 PyPI, 공식 MCP 레지스트리 및 Smithery를 통해 배포됩니다.
Related MCP server: bounty-mcp
채널 | 식별자 | 상태 |
PyPI |
| ✅ 라이브 |
MCP Registry |
| ✅ 게시됨 |
Smithery |
| ✅ 게시됨 |
GitHub | 진실의 원천 | |
GitHub Releases | 6시간마다 새로 고쳐지는 SQLite DB의 | 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을 다시 시작하세요. 아래 6가지 도구를 모델에서 사용할 수 있게 됩니다.
대부분의 클라이언트는 동일한 mcpServers 형태를 사용합니다. (pip install 후) command를 opportunity-mcp로 지정하거나 설치가 필요 없는 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이 서버는 6가지 도구를 제공합니다. 각 도구는 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 검증됨)를 생성하는 방법을 알고 있습니다.
쿼리 엔진은 사이트에 대해 아무것도 모르며, 정규화된 인덱스를 검색합니다.
새 소스를 추가하는 것은 일반적으로 50줄 정도의 풀 리퀘스트입니다. docs/ADAPTER_GUIDE.md를 참조하세요. 전체 아키텍처 근거는 docs/ARCHITECTURE.md에 있습니다.
사용자 추적 없음. 모든 쿼리는 로컬에서 처리되며, 주기적인 소스 사이트 새로 고침을 제외하고는 사용자의 컴퓨터에서 외부로 나가는 데이터가 없습니다.
모든 인덱싱된 데이터는 공개됨. 요약은 500자로 제한되며 모든 레코드는 원본 기사로 연결됩니다.
정중한 식별. HTTP User-Agent에 프로젝트 URL이 포함되어 있어 사이트 소유자가 직접 연락할 수 있습니다.
보수적인 새로 고침 주기. 소스는 사용자 쿼리 시점이 아닌 CI를 통해 최대 6시간마다 폴링됩니다.
요청 시 소스 제거. 협상 없이 24시간 이내에 처리됩니다.
robots.txt 준수. 모든 어댑터는 데이터를 가져오기 전에 robots.txt를 준수합니다.
2단계 — 국가, 수준 및 언어 인식 추출 (현재 AI 클라이언트에 위임됨).
3단계 — 첫 번째 HTML 어댑터(Youth Opportunities), 더 넓은 Tier-2/Tier-4 소스 커버리지.
4단계 — 원격 MCP 서버를 선호하는 클라이언트를 위한 호스팅된 Streamable-HTTP 엔드포인트.
5단계 — 저장된 프로필별 선택적 주간 요약.
add a source 라벨이 붙은 열린 이슈들은 좋은 첫 기여가 될 것입니다.
풀 리퀘스트를 환영합니다. 가장 빠른 기여 방법은 아직 인덱싱하지 않은 소스를 추가하는 것입니다. 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.
