Skip to main content
Glama
florinel-chis

bvb-mcp

by florinel-chis
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

bvb-mcp

Read-only MCP server for the Bucharest Stock Exchange (Bursa de Valori București, BVB). It exposes BVB's own public backend — the TradingView-UDF datafeed at wapi.bvb.ro and the market-list pages at www.bvb.ro — as MCP tools: instrument universe, symbol search and metadata, and OHLCV candles.

No account, no API key, no token: the BVB backend is public and unauthenticated. Every tool is read-only; there is nothing to trade through here.

Features

  • OHLCV candles for any BVB ticker or index (get_candles), with a clean resolution parameter that hides the datafeed's 1D-not-D quirk.

  • Full instrument universe scraped from the exchange's market-list pages (list_instruments) — ticker + ISIN + name — plus the index universe (list_indices).

  • Datafeed symbol search (search_symbol) and per-symbol metadata (get_symbol_info), with diagnostics (server_time, datafeed_config).

  • Browser-like User-Agent and Referer: https://www.bvb.ro/ on every request (defensive; no cookies, no token).

  • One automatic retry on HTTP 429, honouring Retry-After (capped at 30s).

  • stdio transport by default, HTTP (/mcp) on request.

Related MCP server: tokenbel/financial-data

Tools

All tools are read-only (there are no write tools):

Tool

Description

list_instruments

List a market's instrument universe (ticker + ISIN + name) by scraping the BVB market-list page. Markets: shares, bonds, fund-units (ETFs), warrants, certificates (structured)

list_indices

List the BVB index universe (BET, BET-TR, BET-FI, ROTX, …)

search_symbol

Datafeed symbol search by ticker/name (server-capped at ~30 results)

get_symbol_info

Resolve a ticker to its metadata: name, type, session, timezone, currency, sector/industry

get_candles

OHLCV candles for a ticker/index at minute/daily/weekly/monthly resolution

get_fundamentals

Company details + valuation snapshot scraped from the detail page: identity, Indicatori bursieri (market cap, P/E, P/BV, EPS, div yield, dividend), issue info, and ownership structure

financial_summary

One-call bundle for a fundamental ("Buffett-style") analysis: get_fundamentals + a price summary (last close, 52-week range, 1y/5y change). Returns data, not a verdict

server_time

Datafeed server time (reachability check)

datafeed_config

Datafeed configuration: instrument-type codes and supported resolutions

Notes on the data surface

  • Search is capped. search_symbol mirrors the datafeed's own search, which returns roughly 30 results for broad queries. Use list_instruments (or list_indices) to enumerate the full universe.

  • The 1D quirk. The datafeed advertises a bare D for daily bars but the history endpoint only accepts 1D (bare D returns HTTP 500). get_candles takes a friendly resolution (1, 5, 15, 30, 60, 1D, 1W, 1M; D/W/M are accepted too) and sends the correct code.

  • Index metadata is partial. list_indices always returns every index's symbol, but name/isin are populated only for the indices BVB renders a server-side profile card for; the rest load via client-side tabs and come back as null.

  • Rights / structured. BVB publishes no standalone "rights" market page, and "structured products" (datafeed type T) are split across the warrants and certificates pages — structured is accepted as an alias for certificates.

  • No multi-year statements. get_fundamentals / financial_summary expose BVB's current snapshot (valuation ratios, dividend, ownership) — BVB does not publish structured multi-year income/balance/cash-flow statements, so a full 10-year ROE/margin/FCF track record is not available. Pair with get_candles for the price trend; the client (LLM) does the analysis.

Configuration

All configuration is via environment variables, and all of it is optional — the BVB backend needs no credentials.

Variable

Default

Purpose

BVB_DATAFEED_URL

https://wapi.bvb.ro

Datafeed base URL

BVB_WEB_URL

https://www.bvb.ro

Market-list site base URL

BVB_MCP_USER_AGENT

a Chrome-like UA

User-Agent sent on every request

BVB_LANG

ro

Language for the datafeed config endpoint

Getting started

Run straight from the repository with uv:

uvx --from git+https://github.com/florinel-chis/bvb-mcp bvb-mcp

The server speaks stdio by default; add --transport http --port 8000 to serve MCP over HTTP at /mcp instead. HTTP binds 127.0.0.1 by default, and a non-loopback --host is refused unless --allow-remote is also passed — read the Safety section before using that flag.

MCP client configuration

Add the server to your MCP client's configuration (stdio, via uvx):

{
  "mcpServers": {
    "bvb": {
      "command": "uvx",
      "args": ["--from", "git+https://github.com/florinel-chis/bvb-mcp", "bvb-mcp"]
    }
  }
}

Or run the Docker image (build it first, see below):

{
  "mcpServers": {
    "bvb": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "bvb-mcp"]
    }
  }
}

Docker

A small (~200 MB) multi-stage image that works both ways an MCP client might use it — spawned per call over stdio, or as a long-running HTTP server. Both paths are verified against BVB's live backend. The container only needs outbound network to reach wapi.bvb.ro / www.bvb.ro; no credentials or volumes.

Build:

docker build -t bvb-mcp .

stdio — what an MCP client spawns (use bvb-mcp as the image name in the docker config above):

docker run -i --rm bvb-mcp

HTTP — a shared, long-running server at http://127.0.0.1:8000/mcp/:

docker run --rm -p 127.0.0.1:8000:8000 bvb-mcp \
  --transport http --host 0.0.0.0 --port 8000 --allow-remote

--host 0.0.0.0 binds inside the container so the port mapping works — which is why --allow-remote is needed; the 127.0.0.1: prefix on -p keeps the endpoint reachable from this machine only (it is unauthenticated — see Safety). If host port 8000 is taken, map another, e.g. -p 127.0.0.1:8010:8000.

Share without a registry — hand the image to someone as a file they docker load, no Docker Hub / GHCR needed:

docker save bvb-mcp:latest | gzip > bvb-mcp.tar.gz   # you: export
docker load < bvb-mcp.tar.gz                          # them: image is now local

Safety

  • The HTTP transport has no authentication: anyone who can reach the /mcp endpoint can call every tool. Keep it bound to 127.0.0.1 (the CLI default; with Docker, publish as -p 127.0.0.1:8000:8000) or put it behind an authenticating reverse proxy. Never expose it directly on a public network.

  • All tools are read-only — this server cannot place orders or move money.

  • Use at your own risk. Nothing here is investment advice.

Data & terms

This server ships code, not data. It fetches from BVB's own public backend at request time and returns whatever BVB serves. Redistributing or otherwise using BVB price data is subject to BVB's terms and any applicable market-data licensing, and is your responsibility as the operator — the software makes no representation about your right to store, redistribute, or trade on the data it relays.

Development

uv sync
uv run pytest -q
uv run ruff check .

Tests are fully offline: HTTP is stubbed with respx against captured BVB response fixtures in tests/fixtures/.

License

MIT

Available Tools

9 tools
datafeed_configA
Read-only

Get the datafeed configuration: instrument types and resolutions.

Returns symbols_types (each {name, value}, where value is the one-letter type code: S=Actiuni/shares, B=Obligatiuni/bonds, R=Drepturi/rights, U=Unitati de fond/fund units, T=Structurate, F= Futures, I=Indici/indices) and supported_resolutions (the datafeed's advertised resolution vocabulary).

Note: the config advertises a bare "D" for daily, but the history endpoint requires "1D" — get_candles handles that translation, so pass its friendly resolution values rather than these raw codes.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses full return structure and a known inconsistency (D vs 1D). No contradictions with readOnlyHint annotation. Adds context beyond annotations by explaining the resolution issue.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose. Some detail in listing types could be condensed, but overall efficient and informative. The note is essential and well-placed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no parameters and an output schema, the description fully explains the return values and a critical caveat. No gaps remain for agent understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters; schema coverage 100%. Baseline 4 per guidelines. Description adds no parameter info, but none needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Get the datafeed configuration: instrument types and resolutions.' Specifies exact return fields and their meanings. Distinguishes from sibling tool get_candles by noting resolution translation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit note about discrepancy between 'D' and '1D' and advises to use get_candles for friendly resolution values. Guides agent on when to use this tool (for config) and when to avoid raw codes.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

financial_summaryA
Read-only

One-call bundle for a fundamental ("Buffett-style") analysis.

Combines get_fundamentals with a price summary (last close, 52-week high/low, 1-year and ~5-year percent change) derived from daily history, so a caller has every input in a single call. It returns data, not a verdict — the analysis/judgement is left to the caller.

Caveat (see note): the inputs are a current valuation snapshot + dividend + ownership + price trend. BVB publishes no multi-year financial statements, so a full 10-year ROE/margin/FCF track record is not available from this source.

ParametersJSON Schema
NameRequiredDescriptionDefault
tickerYesBVB ticker to summarise, e.g. "TLV" or "ATB".

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint annotation, the description adds that the tool returns data, not a verdict, and highlights a data limitation (no multi-year financial statements). This gives useful behavioral context beyond read-only confirmation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: three focused sentences that front-load the purpose and include a caveat. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (not shown), the description does not need to detail return fields. It explains the components (fundamentals + price summary) and the caveat, making it complete for a read-only bundle tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema already describes the ticker parameter with examples. The description adds no additional semantic meaning beyond what the schema provides, so baseline score is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it is a 'one-call bundle for a fundamental analysis' that combines get_fundamentals with a price summary, distinguishing it from sibling tools like get_fundamentals or get_candles. The verb is implicit but the resource is well-defined.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context as a bundle for convenience and notes a caveat about missing multi-year data. It implies use when both fundamentals and price trends are needed in one call, but does not explicitly state when not to use or name alternatives beyond the sibling list.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_candlesA
Read-only

Fetch OHLCV candles for a BVB ticker.

Returns bars oldest-first, each {time, open, high, low, close, volume} where time is an ISO 8601 UTC timestamp and volume is an integer. An empty list means the datafeed had no data for the window (not an error).

The window is resolved as: to defaults to now; countback (when given) fixes the number of bars, otherwise it is derived from the from_/to span (capped at 5000) or defaults to 300; from_ defaults to to minus countback bars. Daily bars reach back to the 1990s; intraday resolutions only cover a recent window.

ParametersJSON Schema
NameRequiredDescriptionDefault
toNoWindow end, unix seconds (UTC). Defaults to now.
from_NoWindow start, unix seconds (UTC). Derived from countback if omitted.
tickerYesBVB ticker, e.g. "TLV", "SNP", or an index like "BET".
adjustedNoSplit/dividend-adjusted prices (True) or raw (False).
currencyNoQuote currency code, e.g. 'RON'.RON
countbackNoNumber of bars ending at 'to'. Overrides the from/to span when set; derived from the span (or defaults to 300) otherwise.
resolutionNoBar size (case-insensitive). Minutes: 1, 5, 15, 30, 60. Daily: 1D (or D). Weekly: 1W. Monthly: 1M.1D

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true. The description adds value by detailing return format (oldest-first), empty list behavior, and window resolution logic. It does not contradict annotations and provides context beyond what annotations convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is reasonably concise, with a clear structure that separates return format from window resolution logic. It could be slightly more structured (e.g., bullet points), but it remains focused and front-loaded with the purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 7 parameters, high schema coverage, and an output schema, the description covers essential behaviors including return format, edge cases (empty list), and window resolution. It is complete for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema descriptions cover all 7 parameters at 100%. The description adds significant meaning by explaining the window resolution algorithm, default behaviors for to, countback, from_, and how they interact, which goes beyond the schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it fetches OHLCV candles for a BVB ticker, specifying the return format and behavior when no data. It distinguishes itself from sibling tools like get_symbol_info or list_instruments by focusing on candlestick data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the window resolution logic in detail, including defaults and how parameters interact. However, it does not explicitly state when to use this tool over alternatives like get_fundamentals or search_symbol, so it misses explicit exclusions or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_fundamentalsA
Read-only

Company details + valuation snapshot scraped from the detail page.

Returns identity (ticker, name, isin, type, segment, category, status), the "Indicatori bursieri" valuation ratios (market_cap, per, pbv, eps, div_yield, dividend + dividend_year), issue info (shares_outstanding, nominal_value, share_capital, first_trade_date), and the ownership structure (shareholders: name/shares/percent). Amounts are in RON; indicators the page omits come back as null.

Note: BVB does not expose multi-year income/balance/cash-flow statements as structured data, so there is no historical ROE/margin/FCF series here — pair this with get_candles (price history) for trend context.

ParametersJSON Schema
NameRequiredDescriptionDefault
tickerYesBVB ticker, e.g. "TLV", "SNP", or "ATB".

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Description discloses that data is scraped (read-only), indicates amounts in RON, explains null handling for omitted indicators, and aligns with annotations (readOnlyHint=true). Adds value beyond annotations by detailing data source and behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is well-structured with bulleted lists and clear sections, but is slightly verbose. Every sentence adds value, but could be trimmed for brevity while maintaining clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists and description already covers main data categories, null handling, and data source limitations. No missing essential details for proper tool usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and description provides example tickers (TLV, SNP, ATB) which add helpful context beyond the schema description. Parameter semantics are clear but description does not significantly extend meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it returns company details and valuation snapshot from the detail page, listing specific data categories like valuation ratios, issue info, and ownership structure. It distinguishes from sibling tools like get_candles by noting it provides fundamental data rather than price history.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly notes that multi-year financial statements are not available and suggests pairing with get_candles for trend context. This provides clear guidance on when to use and what alternatives exist.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_symbol_infoA
Read-only

Resolve one BVB ticker to its symbol metadata.

Returns: ticker, name (short name), description (issuer/full name), exchange (always "BVB"), type (e.g. "Shares"), session (trading hours, e.g. "0700-1830"), timezone ("Europe/Bucharest"), currency_code (e.g. "RON"), sector, industry, has_intraday (whether intraday bars exist), supported_resolutions, and pricescale (the datafeed's price scaling factor). Errors if the ticker does not resolve.

ParametersJSON Schema
NameRequiredDescriptionDefault
tickerYesBVB ticker, e.g. "TLV", "SNP", or "BRD".

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description acknowledges the read-only nature (consistent with readOnlyHint) and adds that errors occur for unresolvable tickers. It lists all returned fields, providing transparency beyond the annotations alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: a clear opening sentence followed by a bulleted list of returned fields. Every sentence adds value, and there is no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, has output schema), the description is fully complete. It covers the single parameter, lists all return fields, and notes an error condition. No gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema coverage, the input schema already describes the parameter. The description adds only examples (e.g., 'TLV') but does not provide extra semantic value beyond what the schema offers.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Resolve one BVB ticker to its symbol metadata.' It specifies the action (resolve) and resource (ticker metadata), and is distinct from sibling tools like search_symbol (searching) and get_candles (candles).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when a specific BVB ticker is known and metadata is needed, but does not explicitly state when to use or not use this tool versus alternatives. No exclusions or when-not-to guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_indicesA
Read-only

List the BVB index universe (BET, BET-TR, BET-FI, ROTX, …).

Scrapes the indices overview page. Returns up to limit indices, each {symbol, name, isin}. Every index's symbol is returned; name and isin are populated only for indices BVB renders a server-side profile for (others load via client-side tabs) and are otherwise null. Pass a symbol to get_candles to chart an index.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of indices to return

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses data source ('Scrapes the indices overview page') and explains nullable fields (name, isin) when server-side profile missing, beyond the readOnlyHint annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Few sentences, front-loaded with purpose, efficiently conveys key usage and behavior without superfluous text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With output schema present, description still adds value by explaining return fields and null behavior; covers main logic and edge cases well.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers limit parameter 100%; description adds minimal extra meaning ('Returns up to limit indices') but no new semantic detail beyond what schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description specifies 'List the BVB index universe' with concrete examples (BET, BET-TR) and distinguishes from sibling get_candles by showing how the output is used.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides a clear use case (list indices) and explicitly connects to get_candles for charting, but does not contrast with other siblings like list_instruments.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_instrumentsA
Read-only

List the instrument universe for a BVB market.

Scrapes the exchange's market-list page (the datafeed search is capped and unsuitable for enumeration). Returns up to limit instruments, each {ticker, isin, name, market} — isin is the 12-character BVB ISIN (or null if the page omits it), name is the issuer, and market echoes the normalised market key.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of instruments to return
marketNoInstrument market: 'shares', 'bonds', 'fund-units' (ETFs), 'warrants', or 'certificates' ('structured'). For indices use list_indices.shares

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true. Description adds context about scraping behavior, limit handling, and that ISIN may be null. No contradictions. Adds value beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two well-organized paragraphs. First sentence states purpose, second provides technical details. Could be slightly more compact, but effectively front-loaded and every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that an output schema exists, the description is complete. It explains the scraping approach, limit, output fields, and null handling. No gaps for a tool of this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline 3. Description adds meaning by explaining the output fields (ticker, isin, name, market) and that ISIN can be null, going beyond the schema's parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description precisely states it lists the instrument universe for a BVB market, using specific verbs and resources. It distinguishes from siblings by mentioning 'For indices use list_indices' and implies differentiation from search_symbol.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use (enumeration of instruments by market) and when not (capped datafeed search). Provides clear alternative for indices via list_indices and explains rationale for scraping.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_symbolA
Read-only

Search the datafeed for symbols matching a query.

Returns up to limit matches, each with symbol, ticker, full_name, description (includes the ISIN as its trailing token), isin (extracted from the description for convenience), exchange, and type (lowercase: "share", "bond", "structured", …).

Note: the datafeed caps this search at roughly 30 results for broad queries, so it is a lookup aid, not a way to enumerate the full universe — use list_instruments (or list_indices) for that.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of results to return
queryYesFree-text query matched against ticker and name, e.g. "TLV" or "banca".

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only. Description adds details on result cap, field types, and that limit controls max matches. Provides useful behavioral context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise paragraphs with front-loaded purpose and a clear note. No extraneous text; every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers all needed aspects: purpose, usage, constraints, return fields. Output schema exists, so return format is covered. Complete for a low-complexity read-only tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema already describes both parameters with examples. Description does not add new parameter-level information; it only references limit in context of result count. With 100% schema coverage, baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it searches for symbols matching a query, lists returned fields, and distinguishes from sibling tools list_instruments/list_indices for enumeration.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly notes it is a lookup aid (not for full enumeration) and suggests using list_instruments or list_indices for that purpose. Also mentions result cap at ~30.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

server_timeA
Read-only

Get BVB's datafeed server time.

Returns unix (server time in unix seconds) and iso (the same instant as an ISO 8601 UTC timestamp). Useful as a reachability check and to anchor from_/to windows for get_candles.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=true, and the description confirms a read operation returning two timestamps. No hidden side effects or ambiguities exist; the behavior is fully disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise—two sentences that fully convey the tool's purpose, return values, and use cases without superfluous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description adequately covers all relevant aspects: purpose, output format, and usage context. Given the tool's simplicity and the presence of an output schema, no additional details are necessary.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so schema coverage is 100%. The description does not need to add parameter details, earning a baseline score of 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves server time with specific return fields (unix and iso). It stands apart from sibling tools like get_candles or search_symbol by focusing on a simple reachability check.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly mentions two use cases: reachability check and anchoring time windows for get_candles. While it doesn't list when not to use it, the provided guidance is concrete and actionable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 9 tool updatesv0.1.0
    • First observeddatafeed_config
    • First observedfinancial_summary
    • First observedget_candles
    • First observedget_fundamentals
    • First observedget_symbol_info
    • First observedlist_indices
    • First observedlist_instruments
    • First observedsearch_symbol
    • First observedserver_time
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0
Disambiguation5/5

Each tool targets a distinct aspect of the BVB datafeed: configuration, symbol lookup, time, search, candles, instrument/indices listing, fundamentals, and a bundled summary. No two tools overlap in purpose.

Naming Consistency4/5

Eight of nine tools follow a consistent verb_noun pattern (e.g., get_symbol_info, list_instruments). Only financial_summary deviates, but it is still descriptive. Minor inconsistency.

Tool Count5/5

Nine tools cover all core functionalities for a stock exchange datafeed: configuration, symbol info, search, time, candles, instrument/indices listing, fundamentals. Each tool serves a clear and necessary purpose.

Completeness4/5

The toolset covers basic CRUD for market data: search, list, get candles, get fundamentals. Missing depth like historical financial statements is noted in descriptions as unavailable, so the gap is acknowledged. Minor but acceptable.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • market-data-mcp

    SmashToes
    -
    license
    Not graded
    quality
    Not graded
    maintenance
    Real-time financial market data MCP server. Stocks, crypto, technicals, sentiment, FDA calendar. No API keys required.
    -

  • tokenbel/financial-data

    Red-Panda-Dev
    A
    license
    Not graded
    quality
    D
    maintenance
    Read-only MCP server providing access to Belarusian securities data: tokens, shares, bonds, companies, ticker search, and company name or UNP search.
    MIT

  • Mercado Financeiro BR

    mcp-dir
    A
    license
    Not graded
    quality
    D
    maintenance
    Provides Brazilian financial market data (stocks, dividends, FIIs, crypto, exchange rates, macro indicators) from B3. Works with any MCP client via HTTP, read-only.
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/florinel-chis/bvb-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server