El primer servidor MCP para la bolsa de valores regional de África Occidental.
Conecte cualquier agente de IA — Claude, ChatGPT, Cursor, Copilot, LangGraph — a datos de mercado en tiempo real de la BRVM (Bourse Régionale des Valeurs Mobilières), que presta servicio a 8 estados miembros de la UEMOA en África Occidental.
La BRVM cotiza unas 46 empresas en Benín, Burkina Faso, Costa de Marfil, Guinea-Bisáu, Malí, Níger, Senegal y Togo, con una capitalización de mercado combinada de unos 27.800 millones de dólares estadounidenses. Sin embargo, no tiene una API pública. Este servidor cierra esa brecha, haciendo que los datos de la BRVM sean accesibles para el ecosistema de IA a través del Protocolo de Contexto de Modelo.
18 de diciembre de 2026: Primer mercado de derivados en el África occidental francófona (futuros sobre índices y acciones)
2026–2027: Listados de ETF
2026: Bolsa de productos agrícolas (BMPA CI) — anacardo, maíz, nuez de cola
Este servidor está diseñado para crecer junto con estos desarrollos.
Related MCP server: Alpha Vantage MCP Server
Herramienta | Descripción |
| Resumen completo de la sesión de negociación: volumen, valor, ganadores/perdedores, índices |
| Cotización actual de un ticker específico (precio, cambio, volumen) |
| Todos los índices de la BRVM: Compuesto, BRVM 30, Prestige, Principal, sectores |
| Los N principales ganadores y perdedores del día |
| Detalles de la empresa: nombre, país, sector, capitalización de mercado |
| Búsqueda por nombre, país o sector |
| Todos los ~46 tickers de la BRVM con metadatos |
URI | Descripción |
| Resumen de la bolsa BRVM para la inyección de contexto |
Prompt | Descripción |
| Análisis estructurado de una acción de la BRVM |
| Plantilla de informe de mercado diario completo |
Python 3.11+
uv (recomendado) o 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 8000Agréguelo a su configuración de Claude Desktop (~/Library/Application Support/Claude/claude_desktop_config.json en macOS):
{
"mcpServers": {
"brvm": {
"command": "uv",
"args": ["run", "--directory", "/path/to/brvm-mcp-server", "brvm-mcp"]
}
}
}Reinicie Claude Desktop. Verá las herramientas de la BRVM en el menú 🔨.
npx @modelcontextprotocol/inspector uv run brvm-mcpdocker build -t brvm-mcp .
docker run -p 8000:8000 brvm-mcpUna vez conectado, puede preguntarle a Claude:
"¿Qué está haciendo el mercado de la BRVM hoy?" → Llama a
get_market_summary(), devuelve los datos completos de la sesión
"Muéstrame el precio de las acciones de Sonatel" → Llama a
get_stock_price("SNTS")
"¿Qué acciones de la BRVM son de Senegal?" → Llama a
search_stocks(country="Sénégal")
"Dame un informe de mercado completo" → Utiliza el prompt
market_reportpara orquestar múltiples llamadas a herramientas
"¿Qué acciones cayeron más hoy?" → Llama a
get_top_movers(), se centra en los perdedores
┌──────────────────┐ 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: Marco de trabajo MCP basado en decoradores (SDK oficial de Python)
httpx: Cliente HTTP asíncrono para scraping
BeautifulSoup4 + lxml: Análisis de HTML
diskcache: Caché de disco basada en TTL (5 min por defecto, respetuoso con las fuentes)
Pydantic: Modelos de datos estructurados
[ ] v0.2 — Datos históricos de precios (barras OHLCV)
[ ] v0.3 — Feed de anuncios oficiales de la BRVM / acciones corporativas
[ ] v0.4 — Datos de productos básicos de BMPA CI (cuando estén disponibles)
[ ] v0.5 — Datos de derivados (futuros, opciones — tras el lanzamiento de diciembre de 2026)
[ ] v1.0 — OAuth + limitación de tasa para despliegue multiusuario
[ ] Registrarse en el Registro MCP
Este servidor extrae datos disponibles públicamente. Implementa:
Caché (TTL de 5 min) para minimizar las solicitudes
Cabecera User-Agent educada que identifica el proyecto
Sin omisión de autenticación — solo datos públicos
Para feeds FIX en tiempo real, contacte directamente con la BRVM: brvm.org/real-time-data-feed
¡Las PR son bienvenidas! Áreas prioritarias:
Fuentes de datos adicionales (eodhd.com, Rich Bourse)
Soporte de datos históricos
Pruebas (pytest + casetes VCR para pruebas de scraper)
Puerto TypeScript para hosts MCP de Node.js
MIT
Construido con ☕ en Mauricio por Dilane Fogué Kamga — Ingeniero Senior de Software e IA, Máster en Ingeniería Financiera (WorldQuant University).
Uniendo la IA y los mercados de capitales africanos.
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.
