Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@BRVM MCP Server show me the top gainers on BRVM today"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
The first MCP server for West Africa's regional stock exchange.
Connect any AI agent — Claude, ChatGPT, Cursor, Copilot, LangGraph — to live market data from the BRVM (Bourse Régionale des Valeurs Mobilières), serving 8 UEMOA member states across West Africa.
The BRVM lists ~46 companies across Bénin, Burkina Faso, Côte d'Ivoire, Guinée-Bissau, Mali, Niger, Sénégal, and Togo — with a combined market cap of ~$27.8B USD. Yet it has no public API. This server bridges that gap, making BRVM data accessible to the AI ecosystem via the Model Context Protocol.
December 18, 2026: First derivatives market in francophone West Africa (futures on indices and stocks)
2026–2027: ETF listings
2026: Agricultural commodities exchange (BMPA CI) — cashew, maize, cola nut
This server is built to grow alongside these developments.
Related MCP server: Alpha Vantage MCP Server
Tool | Description |
| Full trading session overview: volume, value, gainers/losers, indices |
| Current quote for a specific ticker (price, change, volume) |
| All BRVM indices: Composite, BRVM 30, Prestige, Principal, sectors |
| Top N gainers and losers of the day |
| Company details: name, country, sector, market cap |
| Search by name, country, or sector |
| All ~46 BRVM tickers with metadata |
URI | Description |
| BRVM exchange overview for context injection |
Prompt | Description |
| Structured analysis of a BRVM stock |
| Full daily market report template |
Python 3.11+
uv (recommended) or 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 8000Add to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"brvm": {
"command": "uv",
"args": ["run", "--directory", "/path/to/brvm-mcp-server", "brvm-mcp"]
}
}
}Restart Claude Desktop. You'll see the BRVM tools in the 🔨 menu.
npx @modelcontextprotocol/inspector uv run brvm-mcpdocker build -t brvm-mcp .
docker run -p 8000:8000 brvm-mcpOnce connected, you can ask Claude:
"What's the BRVM market doing today?" → Calls
get_market_summary(), returns full session data
"Show me Sonatel's stock price" → Calls
get_stock_price("SNTS")
"Which BRVM stocks are from Sénégal?" → Calls
search_stocks(country="Sénégal")
"Give me a full market report" → Uses the
market_reportprompt to orchestrate multiple tool calls
"Which stocks dropped the most today?" → Calls
get_top_movers(), focuses on losers
┌──────────────────┐ 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: Decorator-based MCP framework (official Python SDK)
httpx: Async HTTP client for scraping
BeautifulSoup4 + lxml: HTML parsing
diskcache: TTL-based disk caching (5min default, respectful of sources)
Pydantic: Structured data models
v0.2 — Historical price data (OHLCV bars)
v0.3 — BRVM official announcements / corporate actions feed
v0.4 — BMPA CI commodities data (when available)
v0.5 — Derivatives data (futures, options — post Dec 2026 launch)
v1.0 — OAuth + rate limiting for multi-user deployment
Register on MCP Registry
This server scrapes publicly available data. It implements:
Caching (5min TTL) to minimize requests
Polite User-Agent header identifying the project
No authentication bypass — only public data
For real-time FIX feeds, contact BRVM directly: brvm.org/real-time-data-feed
PRs welcome! Priority areas:
Additional data sources (eodhd.com, Rich Bourse)
Historical data support
Tests (pytest + VCR cassettes for scraper tests)
TypeScript port for Node.js MCP hosts
MIT
Built with ☕ in Mauritius by Dilane Fogué Kamga — Senior Software & AI Engineer, Financial Engineering MSc (WorldQuant University).
Bridging AI and African capital markets.
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.
Live multi-asset market data for AI agents with provenance, starter credits, x402, and examples.
Real-time data API for AI Agents: stocks, weather, forex, logistics, search, scrape, news, IP.
US stock market data for AI agents: SEC filings, financials, insider trades, 13F, options, macro.
Evidence-backed capital-change intelligence and sourced financial data for AI agents
