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., "@CSE MCP Server what's the current stock price of John Keells Holdings?"
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.
A Model Context Protocol (MCP) server that provides real-time stock market data from the Colombo Stock Exchange (CSE). This server enables AI assistants to search for companies and retrieve current stock prices from the Sri Lankan stock market.
Company Search: Search for CSE-listed companies by name or symbol with fuzzy matching
Real-time Stock Data: Get current price, change, and percentage change for any CSE ticker
Fuzzy Matching: Find companies even with typos or partial names
308 Companies: Complete database of all CSE-listed companies
Related MCP server: CSE MCP Server
claude mcp add cse-mcp -- npx cse-mcpAlternatively, add to your Claude configuration (~/Library/Application Support/Claude/claude_desktop_config.json on Mac):
{
"mcpServers": {
"cse": {
"command": "npx",
"args": ["cse-mcp"]
}
}
}Use the following command configuration:
Command: npx
Arguments: ["cse-mcp"]
Search for companies listed on the Colombo Stock Exchange.
Input:
query (string): Company name or symbol to search
Features:
Returns top 3 matches using fuzzy search
Searches both symbol and company name
Handles typos and partial matches
Example:
{
"query": "john keells"
}Response:
{
"query": "john keells",
"count": 3,
"companies": [
{
"id": 297,
"symbol": "JKH.N0000",
"name": "JOHN KEELLS HOLDINGS PLC"
},
{
"id": 596,
"symbol": "JKL.N0000",
"name": "JOHN KEELLS HOTELS PLC"
},
{
"id": 556,
"symbol": "JKPL.N0000",
"name": "JOHN KEELLS PLC"
}
],
"note": "Top 3 matches using fuzzy search"
}Get real-time stock price data for a specific ticker symbol.
Input:
symbol (string): Exact ticker symbol (e.g., "JKH.N0000")
Features:
Validates symbol against company database
Fetches real-time data from CSE API
Returns price in Sri Lankan Rupees (Rs.)
Example:
{
"symbol": "JKH.N0000"
}Response:
{
"symbol": "JKH.N0000",
"companyName": "JOHN KEELLS HOLDINGS PLC",
"price": "Rs. 22.20",
"change": "-0.10",
"changePercentage": "-0.45%",
"lastUpdated": "2024-12-17T10:30:00.000Z"
}Node.js 16 or higher
npm or yarn
# Clone the repository
git clone https://github.com/Shaveen12/cse-mcp.git
cd cse-mcp
# Install dependencies
npm install
# Build TypeScript
npm run build
# Run in development mode (watches for changes)
npm run dev
# Test locally with MCP Inspector
npx @modelcontextprotocol/inspector node dist/index.jscse-mcp/
├── src/
│ └── index.ts # Main server implementation
├── bin/
│ └── cse-mcp.js # CLI entry point
├── dist/ # Compiled JavaScript (generated)
├── cse_companies.csv # Company database
├── package.json
├── tsconfig.json
└── README.mdThe CSE API has the following considerations:
No authentication required
Reasonable rate limiting is recommended
Timeout set to 10 seconds per request
Company data and real-time prices are sourced from the Colombo Stock Exchange.
Contributions are welcome! Please feel free to submit a Pull Request.
Fork the repository
Create your feature branch (git checkout -b feature/AmazingFeature)
Commit your changes (git commit -m 'Add some AmazingFeature')
Push to the branch (git push origin feature/AmazingFeature)
Open a Pull Request
This project is licensed under the ISC License - see the package.json file for details.
This tool is for informational purposes only. Stock market data may be delayed. Always verify data with official sources before making investment decisions.
For issues, questions, or suggestions, please open an issue on GitHub.
Colombo Stock Exchange for providing the data API
Model Context Protocol for the MCP SDK
Get comprehensive company information including 52-week high/low, YTD metrics, market cap, and beta values. Use search_company first to find the correct symbol.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Ticker symbol from CSE (e.g., 'JKH.N0000') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It lists the returned data types but does not disclose potential behaviors like error handling, data freshness, or query limits. The description is 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 concise sentences: the first states the purpose with examples, the second gives usage guidance. No redundant information, and the content is front-loaded.
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, prerequisite, and example outputs. While it omits details like authentication or real-time vs. delayed data, it is sufficient given the simplicity of the tool and absence of 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?
Schema coverage is 100% with a description for the symbol parameter. The description adds a concrete example ('JKH.N0000') and suggests using search_company first, which adds meaning beyond the schema pattern alone.
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 it retrieves comprehensive company info and lists specific metrics (52-week high/low, YTD metrics, market cap, beta). It distinguishes from siblings like search_company by explicitly stating a prerequisite.
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?
Provides explicit guidance to use search_company first to find the correct symbol, which clarifies when this tool is appropriate. However, it does not mention when to avoid this tool in favor of other siblings like get_stock_data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the overall market summary including total trade volume, share volume, and trade date.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the output fields (volume, date) and implies a read-only action. Given the tool's simplicity (no params), the description is adequate but could mention data freshness or scope.
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 concise sentence that directly conveys purpose and primary outputs. No wasted words.
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 zero-parameter tool with no output schema or annotations, the description is minimal. It covers the basic purpose but lacks depth about output structure, data recency, or any caveats. Could be more 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?
There are no parameters, so schema coverage is 100%. The description adds no parameter details, but none are needed. Baseline for 0 params is 4.
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 it gets the overall market summary and specifies included fields (total trade volume, share volume, trade date). This distinctly separates it from sibling tools that focus on individual companies or filtered lists.
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 use for broad market overview but does not explicitly state when to use versus siblings or provide exclusions. The context of sibling tools helps but is not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the top 10 most actively traded stocks by volume in the CSE for the current trading day.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses that the data is for the current trading day, but omits other behavioral traits such as real-time nature, rate limits, handling of market closures, or whether results are sorted. This is a minimal but acceptable disclosure for a simple read-only query.
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 wasted words. It front-loads the key action and result scope. Every piece of information is relevant and compact.
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, parameterless tool, the description is mostly complete: it specifies the number of items, metric (volume), exchange, and time frame. However, it lacks details about the output format (e.g., fields like symbol, volume, price). Since no output schema exists, a brief mention of return fields would improve completeness. Overall, adequate for the tool's simplicity.
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 zero parameters, so the description does not need to explain any parameters. Schema coverage is trivially 100%. The baseline score for zero parameters is 4, and the description adds no unnecessary parameter information.
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 the top 10 most actively traded stocks by volume in the CSE for the current trading day. This specific verb-resource combination ('get most active stocks') and scope ('top 10', 'volume', 'CSE', 'current day') effectively distinguishes it from siblings like 'get_top_gainers' and 'get_top_losers'.
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 when the agent needs the most actively traded stocks by volume for the current day. However, it provides no explicit guidance on when not to use this tool or how it compares to siblings (e.g., gainers vs volume). Given the straightforward nature and zero parameters, a score of 3 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get real-time stock price data for a specific CSE ticker symbol. Use search_company first to find the correct symbol.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Ticker symbol from CSE (e.g., 'JKH.N0000') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. States 'real-time stock price data' but lacks details on rate limits, error handling, or return format. Adequate but 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?
Two sentences, no wasted words, front-loaded with purpose. Very concise for a simple tool.
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?
Tool is simple (1 required param, no output schema), but description omits return data details. Adequate but could state what fields are returned.
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 has 100% coverage with pattern and description. Description adds value by explaining CSE context and format examples (e.g., 'JKH.N0000'), plus guidance to search first.
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?
Describes verb 'Get' and resource 'real-time stock price data for a specific CSE ticker symbol'. Distinguishes from siblings by focusing on a single symbol and recommends search_company first.
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 tells agent to use search_company first to find correct symbol, providing clear when-to-use guidance and implicit when-not-to.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the top 10 gaining stocks in the CSE for the current trading day.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description fully discloses the tool's behavior: it returns the top 10 gaining stocks for the current day. It does not mention data freshness or auth requirements, but given the simplicity, it is transparent.
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 12 words, no filler, and front-loads the key information. Every word is essential.
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 lacks details about the output format (e.g., fields returned). With no output schema, agents may need to infer the structure. However, the tool is simple and the description is adequate for basic usage.
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?
There are no parameters, so the schema coverage is 100% automatically. The description does not need to add parameter details; baseline 4 applies.
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 ('Get'), the specific resource ('top 10 gaining stocks'), and the scope ('in the CSE for the current trading day'). It distinguishes from siblings like get_top_losers and get_most_active_stocks.
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 is straightforward with no parameters. The description implicitly guides when to use this tool (for top gainers) versus siblings, but it does not explicitly exclude other scenarios or mention 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.
Get the top 10 losing stocks in the CSE for the current trading day.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The tool is a straightforward read operation. However, with no annotations, the description does not disclose behavioral details like whether data is real-time, delayed, or historical, or what happens if the market is closed. Basic transparency is provided but 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, well-structured sentence that conveys all necessary information without extraneous words. It is front-loaded with the key action and resource.
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 tool with no parameters and no output schema, the description is mostly complete. However, it could be improved by noting what data fields are returned (e.g., ticker, percent change) to set user expectations. It is adequate but not exhaustive.
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?
There are no parameters (0 params), so the description adds no parameter-level information. However, schema coverage is 100% (empty schema), and no additional meaning is needed beyond the tool's purpose.
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 action ('get'), the resource ('top 10 losing stocks'), the exchange ('CSE'), and the time frame ('current trading day'). It effectively distinguishes from sibling tools like 'get_top_gainers' by focusing on losers and specifying the exchange.
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_detailed_company_info' or 'get_top_gainers'. There is no mention of prerequisites, limitations (e.g., only CSE data), 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.
Search for Colombo Stock Exchange companies by name or symbol. Uses fuzzy matching to return the 3 closest matches.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Company name or symbol to search (e.g., 'JKH' or 'John Keells') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: fuzzy matching and limited results (3 matches). It does not mention read-only status or error handling, but for a search tool this is acceptable.
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 extremely concise: two short sentences that front-load the purpose and key behavior. Every word is meaningful with no 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 the tool's simplicity and full schema coverage, the description provides essential context (fuzzy matching, result limit). It could mention lack of side effects or pagination, but overall it is sufficiently 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?
Schema coverage is 100% with a good description for the 'query' parameter. The tool description does not add extra meaning beyond the schema, meeting the baseline of 3.
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 specific verb 'Search' and the resource 'Colombo Stock Exchange companies by name or symbol,' distinguishing it from sibling tools like get_detailed_company_info which provide detailed info for a specific company.
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 how it works ('fuzzy matching', 'returns 3 closest matches'), implying it's for initial searches before detailed lookup. However, it does not explicitly state when not to use or name alternative tools.
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.
get_detailed_company_infoget_market_summaryget_most_active_stocksget_stock_dataget_top_gainersget_top_loserssearch_companyTools are mostly distinct: search_company finds symbols, get_stock_data provides real-time price, get_detailed_company_info gives comprehensive data, and the remaining four cover market overviews. There is a slight overlap between get_stock_data and get_detailed_company_info (both include price data), but descriptions clarify the difference.
All tool names follow a consistent 'get_' prefix with descriptive snake_case noun phrases (e.g., get_detailed_company_info, get_most_active_stocks). No mixing of conventions or vague verbs.
7 tools is well-scoped for a stock exchange MCP server. It provides a focused set covering search, individual stock data, company info, and market summaries without being overly numerous or sparse.
The tool set covers basic read operations (search, price, details, market summary, top movers) but lacks historical data, time series, or order book information. While functional for common queries, there are notable gaps for more advanced analysis.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Fetch current stock prices and key data for symbols across global markets. Look up companies like…
Look up the latest stock prices by ticker symbol across global markets. Get current price and esse…
Analyze stocks with summaries, price targets, and analyst recommendations. Track SEC filings, divi…
Provide access to Chinese stock market data including historical prices, real-time data, news, and…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Shaveen12/cse-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server