Provides access to historical Indonesian stock data from the GitHub Dataset-Saham-IDX repository, covering 2019-2025 with over 958 stocks.
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., "@Baguskto Saham show me the banking sector performance"
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.
MCP Server untuk mengakses data Bursa Efek Indonesia (IDX) dengan dukungan data historis lengkap dari tahun 2019 hingga kini. Dibangun dengan TypeScript dan @modelcontextprotocol/sdk, server ini memungkinkan AI assistant untuk mengambil informasi saham real-time, data historis komprehensif, analisis teknikal, dan performa sektor.
✅ Data historis 2019–kini (Yahoo Finance + GitHub archive, auto-merge)
✅ Yahoo Finance sebagai sumber utama (data terbaru selalu tersedia)
✅ GitHub Dataset-Saham-IDX sebagai deep-history archive (2019–Feb 2025)
✅ Auto-merge: Yahoo menang untuk tanggal overlap, archive backfill gap
✅ Periode pendek (1d/1w/1m) langsung dari Yahoo (archive stagnan diabaikan)
Catatan data: Dataset GitHub komunitas berhenti di-update sekitar Feb 2025. Strategi hybrid memastikan data 2025–2026 tetap tersedia via Yahoo Finance.
Related MCP server: Baguskto Saham
Market overview (IHSG, volume, top movers)
Stock info (price, ratios, market cap)
Historical data (2019-2025, OHLCV)
Sector performance
Stock search dan comparison
Technical analysis
958 saham IDX
Multi-source dengan fallback
TypeScript + Zod validation
Cara termudah menggunakan Baguskto Saham adalah dengan npx:
# Jalankan langsung dengan npx (otomatis install dan run)
npx @baguskto/saham@latest
# Command line options (implemented)
npx @baguskto/saham --help # Show help
npx @baguskto/saham --version # Show version
# Environment variables
IDX_MCP_DEBUG=true npx @baguskto/saham@latest # Debug mode
IDX_MCP_LOG_LEVEL=error npx @baguskto/saham@latest # MCP mode# npm
npm install @baguskto/saham@latest
# yarn
yarn add @baguskto/saham
# pnpm
pnpm add @baguskto/saham# Clone the repository
git clone https://github.com/baguskto/saham-mcp.git
cd saham-mcp
# Install dependencies
npm install
# Build the project
npm run build
# Run in development mode
npm run dev
# Run tests
npm testThe server provides 9 comprehensive MCP tools (fully implemented):
Get Indonesian stock market overview including IHSG index.
{
"name": "get_market_overview",
"arguments": {}
}Response:
{
"success": true,
"data": {
"ihsgValue": 7234.56,
"ihsgChange": 45.23,
"ihsgChangePercent": 0.63,
"tradingVolume": 12300000000,
"tradingValue": 8700000000000,
"marketStatus": "open",
"topGainers": [
{"ticker": "ADRO", "name": "Adaro Energy", "price": 2840, "changePercent": 6.8}
],
"topLosers": [
{"ticker": "EMTK", "name": "Elang Mahkota", "price": 156, "changePercent": -3.2}
],
"lastUpdated": "2025-01-15T08:30:00.000Z"
},
"source": "live",
"responseTime": 1250
}Get detailed information for a specific Indonesian stock.
{
"name": "get_stock_info",
"arguments": {
"ticker": "BBCA"
}
}Get historical price data for a specific stock from 2019 to present.
{
"name": "get_historical_data",
"arguments": {
"ticker": "TLKM",
"period": "5y"
}
}Parameters:
ticker: Stock ticker symbol (required)
period: Time period - "1d", "1w", "1m", "3m", "6m", "1y", "2y", "5y" (default: "1y")
Historical Data Coverage:
Time Range: July 2019 - Present (6+ years)
Data Points: ~1,200+ entries per stock
Stocks Covered: 958 IDX-listed stocks
Data Quality: 91%+ success rate
Get performance data for all IDX sectors.
{
"name": "get_sector_performance",
"arguments": {}
}Search for stocks by company name or ticker symbol from 958 available stocks.
{
"name": "search_stocks",
"arguments": {
"query": "bank"
}
}Get comprehensive technical analysis for a stock with indicators and recommendations.
{
"name": "get_stock_analysis",
"arguments": {
"ticker": "BBCA",
"period": "2y"
}
}Parameters:
ticker: Stock ticker symbol (required)
period: Analysis period - "1m", "3m", "6m", "1y", "2y", "5y" (default: "1y")
Compare performance of multiple stocks over a specified period.
{
"name": "compare_stocks",
"arguments": {
"tickers": ["BBCA", "BBRI", "BMRI"],
"period": "2y"
}
}Parameters:
tickers: Array of 2-5 stock ticker symbols (required)
period: Comparison period - "1m", "3m", "6m", "1y", "2y" (default: "1y")
Get list of all 958 available stock tickers in the historical dataset.
{
"name": "get_available_stocks",
"arguments": {}
}Response includes:
Complete list of available IDX stocks
Sector breakdown:
sectors: count of available stocks per sector
sectorUniverse: full sector → ticker counts from the bundled stock list
withKnownSector: number of available stocks matched to a known sector
Get information about the historical dataset including last update and coverage.
{
"name": "get_dataset_info",
"arguments": {}
}Response includes:
Repository information and last update
Total available stocks (958)
Cache statistics
Data coverage range (2019-2025)
Create a .env file or set environment variables:
# Server settings
IDX_MCP_SERVER_NAME="IDX MCP Server"
IDX_MCP_DEBUG=false
# MCP Mode (for clean JSON-RPC communication)
IDX_MCP_LOG_LEVEL=error # Enables MCP mode
# Cache settings
IDX_MCP_CACHE_TYPE=memory # memory or redis
IDX_MCP_CACHE_TTL_MARKET_OVERVIEW=60
IDX_MCP_CACHE_TTL_STOCK_INFO=300
IDX_MCP_CACHE_TTL_HISTORICAL=86400 # 24 hours for historical data
# Data source timeouts
IDX_MCP_YAHOO_TIMEOUT=10000
IDX_MCP_WEB_TIMEOUT=15000Tambahkan ke file konfigurasi Claude Desktop:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%/Claude/claude_desktop_config.json
{
"mcpServers": {
"baguskto-saham": {
"command": "npx",
"args": ["@baguskto/saham@latest"],
"env": {
"IDX_MCP_LOG_LEVEL": "error"
}
}
}
}{
"mcpServers": {
"saham": {
"command": "npx",
"args": ["@baguskto/saham@latest"]
}
}
}The server uses a DataSourceManager that coordinates multiple data sources:
GitHubDatasetSource (Historical Data)
Source: wildangunawan/Dataset-Saham-IDX
Implementation: src/data-sources/github-dataset.ts
Coverage: 2019-2025 (6+ years)
Stocks: 958 IDX stocks
Priority: HIGH
Cache TTL: 24 hours
YahooFinanceSource (Real-time Data)
Implementation: src/data-sources/yahoo-finance.ts
Library: yahoo-finance2
Real-time stock quotes and IHSG index
Priority: HIGH
Cache TTL: 5 minutes
WebScrapingSource (Fallback)
Implementation: src/data-sources/web-scraper.ts
Library: cheerio + axios
Fallback when primary sources fail
Priority: MEDIUM
Response Time: < 2 seconds for all queries
Historical Data: 1,200+ data points per stock (2019-2025)
Success Rate: 91%+ for historical data parsing
Caching Strategy:
Market overview: 1 minute
Stock info: 5 minutes
Historical data: 24 hours
Dataset info: Live fetch with caching
Error Handling: Graceful degradation with multi-source fallback
MCP Compliance: Clean JSON-RPC communication without parsing errors
"Show me BBCA stock performance over the last 5 years"
"Compare the 2-year performance of major banking stocks: BBCA, BBRI, BMRI"
"Get historical analysis of Telkom Indonesia (TLKM) from 2019 to now"
"What's the current market overview and how has IHSG performed this year?"
"Analyze the technical indicators for ADRO over the last 2 years"
"Search for mining stocks and show their 5-year performance"
"What's the dataset coverage and how many stocks are available?"
"Show me the best performing stocks in the last 6 months"src/
├── types/ # TypeScript type definitions
│ └── index.ts # All type exports
├── config/ # Configuration management
│ └── index.ts # AppConfig with Zod validation
├── utils/ # Utilities and helpers
│ ├── logger.ts # Winston logging setup
│ └── github-api.ts # GitHub API service
├── cache/ # Caching layer
│ └── index.ts # Memory cache with TTL
├── data-sources/ # Data source implementations
│ ├── base.ts # DataSource and DataSourceManager
│ ├── github-dataset.ts # GitHub Dataset-Saham-IDX integration
│ ├── yahoo-finance.ts # Yahoo Finance integration
│ ├── web-scraper.ts # Web scraping fallback
│ └── index.ts # Data source management
├── services/ # Business logic services
│ ├── historical-data-service.ts # Historical data with caching
│ ├── csv-parser.ts # Robust CSV parsing
│ └── technical-analysis.ts # Technical indicators
├── server/ # MCP server implementation
│ └── index.ts # IDXMCPServer with 9 tools
├── cli.ts # CLI with Commander.js
├── mcp-entry.ts # MCP stdio entry point
└── index.ts # Main exportsJSON parsing errors in MCP mode
# Ensure MCP mode is enabled
IDX_MCP_LOG_LEVEL=error npx @baguskto/sahamHistorical data not loading
# Clear cache and retry
npx @baguskto/saham clear-cache
# Test GitHub connectivity
npx @baguskto/saham testYahoo Finance timeouts
Increase timeout in configuration
Check internet connectivity
Use debug mode for diagnosis
# Enable debug logging (not for MCP mode)
IDX_MCP_DEBUG=true IDX_MCP_LOG_LEVEL=debug npx @baguskto/saham✅ Complete GitHub Dataset Integration: Full access to 2019-2025 historical data via GitHubDatasetSource
✅ Fixed Column Mapping Bug: Resolved CSV parsing issues in csv-parser.ts (date column priority)
✅ Extended Period Support: Added 2y and 5y analysis periods to all tools
✅ JSON-RPC Compliance: Clean MCP protocol via mcp-entry.ts with stdout interception
✅ Enhanced Error Handling: Comprehensive error handling in DataSourceManager
✅ 958 Stock Coverage: Complete IDX stock universe from Dataset-Saham-IDX repository
✅ TypeScript Implementation: Full TypeScript with Zod validation and type safety
v1.0.4: Basic MCP implementation with Yahoo Finance
v1.0.0-1.0.3: Initial releases and bug fixes
Fork the repository at GitHub
Create a feature branch
Make your changes
Add tests if applicable
Submit a pull request
MIT License - see LICENSE file for details.
GitHub Issues: Report bugs
Discussions: Community discussions
Documentation: GitHub Repository
Dataset Credit: Historical data provided by Dataset-Saham-IDX repository.
Disclaimer: This server provides market data for informational purposes only. Not intended for trading or investment decisions. Always verify data from official sources.
Compare performance of multiple stocks over a specified period
| Name | Required | Description | Default |
|---|---|---|---|
| tickers | Yes | Array of stock ticker symbols to compare | |
| period | No | Comparison period | 1y |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description should disclose behavioral traits. It fails to specify whether the operation is read-only, what performance metrics are returned, rate limits, or any side effects.
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?
Single sentence conveying the core purpose without extraneous information. It is front-loaded and every word is necessary.
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 output format (e.g., what data is returned, how results are presented) and does not explain the meaning of the period parameter values. For a comparison tool, users need more context about the expected results.
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 100% (both parameters documented). The description adds no new meaning beyond 'compare performance', which is already implied by the tool name. Baseline 3 is appropriate.
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 verb 'compare' and resource 'stocks', specifying 'performance of multiple stocks over a specified period'. It distinguishes from sibling tools like get_stock_analysis (single stock) and get_historical_data (single stock history).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for comparing multiple stocks but lacks explicit when-to-use or when-not-to-use guidance. No alternative tools are mentioned, such as get_stock_analysis for single stock analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get list of all available stock tickers in the historical dataset
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It accurately says it returns a list, but does not disclose other behaviors (e.g., read-only, sorting, authentication needs).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is concise and immediately conveys the tool's purpose.
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 simplicity of the tool (zero parameters, no output schema), the description adequately explains what it returns. However, it lacks details like return format or whether list is sorted.
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 zero parameters, so the baseline is 4. The description does not need to cover parameters as the schema is empty.
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 returns a list of available stock tickers in the historical dataset. This is distinct from sibling tools like get_stock_info or search_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?
The usage is clear: use this to get available tickers. However, it does not explicitly state when not to use or mention alternatives, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about the historical dataset including last update and coverage
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description indicates a read operation returning specific fields, but lacks details on output structure, error conditions, or any behavioral quirks. No annotations to supplement.
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?
Single, well-structured sentence that is front-loaded and contains no redundant information.
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?
Adequately describes the output for a simple metadata tool with no parameters and no output schema. Could be slightly more explicit about what 'information' includes beyond last update and coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; schema is empty and fully covered. Baseline 4 for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool gets information about the historical dataset, specifically last update and coverage. Distinguishes from siblings like get_historical_data (data series) and get_stock_info (specific stock).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for metadata about the dataset, but no explicit when-to-use or when-not-to-use guidance. With multiple sibling tools, an exclusions or alternatives mention would be beneficial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get historical price data for a specific stock
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Stock ticker symbol | |
| period | No | Time period for historical data | 1y |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but merely restates the tool name. It does not disclose what fields are returned (e.g., open, high, low, close, volume), data granularity, or any auth requirements. This leaves the agent unaware of the output 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 a single sentence with no wasted words. It is appropriately concise for a simple tool, though it could be slightly more informative without losing brevity.
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 lack of annotations and output schema, the description is insufficient. It does not explain the nature of the returned data (e.g., OHLCV, intervals) or handle edge cases like missing data. The tool is simple, but the description should provide more context for an agent to use it confidently.
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 already has 100% coverage with descriptions for both 'ticker' and 'period', including an enum for period. The description adds no extra meaning beyond the schema, so a baseline score of 3 is appropriate.
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 verb 'Get' and the resource 'historical price data for a specific stock'. It concisely identifies the tool's main function. However, it does not differentiate from sibling tools like 'get_stock_analysis' or 'compare_stocks', which diminishes clarity slightly.
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 no guidance on when to use this tool versus alternatives. It does not mention prerequisites, limitations, or scenarios where this tool is preferred over siblings like 'get_stock_info' (for current data) or 'get_market_overview'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Indonesian stock market overview including IHSG index, volume, and top movers
| 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 indicates a read operation ('Get') but does not disclose any behavioral traits such as data freshness, rate limits, or side effects. The description is minimal and lacks depth about what happens when the tool is invoked.
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, front-loading the verb 'Get' and the resource. It is appropriately concise 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 no output schema, the description partially defines return values (IHSG index, volume, top movers) but remains vague ('top movers' could refer to gainers, losers, or both). No data timeframe is mentioned. For a simple overview tool, the description is adequate but lacks complete specification.
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, and the schema coverage is 100% (empty schema). The description adds value by listing the components of the overview (IHSG index, volume, top movers), which provides semantic meaning beyond the empty input schema. The baseline for zero parameters 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 that the tool retrieves an Indonesian stock market overview, specifically including IHSG index, volume, and top movers. It uses a specific verb 'Get' and distinguishes the tool from siblings such as get_sector_performance or compare_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?
No guidance is provided on when to use this tool vs alternatives. There is no mention of context, prerequisites, or exclusions. Among siblings like get_historical_data or get_stock_analysis, the description does not clarify the appropriate use case for this overview tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get performance data for all IDX sectors
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states 'Get performance data' without disclosing behavioral traits (e.g., read-only, data freshness, rate limits). Fails to inform the agent about the operation's safety or side effects.
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?
Single sentence, front-loaded with verb and resource. No unnecessary words, efficient and clear.
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?
With no output schema, description should hint at return structure. 'Performance data' is vague (could be a list of sectors with returns). Minimal but adequate for a simple tool; could be richer.
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 zero parameters and 100% coverage. For 0-param tools, baseline is 4; description adds no further meaning but is not needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and clearly identifies the resource 'performance data for all IDX sectors'. It distinguishes from sibling tools like 'get_stock_analysis' (individual stocks) and 'get_market_overview' (broader market).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Does not specify contexts like comparing sector performance or that individual stock tasks should use sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comprehensive technical analysis for a stock with indicators and recommendations
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Stock ticker symbol (e.g., BBCA, TLKM) | |
| period | No | Analysis period | 1y |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only vaguely mentions 'indicators and recommendations' without specifying what indicators, how many, or any potential side effects or requirements. Lacks detail on output format or computational cost.
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?
Single, clear sentence with no unnecessary words. Front-loaded with the core action and outcome. Efficiently conveys the tool's purpose.
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 lack of output schema and annotations, the description is somewhat vague about the output (only 'analysis with indicators and recommendations'). For a simple tool with two parameters, it is minimally adequate but could mention the nature of the return value (e.g., text report vs. structured data).
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 100%, and the parameters are well described in the schema (ticker with example, period with enum). The tool description adds no additional meaning beyond what the schema already provides, so baseline 3 is appropriate.
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 uses a specific verb 'Get' and resource 'stock', clearly stating it provides 'comprehensive technical analysis with indicators and recommendations'. This distinguishes it from siblings like 'get_historical_data' (raw data) and 'compare_stocks' (comparison).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Does not mention prerequisites, limitations, or when not to use it. Sibling tools exist (e.g., 'get_historical_data', 'get_stock_info') but no differentiation is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information for a specific Indonesian stock
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Stock ticker symbol (e.g., BBCA, TLKM) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description implies read operation but does not disclose behavior such as data freshness, rate limits, or what 'detailed information' specifically includes. Minimal transparency beyond the basic action.
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?
Single sentence, 8 words, entirely front-loaded with key information. No wasted words, though could be slightly expanded for clarity.
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?
With no output schema and no annotations, the description is insufficient to understand what 'detailed information' includes. Compared to siblings like get_stock_analysis or get_historical_data, this tool's output is ambiguous, lacking context on return values.
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 parameter 'ticker' described. Description adds no additional meaning beyond the schema, meeting the baseline for high-coverage cases. No extra context like format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'get' and resource 'detailed information for a specific Indonesian stock', specifying geographic scope. However, it does not differentiate from sibling tool 'get_stock_analysis' which may have overlapping purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., get_stock_analysis, get_historical_data). No context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for stocks by company name or ticker symbol
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (company name or partial ticker) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It fails to mention whether the search is exact or fuzzy, what fields are matched, or any side effects. As a read-like operation, read-only hint is absent. The description is insufficient for an agent to understand behavior.
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 that is concise and front-loaded. It immediately conveys the core purpose without any redundant words or irrelevant details.
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 no output schema and no annotations, the description is too minimal. It lacks information about what the tool returns (e.g., list of matches, symbols, full details), which is critical for an agent to decide if the tool meets its needs. Completeness is inadequate for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description ('by company name or ticker symbol') aligns with the parameter description ('Search query (company name or partial ticker)'). The description adds no new meaning beyond what the schema already provides, so baseline score of 3 is appropriate.
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 verb 'search', the resource 'stocks', and the methods 'company name or ticker symbol'. It distinguishes the tool from siblings like 'compare_stocks' or 'get_available_stocks' by focusing on searching by specific criteria.
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 over alternatives. For example, it doesn't clarify that 'search_stocks' is for finding specific stocks by name/ticker, while 'get_available_stocks' lists all available stocks. The agent lacks context to choose effectively.
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.
v1.0.5compare_stocksget_available_stocksget_dataset_infoget_historical_dataget_market_overviewget_sector_performanceget_stock_analysisget_stock_infosearch_stocksEach tool targets a distinct function: comparing stocks, fetching historical data, getting analysis, searching, etc. No two tools have overlapping purposes.
All tools follow a consistent verb_noun snake_case pattern (e.g., compare_stocks, get_historical_data, search_stocks) with no deviations.
9 tools is an ideal scope for a stock market server, covering all major operations without being overwhelming or too sparse.
The tool surface covers all essential stock data tasks: listing, searching, info, historical data, comparison, market overview, sector performance, and technical analysis, leaving no obvious gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Data saham Indonesia (IDX) untuk AI: harga, teknikal, screener, deteksi bandar, sektor, earnings.
Official-source financial data for AI agents: Korea, US, Taiwan, Japan, Europe. 37 tools, free tier.
AI stock intelligence: prices, fundamentals, technicals, news, macro regime, and sector signals.
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/kevindoni/idx-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server