西アフリカ地域証券取引所向けの初のMCPサーバー。
Claude、ChatGPT、Cursor、Copilot、LangGraphなどのあらゆるAIエージェントを、西アフリカのUEMOA加盟8カ国にサービスを提供するBRVM（Bourse Régionale des Valeurs Mobilières：地域証券取引所）のライブ市場データに接続します。
BRVMは、ベナン、ブルキナファソ、コートジボワール、ギニアビサウ、マリ、ニジェール、セネガル、トーゴの約46社を上場しており、合計時価総額は約278億米ドルに達します。しかし、公開APIが存在しません。このサーバーはそのギャップを埋め、Model Context Protocolを通じてAIエコシステムがBRVMデータにアクセスできるようにします。
2026年12月18日: フランス語圏西アフリカ初のデリバティブ市場（指数および株式の先物）
2026年〜2027年: ETF上場
2026年: 農産物取引所（BMPA CI）— カシューナッツ、トウモロコシ、コーラナッツ
このサーバーは、これらの発展に合わせて成長するように構築されています。
Related MCP server: Alpha Vantage MCP Server
ツール | 説明 |
| 取引セッションの全体概要：出来高、売買代金、値上がり/値下がり銘柄、指数 |
| 特定のティッカーの現在の相場（価格、変動率、出来高） |
| すべてのBRVM指数：総合指数、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 8000Claude Desktopの設定（macOSの場合は ~/Library/Application Support/Claude/claude_desktop_config.json）に追加します：
{
"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="Sénégal")を呼び出します
"市場レポートを詳しく作成して" →
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フレームワーク（公式Python SDK）
httpx: スクレイピング用の非同期HTTPクライアント
BeautifulSoup4 + lxml: HTML解析
diskcache: TTLベースのディスクキャッシュ（デフォルト5分、ソースに配慮）
Pydantic: 構造化データモデル
[ ] v0.2 — 過去の価格データ（OHLCVバー）
[ ] v0.3 — BRVM公式発表 / コーポレートアクションフィード
[ ] v0.4 — BMPA CI商品データ（利用可能になり次第）
[ ] v0.5 — デリバティブデータ（先物、オプション — 2026年12月以降）
[ ] v1.0 — マルチユーザーデプロイ用のOAuth + レート制限
[ ] MCP Registryへの登録
このサーバーは公開されているデータをスクレイピングします。以下を実装しています：
キャッシュ（5分のTTL）によるリクエストの最小化
プロジェクトを識別する丁寧なUser-Agentヘッダー
認証バイパスなし — 公開データのみ
リアルタイムのFIXフィードについては、BRVMに直接お問い合わせください：brvm.org/real-time-data-feed
プルリクエストを歓迎します！優先分野：
追加のデータソース（eodhd.com、Rich Bourse）
過去データサポート
テスト（pytest + スクレイパーテスト用のVCRカセット）
Node.js MCPホスト向けのTypeScript移植
MIT
モーリシャスにて☕で構築。開発者：Dilane Fogué Kamga — シニアソフトウェア＆AIエンジニア、金融工学修士（WorldQuant University）。
AIとアフリカの資本市場を繋ぐ。
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.
