Первый MCP-сервер для региональной фондовой биржи Западной Африки.
Подключите любого ИИ-агента — Claude, ChatGPT, Cursor, Copilot, LangGraph — к актуальным рыночным данным BRVM (Bourse Régionale des Valeurs Mobilières), обслуживающей 8 государств-членов UEMOA в Западной Африке.
На бирже BRVM котируются около 46 компаний из Бенина, Буркина-Фасо, Кот-д'Ивуара, Гвинеи-Бисау, Мали, Нигера, Сенегала и Того с общей рыночной капитализацией около 27,8 млрд долларов США. Однако у нее нет публичного API. Этот сервер устраняет данный пробел, делая данные BRVM доступными для экосистемы ИИ через Model Context Protocol.
18 декабря 2026 г.: Первый рынок деривативов во франкоязычной Западной Африке (фьючерсы на индексы и акции)
2026–2027 гг.: Листинг ETF
2026 г.: Биржа сельскохозяйственных товаров (BMPA CI) — кешью, кукуруза, орехи кола
Этот сервер создан для развития вместе с данными изменениями.
Related MCP server: Alpha Vantage MCP Server
Инструмент | Описание |
| Обзор торговой сессии: объем, стоимость, лидеры роста/падения, индексы |
| Текущая котировка для конкретного тикера (цена, изменение, объем) |
| Все индексы BRVM: Composite, BRVM 30, Prestige, Principal, секторальные |
| Топ-N лидеров роста и падения за день |
| Информация о компании: название, страна, сектор, рыночная капитализация |
| Поиск по названию, стране или сектору |
| Все ~46 тикеров BRVM с метаданными |
URI | Описание |
| Обзор биржи BRVM для контекстного внедрения |
Промпт | Описание |
| Структурированный анализ акции BRVM |
| Шаблон полного ежедневного отчета по рынку |
Python 3.11+
uv (рекомендуется) или pip
# Clone
git clone https://github.com/dilanefk/brvm-mcp-server.git
cd brvm-mcp-server
# Install
uv sync
# Run (stdio — for Claude Desktop / Cursor)
uv run brvm-mcp
# Run (HTTP — for remote agents / web apps)
uv run brvm-mcp --transport streamable-http --port 8000Добавьте в конфигурацию Claude Desktop (~/Library/Application Support/Claude/claude_desktop_config.json на macOS):
{
"mcpServers": {
"brvm": {
"command": "uv",
"args": ["run", "--directory", "/path/to/brvm-mcp-server", "brvm-mcp"]
}
}
}Перезапустите Claude Desktop. Вы увидите инструменты BRVM в меню 🔨.
npx @modelcontextprotocol/inspector uv run brvm-mcpdocker build -t brvm-mcp .
docker run -p 8000:8000 brvm-mcpПосле подключения вы можете спросить Claude:
"Что происходит на рынке BRVM сегодня?" → Вызывает
get_market_summary(), возвращает полные данные сессии
"Покажи мне цену акций Sonatel" → Вызывает
get_stock_price("SNTS")
"Какие акции BRVM из Сенегала?" → Вызывает
search_stocks(country="Сенегал")
"Составь полный отчет по рынку" → Использует промпт
market_reportдля организации нескольких вызовов инструментов
"Какие акции упали больше всего сегодня?" → Вызывает
get_top_movers(), фокусируясь на лидерах падения
┌──────────────────┐ MCP (stdio/HTTP) ┌──────────────────┐
│ AI Agent │◄────────────────────────►│ BRVM MCP Server │
│ (Claude, GPT, │ │ │
│ Cursor, etc.) │ │ FastMCP + Tools │
└──────────────────┘ │ + Cache Layer │
└────────┬─────────┘
│ httpx
┌────────▼─────────┐
│ Data Sources │
│ • afx.kwayisi │
│ • brvm.org │
│ • Rich Bourse │
└──────────────────┘FastMCP: Фреймворк MCP на основе декораторов (официальный SDK для Python)
httpx: Асинхронный HTTP-клиент для парсинга
BeautifulSoup4 + lxml: Парсинг HTML
diskcache: Дисковое кэширование с TTL (по умолчанию 5 минут, с уважением к источникам)
Pydantic: Структурированные модели данных
[ ] v0.2 — Исторические данные о ценах (бары OHLCV)
[ ] v0.3 — Официальные объявления BRVM / лента корпоративных действий
[ ] v0.4 — Данные по товарам BMPA CI (по мере доступности)
[ ] v0.5 — Данные по деривативам (фьючерсы, опционы — после запуска в декабре 2026 г.)
[ ] v1.0 — OAuth + ограничение частоты запросов для многопользовательского развертывания
[ ] Регистрация в реестре MCP
Этот сервер собирает общедоступные данные. Он реализует:
Кэширование (TTL 5 минут) для минимизации запросов
Вежливый заголовок User-Agent, идентифицирующий проект
Отсутствие обхода аутентификации — только публичные данные
Для получения потоков FIX в реальном времени свяжитесь с BRVM напрямую: brvm.org/real-time-data-feed
Приветствуются PR! Приоритетные области:
Дополнительные источники данных (eodhd.com, Rich Bourse)
Поддержка исторических данных
Тесты (pytest + VCR cassettes для тестов парсера)
Портирование на TypeScript для хостов MCP на Node.js
MIT
Создано с ☕ на Маврикии Диланом Фоге Камга — старшим инженером по программному обеспечению и ИИ, магистром финансовой инженерии (WorldQuant University).
Соединяя ИИ и африканские рынки капитала.
Get detailed information about a BRVM-listed company.
Args: ticker: The BRVM ticker symbol.
Returns company name, country, sector, and market cap.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must convey all behavioral traits. It describes a read operation but fails to mention any restrictions, side effects, or rate limits. The description is minimal.
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?
Extremely concise: two sentences plus a bullet list. Every word carries weight. No repetition or fluff.
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 output schema exists, the description need not detail return structure. It lists core fields (name, country, sector, market cap) adequately. Lacks error handling info but acceptable for a simple lookup.
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 0% description coverage; the description adds 'The BRVM ticker symbol' for the ticker parameter, which provides exchange context. However, it lacks format examples or constraints like case sensitivity.
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?
Clearly states the verb 'Get' and the resource 'detailed information about a BRVM-listed company'. The return fields help clarify scope. However, it does not explicitly differentiate from siblings like get_stock_price or get_market_summary, leaving some ambiguity.
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 on when to use this tool versus alternatives like search_stocks or get_stock_price. Lacks any 'when not to use' or context about prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current values for all BRVM indices: BRVM Composite (BRVM-CI), BRVM 30, BRVM Prestige, BRVM Principal, and sector indices.
Returns a JSON array of index objects with value, change, and YTD performance.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adequately discloses the return format (JSON array of index objects with specific fields) and implies a read-only, non-destructive operation, but it does not mention rate limits or authentication needs.
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 concise with two sentences: the first clearly states the action and scope, the second provides output details. No unnecessary words or redundancy.
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 zero parameters and no annotations, the description fully covers what the tool does and what it returns, being complete for a simple data retrieval tool.
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?
No parameters exist, so schema coverage is 100%. The description adds value by listing the specific indices returned, providing context beyond the empty 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 tool retrieves current values for all BRVM indices, listing specific index names, which differentiates it from sibling tools that focus on individual stocks or market summaries.
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 for index data but does not explicitly state when to use this tool versus alternatives like get_stock_price or get_market_summary, lacking exclusions or context for choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get today's BRVM market summary including total volume, value traded, number of gainers/losers, and all index values.
Returns a JSON object with the full trading session overview.
| 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, so description carries full burden. It states returns a JSON object with trading session overview, but no side effects, auth needs, or rate limits are mentioned. Adequately discloses return content.
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?
Two tightly written sentences with no fluff. Front-loaded with key information and precise.
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?
Output schema exists, so description needn't detail return values. Mentions key fields. For a parameterless market summary, description is complete given schema presence.
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?
No parameters in schema (100% coverage), so description naturally adds no extra parameter info. Baseline score of 4 applies as no compensation needed.
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?
Description clearly states it gets today's BRVM market summary with specific data points (volume, value, gainers/losers, index values), distinguishing it from sibling tools like get_company_info (company-specific) and get_indices (just indices).
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?
Implies use for a market overview, but lacks explicit when-to-use vs. alternatives. No guidance on when not to use or exclusions, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current price and trading data for a specific BRVM-listed stock.
Args: ticker: The BRVM ticker symbol (e.g., SNTS for Sonatel, SGBC for Société Générale CI, ETIT for Ecobank Transnational, ORAC for Orange CI, ONTBF for Onatel).
Returns a JSON object with price, change, volume, and company details.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes return object fields but lacks details on data freshness, error handling, or required permissions. Adequate but not comprehensive.
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?
Two clear sentences plus a list of examples. No redundant information, though could be even more terse.
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?
Covers purpose, required parameter, and output structure. Minor omissions like handling of invalid tickers or data source are not critical for this simple tool.
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?
Schema coverage is 0%, but description adds meaningful examples and context for the ticker parameter, explaining it's a BRVM symbol and listing common values.
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?
Clearly states it gets current price and trading data for a specific BRVM-listed stock. Verbs and resource are specific, and it distinguishes from siblings like get_company_info or get_market_summary.
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 explicit comparison to sibling tools or guidance on when to use this tool over alternatives. Usage is implied but not directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get today's top gaining and losing stocks on the BRVM.
Args: n: Number of stocks to return per category (default 5, max 10).
Returns a JSON object with 'gainers' and 'losers' arrays.
| Name | Required | Description | Default |
|---|---|---|---|
| n | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses basic behavior: returns JSON with 'gainers' and 'losers' arrays. However, it omits potential edge cases (e.g., market closed, no movers) and does not explicitly state it is read-only or require authentication.
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?
Three concise sentences: one for purpose, one for parameter, one for return format. No extraneous information; every sentence 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?
The description covers purpose, parameter, and return format. With an output schema present, return details are sufficient. However, it lacks a definition of 'top' (e.g., percentage change or absolute change), which would improve completeness for a first-time user.
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?
Input schema has 0% description coverage, but the description clearly explains parameter 'n': its purpose ('Number of stocks to return per category'), default (5), and maximum (10). This fully compensates for the schema's lack of descriptions.
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?
Description clearly states the tool retrieves 'today's top gaining and losing stocks on the BRVM,' specifying verb, resource, and scope. It distinguishes from siblings like 'get_stock_price' (single stock) and 'get_market_summary' (broader market data).
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?
Usage context is implied (for daily top movers) but no explicit guidance on when to use this tool versus alternatives like 'get_stock_price' or 'search_stocks'. No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all BRVM ticker symbols with their company names, countries, and sectors.
Useful for discovering available tickers before calling get_stock_price. Returns a JSON array of all ~46 listed companies.
| 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, so description is the sole source. States returns a JSON array with approximate size (~46), implying read-only behavior. Could mention it's non-destructive, but adequate.
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?
Three concise sentences: purpose, usage hint, return format. No wasted words, front-loaded with key info.
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?
Covers purpose, usage, and return format. Output schema exists, so return details are not needed. Lacks info on ordering or filtering, but for a simple list tool, it's largely 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?
No parameters (0 params), so baseline is 4. Description adds no parameter info, which is acceptable as schema is empty and coverage is 100%.
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?
Clearly states verb (list), resource (BRVM ticker symbols), and scope (company names, countries, sectors). Distinguishes from siblings like get_stock_price by focusing on discovery.
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?
Explicitly suggests using before get_stock_price, providing a clear use case. Lacks explicit 'when not to use' or alternatives beyond that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search BRVM-listed stocks by name, country, or sector.
Args: query: Free-text search on company name or ticker (e.g., 'orange', 'ecobank', 'SNTS'). country: Filter by UEMOA country (e.g., 'Sénégal', 'Côte d'Ivoire', 'Burkina Faso', 'Bénin', 'Togo', 'Mali', 'Niger', 'Guinée-Bissau'). sector: Filter by sector (e.g., 'Services Financiers', 'Agriculture', 'Services Publics', 'Industrie', 'Distribution', 'Transport').
Returns a JSON array of matching companies. At least one filter must be provided.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| country | No | ||
| sector | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the burden. It mentions the return type (JSON array) and the constraint, but does not disclose safety (e.g., read-only), idempotency, or potential rate limits. The behavior is implied as safe, but not 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 front-loaded with the purpose, followed by structured argument details. It is slightly verbose due to listing example values, but remains clear and functional without wasted sentences.
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 absence of annotations and presence of an output schema, the description covers the core functionality, parameters, and return type. It also notes the constraint. Missing details like error handling or pagination but acceptable for a search tool.
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?
Schema description coverage is 0%, yet the description provides rich semantic context for all three parameters: query as free-text on name/ticker, country with list of UEMOA countries, and sector with specific sector names. This fully compensates for the missing schema descriptions.
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 specifies the tool searches BRVM-listed stocks by name, country, or sector, using precise verbs and distinct filtering dimensions. It distinguishes itself from siblings like get_company_info and list_tickers, which target specific data retrieval rather than search.
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 explicitly states 'At least one filter must be provided,' setting a clear constraint. However, it lacks explicit guidance on when to prefer this tool over siblings, e.g., searching by criteria vs. fetching details for a known ticker.
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.0get_company_infoget_indicesget_market_summaryget_stock_priceget_top_moverslist_tickerssearch_stocksScored across 7 tools
Each tool targets a distinct function: company info, price data, indices, market summary, movers, ticker list, and search. Minimal overlap; descriptions clarify boundaries.
All tool names follow a clear verb_noun pattern in snake_case (e.g., get_company_info, list_tickers, search_stocks), providing predictability for agents.
Seven tools cover the essential operations for a stock exchange information server without redundancy or unnecessary complexity, fitting well within the ideal 3-15 range.
The set covers core information retrieval needs (price, company details, indices, search, movers). Minor gaps like historical data or dividend info exist but do not critically impair typical workflows.
A Model Context Protocol server exposing real-time and historical Colombo Stock Exchange (CSE) data to AI agents and LLM applications. Provides quotes and OHLCV price history, full financial statements (income, balance sheet, cash flow), pre-computed technicals (moving averages, RS ratings, volume signals), macroeconomic indicators, corporate actions, and rule-based screening across CSE stocks and sector indices, everything needed to build CSE-aware trading assistants, research tools, and market-analysis agents. This is the official MCP server of www.ceyloncharts.com
Live crypto + IDX stock market intelligence for AI agents — 19 tools, no API key.
Real-time data API for AI Agents: stocks, weather, forex, logistics, search, scrape, news, IP.
Financial data MCP server for Claude, ChatGPT, Cursor and Codex. Real-time stock quotes, financial statements, options flow, SEC filings, insider trades, 13F holdings, macro data and market news from gloom.sh, the open-source Bloomberg Terminal alternative.
