Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@bd-finance-mcp What's the spread between GP on DSE and CSE?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Bangladesh's financial markets, available to your AI assistant. Both stock exchanges, every listed share, and what the taka is worth today.
An MCP server built with FastMCP.
⚠️ Not investment advice. This reports publicly published prices. It does not analyse, recommend, or predict. Figures are last-traded values and may lag the live market.
Unofficial. Not affiliated with DSE, CSE, or Bangladesh Bank.
Tool | What it does |
| The same share priced on both exchanges, with the spread between them. |
| Breadth — how many shares rose, fell, held flat or never traded. |
|
|
| Prices for specific trading codes. |
| Find codes by substring, e.g. |
| How a whole sector traded — did banks rise while textiles fell? |
| The 22 DSE sectors you can ask about. |
| Sector, market cap, P/E ratio, paid-up capital, shares outstanding. |
| Taka per USD, EUR, GBP, SAR, AED, MYR and 160 more. |
| Latest business and financial headlines. |
| Which papers are covered, and which could not be. |
company_profile turns a bare price into something you can reason about — GP trades at a P/E of
11.44 in Telecommunication with a 326,907mn taka market cap, BRAC Bank at 6.14 in Banking. Prices
alone don't tell you that.
compare_exchanges is the one you can't easily do yourself — most Bangladeshi companies list on
both markets, and the prices genuinely differ. GP was trading at 240.60 on Dhaka and 241.50 on
Chittagong while this was being written.
sector_performance answers the question a price list can't: how did banks do today? It
aggregates every share in a sector — advancers, decliners, average move, best and worst — from
one query. Partial names work, so "pharma" finds "Pharmaceuticals & Chemicals".
Prices tell you a share moved; finance_news tells you why.
Every market response carries a market block saying whether DSE is currently trading
(Sunday–Thursday, 10:00–14:30 Asia/Dhaka) and whether the figures are live or the last completed
session. Outside session hours, "today's gainers" means the previous close — the response says so
rather than leaving you to assume.
Related MCP server: MCP-Server-Financial-Analyzer
Source | Provides |
Dhaka Stock Exchange — ~395 instruments, company fundamentals | |
Chittagong Stock Exchange — ~387 instruments | |
Currency reference rates, 166 currencies | |
dsebd.org sector pages | 22 sectors and their constituents |
The Daily Star — Business | Bangladeshi business news |
The Business Standard — Economy | Bangladeshi business news |
Dhaka Tribune | General newsroom (see note below) |
Financial Times — Companies | International business news |
Dhaka Tribune publishes no business-only feed, so its articles are general newsroom output.
finance_news leaves it out by default (business_only=True) rather than passing student
politics off as market coverage — name it in sources, or set business_only=False, to include it.
Bonik Barta is not available. It is a single-page app: every path, including /api/v1/,
returns the same HTML shell with HTTP 200. There is no feed or API behind it. A status code alone
is not proof a source works.
New Age is not available. No working RSS feed exists at any conventional path.
Financial Times links are paywalled. Headlines and summaries come through the public feed; the articles themselves require a subscription.
No API key, login, or paid data feed.
Not included: Bangladesh Bank. Its econdata pages sit behind a CAPTCHA challenge. That is an
explicit request not to automate, and this project respects it rather than working around it. Use
exchange_rate for reference rates instead — but note those are mid-market, not BB's official
rate, and not what a bank will actually pay you.
Not included: gold prices. BAJUS renders them client-side; nothing is in the HTML to parse.
Not included: the DSEX index. It appears only in DSE's navigation menus — the live value is
injected by JavaScript, so there is nothing to read from the served HTML. market_summary gives
you breadth and turnover instead, which describes the session without pretending to quote an
index it cannot see.
Requires uv and Python 3.12+.
git clone https://github.com/Claudefarid/bd-finance-mcp.git
cd bd-finance-mcp
uv sync
uv run fastmcp install claude-code server.py:mcpRestart your client, then ask "Compare GP's price on both Bangladeshi exchanges" or "What's the taka doing against the riyal?"
Verify with uv run python test_server.py.
Each of these produces wrong answers rather than errors — the dangerous kind of bug.
1. The two exchanges disagree about untraded shares.
DSE reports a share that did not trade with price 0. CSE carries yesterday's price forward.
Compute percent change naively and DSE hands you a list of −100% "crashes" that are really just
shares nobody bought. Trade count is the only signal that works on both, so it decides whether a
percentage is meaningful here.
This matters more on CSE than you would guess: 187 of its 387 listed shares did not trade on the day this was written. Nearly half the market. Get this wrong and CSE data is worthless.
2. dsebd.org serves an incomplete TLS certificate chain.
Its leaf certificate is signed by a Sectigo intermediate the server never sends. Browsers and
curl recover by fetching it via AIA; Python's certifi bundle cannot, so httpx fails with
CERTIFICATE_VERIFY_FAILED.
The fix is not verify=False — that disables verification altogether, which is a bad trade
anywhere and a worse one for financial data. Verify against the OS trust store instead:
import ssl, truststore
ctx = truststore.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
httpx.AsyncClient(verify=ctx)3. DSE's P/E table is one column per trading day, and the newest is last.
The ratio table sits under a Particulars header whose columns are dates. Read the first column —
the obvious choice — and you report a P/E from a week ago as today's. company_profile takes the
last populated column and returns the date alongside it, so the figure is always checkable.
There is a second trap in the same table: the page carries several Particulars headers, and the
first one reads "Unaudited / Audited" rather than dates. Matching on width picks the right one.
A missing P/E is not a parsing failure, either. DSE prints - across the row for companies
without meaningful earnings — BEXIMCO, for one — so None there is the honest answer.
4. The Daily Star's feed puts HTML inside its <title> tags.
Its headlines arrive wrapped in an unescaped anchor:
<title><a href="/business/news/...">7,896 customers withdraw Tk 327 crore</a></title>ElementTree parses that anchor as a child element, so findtext("title") returns an empty
string — not an error, just nothing. Every Daily Star headline came back blank, and because an
empty headline matches no keyword, the paper looked like it was ignoring every topic when it was
simply never being read. "".join(element.itertext()) collects descendant text and fixes it.
5. Substring matching puts the IT sector inside "Financial Institutions".
The obvious way to resolve a sector name is query in name.lower(). Ask for "IT" and you match
both IT Sector and Financial Inst**it**utions — so the most natural query for the sector fails as
ambiguous. Matching runs in tiers instead: exact, then prefix, then word-boundary, then substring,
taking the first tier that resolves to one sector.
6. Mid-market rates are not remittance rates.
exchange_rate returns reference rates. Banks and exchange houses apply their own spread, so
what actually lands in a recipient's account is lower. The tool says so in its own description,
so a model relying on it does not quietly present these as the rate you'd receive.
Each call is a single page fetch, and requests identify themselves by User-Agent. Don't poll in a tight loop.
MIT — see LICENSE. Covers this code only, not the exchanges' data.
Fundamentals for one DSE-listed company: sector, market cap, P/E, capital.
This is the context a price alone cannot give you — what business the company is in, how large it is, and what the market is paying per taka of earnings. DSE-listed companies only.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral disclosure burden. It is transparent about the kind of data returned and the market scope, but it does not mention whether the data is point-in-time, how missing or invalid codes are handled, or whether the operation is strictly read-only. These are not severe gaps for a profile-lookup tool, but they prevent a higher score.
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 first sentence is front-loaded and gives the essential information immediately. The second sentence adds value by explaining what the fundamentals mean in practical terms, and the third reinforces the DSE-only restriction. There is minor redundancy, but the description remains compact and readable.
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?
For a tool with one required string parameter and an existing output schema, the description provides sufficient context: it defines the domain, the kind of data returned, and the restriction to DSE-listed companies. It omits an example code or explicit statements about lookup behavior, but those are minor given the tool's simplicity and the presence of an output schema.
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 input schema has one parameter, 'code', with no description and 0% schema coverage. The description indirectly identifies it as the identifier for a DSE-listed company, which provides some semantic grounding. However, it does not explicitly state that 'code' is the DSE trading code or give an example, so the agent must infer the expected format.
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 provides fundamentals for one DSE-listed company and lists the specific fields: sector, market cap, P/E, and capital. It also distinguishes itself from price-focused tools by saying it supplies 'the context a price alone cannot give you,' and the phrase 'DSE-listed companies only' defines the target resource. Despite lacking an explicit verb, the intent is unambiguous.
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 gives clear contextual guidance: use this when you need fundamental context beyond price, and only for DSE-listed companies. It implicitly contrasts with price-only tools and includes an exclusion ('DSE-listed companies only'). However, it does not explicitly name sibling alternatives like get_stock or search_stock, nor does it state when not to use this tool for price data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Price the same share on both Dhaka and Chittagong exchanges.
Most Bangladeshi companies are listed on both. Prices can differ, and the gap is the kind of thing you cannot see without checking two sites.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It communicates that the tool compares prices across two exchanges and explains why that matters, but it does not disclose edge cases like companies listed on only one exchange, data freshness, or how failures are handled.
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 core instruction is front-loaded in the first sentence. The two following sentences add useful context about dual listing and price divergence without redundancy, making the description appropriately sized and well structured.
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 provides helpful context about the two Bangladeshi exchanges, but it leaves the single required parameter ambiguous and does not address companies listed on only one exchange. Since there is an output schema, return-value documentation is not the issue; the missing input semantics are.
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 only defines a required 'code' string with 0% description coverage. The description's phrase 'same share' implies that code identifies a company/share, but it never specifies whether this is a DSE code, CSE code, or normalized ticker, nor what format the agent should pass.
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 action: price the same share on both Dhaka and Chittagong exchanges. It is specific about the resource and scope, though it does not explicitly distinguish itself from sibling tools like get_stock or 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?
The context that most Bangladeshi companies are listed on both exchanges and that prices can differ implies when this tool is useful. However, it lacks explicit guidance about when not to use it or when to prefer a sibling tool such as get_stock for a single-exchange quote.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What one unit of foreign currency is worth in taka.
Defaults to the currencies that matter most for Bangladeshi remittances. Rates are mid-market reference rates — banks and exchange houses apply their own spread, so what you actually receive will be lower.
| Name | Required | Description | Default |
|---|---|---|---|
| currencies | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that rates are mid-market reference rates, that banks add spreads, and that the tool defaults to remittance-relevant currencies—useful behavioral context beyond the bare schema.
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, each adding meaningful information: purpose, default behavior, and rate caveat. No filler 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?
For a tool with one optional parameter and an output schema, the description covers the key contextual points: what the rate represents, which currencies are defaulted, and a practical caveat. The main gap is the lack of parameter value format, but this is minor for such a 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 description coverage is 0%, so the description must compensate. It mentions the default behavior of the 'currencies' parameter but does not explain what values are accepted (e.g., currency codes, case sensitivity, format), leaving an ambiguous parameter.
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's function: converting one unit of a foreign currency into taka. It names the resource ('exchange rate') and the scope, though it doesn't explicitly differentiate from the sibling 'compare_exchanges'.
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 context by mentioning defaults for Bangladeshi remittances and warning that actual received rates are lower. However, it does not explicitly state when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Latest business and financial news, newest first.
Use this to explain what the market is doing — prices tell you a share
moved, the news tells you why. Pass keyword to keep only articles
mentioning a company, sector or topic.
sources limits the scan: 'dailystar', 'tbsnews', 'dhakatribune' or 'ft'
(international, paywalled links). Naming a source always includes it.
Dhaka Tribune publishes no business-only feed, so its articles are general
newsroom output. business_only keeps it out of the default mix — set it
False for wider coverage, or name it in sources to read it directly.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| keyword | No | ||
| sources | No | ||
| business_only | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden, and it does so well. It reveals the sort order, how keyword filtering narrows results, the inclusive-source rule, and the non-obvious business_only/Dhaka Tribune behavior. There is no contradiction with the schema, and all important behavioral nuances are surfaced.
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 compact and well-structured: the core purpose comes first, then usage context, then parameter-level details, then the most specialized caveat. Every sentence earns its place, and none of the prose is redundant with the schema or output schema.
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?
For a tool with four optional parameters and no annotations, the description covers all non-obvious invocation decisions, including an intentional data-source quirk. Since an output schema exists, return-value documentation is not required. The only unmentioned parameter, limit, is straightforward from the schema, so nothing material is missing.
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%, so the description must compensate. It adds real meaning to keyword, sources, and business_only, including valid source values, paywall status, and the Dhaka Tribune feed behavior. The only parameter left entirely to the schema is limit, though its name, integer type, and default value make it self-explanatory.
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 opening line 'Latest business and financial news, newest first' names both the resource and the ordering, and the next sentence gives the practical job: explain what the market is doing. This distinguishes it from sibling price/market tools like top_movers and get_stock by framing the tool as the news-side explanation rather than another market number source.
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 tells the agent when to use it: when prices show that something moved and the agent needs the reason, use the news. It also gives detailed source-selection guidance and a meaningful caveat about Dhaka Tribune. It does not explicitly name a sibling alternative or state a 'do not use when' case, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current prices for specific trading codes on one exchange.
Codes are short symbols like ['GP', 'BRACBANK']. Use compare_exchanges to see one share priced on both markets at once.
| Name | Required | Description | Default |
|---|---|---|---|
| codes | Yes | ||
| exchange | No | dse |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description itself must carry safety and behavior. It clearly frames a read-only price lookup, but gives no details on invalid codes, data delay, limits, or error behavior. This is acceptable for a simple lookup but leaves some edge cases undisclosed.
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 sentences, each earning its place: the first states the core function, the second gives an example and an alternative. No filler or redundant restatement.
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?
For a low-complexity tool with an output schema, the main gap is exchange values: an agent cannot know valid options beyond the default 'dse' from this description. Otherwise, the description and schema together are enough to call get_stock for the default case.
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 description adds concrete meaning to codes with the example ['GP', 'BRACBANK'], which the bare schema lacks. However, the exchange parameter is only implied by 'one exchange' and its accepted values or relationship to the default 'dse' are not explained.
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?
States a specific action: fetching current prices for given trading codes on a single exchange. The 'one exchange' scope and explicit 'Codes are short symbols' example distinguish it from compare_exchanges.
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 routes agents to compare_exchanges when a share price on both markets is needed, which defines when not to use this tool. 'Specific trading codes on one exchange' also implies it is for targeted quotes rather than market-wide tools like top_movers or market_summary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Which news feeds are covered, and which financial papers are not.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses a useful behavioral nuance: the tool not only reports covered feeds but also identifies what is not covered. The list-style operation is implied by the name and no side effects are suggested.
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 a single concise sentence that conveys the essential scope without redundancy. Every word adds value, and it is appropriately brief for a tool with no parameters.
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 tool has no parameters and an output schema exists, the description is largely complete. It explains what the tool reports including the negative case, though a brief mention of how it relates to sibling tools would improve context.
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 tool has zero parameters and 100% schema coverage, so there are no parameter semantics to explain. The description appropriately focuses on the query's purpose rather than parameter details, meeting the baseline for a no-parameter tool.
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 states the tool's purpose: to show which news feeds are covered and which financial papers are not. It clearly identifies the resource (news sources) and the specific scope of coverage, though it lacks a direct verb like 'list' or 'returns'.
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 the tool is for checking coverage of news sources and financial papers, but it does not explicitly say when to use this tool instead of siblings like finance_news or market_summary. Usage context is strongly implied by 'coverage' but no alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the DSE sectors you can ask about, e.g. Bank, Textile, Pharmaceuticals.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden. For a zero-parameter list operation, 'List the DSE sectors...' transparently signals a non-mutating enumeration, and the examples clarify what kind of values will be returned; no hidden side effects are plausible for this tool.
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?
One short sentence with the key operation front-loaded and examples as supporting detail. There is no redundant text or repetition of the title beyond the essential verb.
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?
For a tool with no parameters and an existing output schema, the description covers the core purpose and domain with examples. It could be more complete by pointing to downstream consumers such as sector_performance or noting ordering behavior, but those are not necessary for correct invocation.
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 tool has zero parameters and 100% schema coverage, so the baseline is 4. The description adds no parameter documentation (there are none), but the examples of sector names give useful operational value by showing the domain of returned 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?
The description names the action ('List') and the exact resource ('DSE sectors you can ask about'), with concrete examples (Bank, Textile, Pharmaceuticals) that make the domain unambiguous. It is clear, though it does not explicitly differentiate itself from sector_performance or other siblings.
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 phrase 'you can ask about' implies the tool is for discovering which sector names are valid inputs to other DSE queries, but no explicit when-to-use or alternative is given. An agent can infer the usage context but receives no direct routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Market breadth — how many shares rose, fell, held flat or never traded.
| Name | Required | Description | Default |
|---|---|---|---|
| exchange | No | dse |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral transparency burden. It communicates the output concept but says nothing about call behavior, the default exchange, time window, data source, or side effects. There is no contradiction, but the disclosure 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?
The description is a single sentence with no filler and a clear, front-loaded concept. Every word contributes meaning, making it extremely concise.
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?
Despite its simplicity, the description leaves a clear gap by not explaining the exchange parameter and not guiding selection among the sibling tools. The output schema may cover return values, but the call parameter and usage context remain under-specified.
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 exposes one optional exchange parameter with a default of 'dse' and has 0% schema description coverage. The description never mentions the exchange parameter, so an agent cannot learn what values are valid or how the parameter affects the summary.
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 identifies the tool's output as market breadth counts of rose/fell/flat/never-traded shares. It is specific enough to distinguish from sibling tools like get_stock or sector_performance, though it lacks an explicit action verb and does not directly contrast with siblings.
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?
There is no guidance about when to use market_summary versus the ten sibling tools, nor any mention of prerequisites or exclusions. The intended use is only implied by the output definition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find trading codes containing a substring, e.g. 'BANK' or 'PHARMA'.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| exchange | No | dse |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Find' and gives examples, without revealing details such as case sensitivity, exact matching behavior, pagination/limits, or whether the exchange parameter changes the search scope. Some behavioral expectations are implied but not explicitly disclosed.
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 a single sentence with no filler. It front-loads the action ('Find trading codes') and uses examples to convey the substring behavior efficiently, making it easy for an agent to parse quickly.
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?
Although the tool is simple and has an output schema, the description omits essential context about the 'exchange' parameter and does not provide usage guidance. Given no annotations, the missing parameter explanation and lack of guidance leave the description incomplete for reliable invocation.
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%, and the description does not explain the parameters directly. It implies that 'query' is a substring, but it does not explain the 'exchange' parameter or its default value 'dse'. Since the schema provides no descriptions, the text needed to clarify both parameters, and it only partially addresses 'query'.
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's function: 'Find trading codes containing a substring', with concrete examples such as 'BANK' or 'PHARMA'. This distinguishes it from siblings like get_stock, which likely retrieves a specific stock rather than searching by substring, though it does not explicitly name the sibling it differs from.
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 is provided on when to use this tool versus alternatives such as get_stock or top_movers. The description implies a search use case, but it does not state when to choose this tool, what limitations exist, or when another sibling would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How one DSE sector traded today — did banks rise while textiles fell?
Aggregates every share in the sector: how many advanced, declined or never traded, the average move, and the best and worst performers. Partial names match, so "pharma" finds "Pharmaceuticals & Chemicals".
| Name | Required | Description | Default |
|---|---|---|---|
| sector | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently explains the aggregation behavior, the types of statistics returned, and the partial-name matching feature, including a concrete example. It does not explicitly state that the operation is read-only, but the phrasing and focus on historical trading data make that reasonably clear.
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 and well-structured: an attention-grabbing example first, followed by the aggregation details, then the matching behavior. Every sentence adds value, and there is no redundant or filler content. The structure front-loads the core purpose before giving supporting detail.
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 the tool's purpose, output statistics, and input matching behavior in a way that is sufficient for most calls. The presence of an output schema reduces the need to document return values in detail. It might have mentioned using list_sectors to discover valid sector names, but the partial-match behavior makes this less critical.
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 input schema provides only a bare string parameter with no description, so the description must compensate. It adds meaningful semantics by explaining that the parameter is a sector name and that partial matches are accepted, with an example. It could be even more explicit about acceptable formats, such as case sensitivity or exact name requirements, but the example provides enough guidance for correct invocation.
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 identifies the tool as aggregating sector-level trading statistics for a single DSE sector, listing specific outputs: advance/decline/never-traded counts, average move, and best/worst performers. The opening example ('did banks rise while textiles fell?') makes the purpose intuitive and distinguishes it from sibling tools like top_movers or get_stock, which focus on individual securities or market-wide moves.
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 provides clear context for when to use the tool: when the user wants to know how one sector traded today. It implies the contrast with market-wide or stock-specific tools, though it does not explicitly name alternatives or state when not to use it. The partial-name matching note also guides callers on what input format is acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Biggest movers of the session on one exchange.
direction is 'gainers', 'losers', 'volume' or 'value'. Gainers and losers
rank by percent change, so cheap and expensive shares compare fairly.
Shares that did not trade are excluded rather than shown as total losses.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| exchange | No | dse | |
| direction | No | gainers |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure and does so reasonably well. It explains that gainers and losers rank by percent change, notes that untraded shares are excluded rather than shown as losses, and defines the meaning of the direction parameter. It does not mention rate limits, authentication, or exact output contents, but the output schema covers the return structure.
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 compact and front-loaded with the core purpose, followed by two sentences that add meaningful ranking and exclusion behavior. Every sentence earns its place, and there is no redundant filler or repetition of the tool name.
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?
For a simple query tool with an output schema, the description covers the key invocation details: the supported direction values, the ranking basis, and the handling of untraded shares. It does not document possible exchange identifiers or limit constraints, but the defaults in the schema and the self-explanatory parameter names reduce the practical gap. The main missing element is usage routing relative to sibling tools, which is already penalized under usage guidelines.
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%, so the description must compensate for missing parameter documentation. It thoroughly explains the 'direction' parameter, including its valid values and ranking semantics, but it does not explain 'limit' or acceptable 'exchange' values beyond the default in the schema. The parameter names are self-explanatory, but the description only partially bridges the schema's lack of documentation.
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 identifies the resource as the session's biggest movers on one exchange, which is specific enough to distinguish the tool's subject matter from siblings like market_summary or compare_exchanges. However, it lacks an explicit verb such as 'List' or 'Get,' and it does not directly differentiate itself from sibling tools by name.
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 explains what the tool returns and clarifies the 'direction' values, but it provides no guidance on when to use this tool versus alternatives. There are no explicit when-to-use or when-not-to-use conditions, nor any mention of sibling tools like market_summary for broader market context or compare_exchanges for multi-exchange comparisons.
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. Dates show when Glama detected each change.
v0.1.0company_profilecompare_exchangesexchange_ratefinance_newsget_stocklist_news_sourceslist_sectorsmarket_summarysearch_stocksector_performancetop_moversEach tool targets a distinct slice of the market: movers, breadth, quotes, sectors, news, FX, and cross-exchange comparison. The only mild ambiguity is between get_stock and compare_exchanges, but the descriptions explicitly point from one to the other.
Names are all snake_case, but the set mixes verb-led actions (search_stock, list_sectors, get_stock, compare_exchanges) with noun-only snapshots (top_movers, market_summary, exchange_rate, company_profile, finance_news, sector_performance). There is no single predictable pattern, though each name is still readable.
11 tools is well within the ideal range, and each tool covers a meaningful part of the domain: quotes, movers, sectors, fundamentals, news, FX, and exchange comparison. No obvious redundancy that would justify trimming.
The server covers the main read-only market data needs: current prices, movers, breadth, sector aggregates, company fundamentals, news, FX, and dual-exchange quotes. Missing historical price/performance and index-level data are notable but workable gaps for an agent doing day-of analysis.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
The financial MCP for AI agents - 90+ financial tables, SEC filings, signals, alt-data.
Official-source financial data for AI agents: Korea, US, Taiwan, Japan, Europe. 37 tools, free tier.
Provide AI assistants with real-time access to official SEC EDGAR filings and financial data. Enab…
SEC EDGAR financials, insider trading, and economic data for AI agents. US GAAP + IFRS.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Claudefarid/bd-finance-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
