Der erste MCP-Server für die Regionalbörse Westafrikas.
Verbinden Sie jeden KI-Agenten — Claude, ChatGPT, Cursor, Copilot, LangGraph — mit Live-Marktdaten der BRVM (Bourse Régionale des Valeurs Mobilières), die 8 UEMOA-Mitgliedsstaaten in Westafrika bedient.
Die BRVM listet ca. 46 Unternehmen in Benin, Burkina Faso, Côte d'Ivoire, Guinea-Bissau, Mali, Niger, Senegal und Togo — mit einer kombinierten Marktkapitalisierung von ca. 27,8 Mrd. USD. Dennoch gibt es keine öffentliche API. Dieser Server schließt diese Lücke und macht BRVM-Daten für das KI-Ökosystem über das Model Context Protocol zugänglich.
18. Dezember 2026: Erster Derivatemarkt im frankophonen Westafrika (Futures auf Indizes und Aktien)
2026–2027: ETF-Listings
2026: Landwirtschaftliche Warenbörse (BMPA CI) — Cashew, Mais, Kolanuss
Dieser Server ist so konzipiert, dass er mit diesen Entwicklungen wächst.
Related MCP server: Alpha Vantage MCP Server
Tool | Beschreibung |
| Übersicht der gesamten Handelssitzung: Volumen, Wert, Gewinner/Verlierer, Indizes |
| Aktueller Kurs für ein bestimmtes Tickersymbol (Preis, Veränderung, Volumen) |
| Alle BRVM-Indizes: Composite, BRVM 30, Prestige, Principal, Sektoren |
| Top N Gewinner und Verlierer des Tages |
| Unternehmensdetails: Name, Land, Sektor, Marktkapitalisierung |
| Suche nach Name, Land oder Sektor |
| Alle ca. 46 BRVM-Ticker mit Metadaten |
URI | Beschreibung |
| BRVM-Börsenübersicht zur Kontext-Injection |
Prompt | Beschreibung |
| Strukturierte Analyse einer BRVM-Aktie |
| Vorlage für einen vollständigen täglichen Marktbericht |
Python 3.11+
uv (empfohlen) oder 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 8000Fügen Sie dies zu Ihrer Claude Desktop-Konfiguration hinzu (~/Library/Application Support/Claude/claude_desktop_config.json unter macOS):
{
"mcpServers": {
"brvm": {
"command": "uv",
"args": ["run", "--directory", "/path/to/brvm-mcp-server", "brvm-mcp"]
}
}
}Starten Sie Claude Desktop neu. Sie werden die BRVM-Tools im 🔨-Menü sehen.
npx @modelcontextprotocol/inspector uv run brvm-mcpdocker build -t brvm-mcp .
docker run -p 8000:8000 brvm-mcpSobald die Verbindung hergestellt ist, können Sie Claude fragen:
"Wie läuft der BRVM-Markt heute?" → Ruft
get_market_summary()auf, liefert vollständige Sitzungsdaten
"Zeig mir den Aktienkurs von Sonatel" → Ruft
get_stock_price("SNTS")auf
"Welche BRVM-Aktien kommen aus dem Senegal?" → Ruft
search_stocks(country="Sénégal")auf
"Gib mir einen vollständigen Marktbericht" → Verwendet den
market_report-Prompt, um mehrere Tool-Aufrufe zu koordinieren
"Welche Aktien sind heute am stärksten gefallen?" → Ruft
get_top_movers()auf, fokussiert auf Verlierer
┌──────────────────┐ 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: Dekorator-basiertes MCP-Framework (offizielles Python SDK)
httpx: Asynchroner HTTP-Client für das Scraping
BeautifulSoup4 + lxml: HTML-Parsing
diskcache: TTL-basiertes Disk-Caching (5 Min. Standard, respektiert die Quellen)
Pydantic: Strukturierte Datenmodelle
[ ] v0.2 — Historische Preisdaten (OHLCV-Balken)
[ ] v0.3 — Offizielle BRVM-Ankündigungen / Feed zu Unternehmensmaßnahmen
[ ] v0.4 — BMPA CI Warenmarktdaten (sobald verfügbar)
[ ] v0.5 — Derivatdaten (Futures, Optionen — nach dem Start im Dez. 2026)
[ ] v1.0 — OAuth + Ratenbegrenzung für Multi-User-Bereitstellungen
[ ] Registrierung im MCP Registry
Dieser Server scrapt öffentlich verfügbare Daten. Er implementiert:
Caching (5 Min. TTL), um Anfragen zu minimieren
Höflichen User-Agent-Header, der das Projekt identifiziert
Keine Umgehung der Authentifizierung — nur öffentliche Daten
Für Echtzeit-FIX-Feeds kontaktieren Sie die BRVM direkt: brvm.org/real-time-data-feed
PRs sind willkommen! Prioritätsbereiche:
Zusätzliche Datenquellen (eodhd.com, Rich Bourse)
Unterstützung für historische Daten
Tests (pytest + VCR-Kassetten für Scraper-Tests)
TypeScript-Port für Node.js MCP-Hosts
MIT
Mit ☕ auf Mauritius entwickelt von Dilane Fogué Kamga — Senior Software & AI Engineer, Financial Engineering MSc (WorldQuant University).
Brückenschlag zwischen KI und afrikanischen Kapitalmärkten.
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.
