Skip to main content
Glama
stockintelix

stock-intelix

by stockintelix
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Stock Intelix — Model Context Protocol (MCP) Server

MCP Registry License: MIT Node.js Version

Official Model Context Protocol (MCP) server for Stock Intelix — quantitative equity intelligence and probabilistic price range forecasting across 34 global exchanges.

Designed for seamless integration with Claude Desktop, Cursor, Glama, and any AI agent supporting the Model Context Protocol.

Capabilities & Tools

This MCP server equips AI assistants with two specialized financial tools:

1. get_forecast

Retrieve quantitative probabilistic price forecasts and risk horizons for any covered equity ticker.

  • Parameters:

    • symbol (string, required): Equity ticker (e.g., AAPL, NVDA, RELIANCE.BSE, SAP.XETRA).

    • horizon (integer, optional): Forecast horizon in trading days from 5 to 120 (default: 20).

  • Output: Current price, directional probability (bullish/bearish odds), probabilistic percentiles (p10, p25, median p50, p75, p90), calibration metrics, and catalyst risk score.

2. search_securities

Search the Stock Intelix global database across 34 exchanges to find the exact symbol for any company.

  • Parameters:

    • query (string, required): Company name or ticker fragment (min 2 characters, e.g. Microsoft or MSFT).

    • exchange (string, optional): Filter by market code (e.g. NASDAQ, NYSE, BSE, LSE, DFM).

  • Output: List of matching equities, exchange codes, and operational status.

Related MCP server: fahali-mcp

Authentication & API Keys

All calls to the Stock Intelix API require an API key:

  1. Sign up or log in at stockintelix.com.

  2. Navigate to Console / Developers (https://stockintelix.com/app/developers).

  3. Generate an API Key (starts with sik_...).

Set the API key as an environment variable:

export STOCK_INTELIX_API_KEY="sik_your_api_key_here"

Quickstart

Option A: Using with Claude Desktop

Add this configuration to your claude_desktop_config.json:

{
  "mcpServers": {
    "stock-intelix": {
      "command": "npx",
      "args": ["-y", "stock-intelix-mcp"],
      "env": {
        "STOCK_INTELIX_API_KEY": "sik_your_api_key_here"
      }
    }
  }
}

Option B: Using with Cursor

  1. Open Cursor Settings → Features → MCP.

  2. Click + Add New MCP Server.

  3. Select Command / Stdio:

    • Name: stock-intelix

    • Command: npx -y stock-intelix-mcp

    • Environment Variable: STOCK_INTELIX_API_KEY=sik_your_api_key_here

Option C: Using Docker / Glama

Build and run using the included Dockerfile:

# Build container
docker build -t stock-intelix-mcp .

# Run with your API key
docker run -i --rm -e STOCK_INTELIX_API_KEY="sik_your_api_key_here" stock-intelix-mcp

Development & Local Testing

# Clone the repository
git clone https://github.com/stockintelix/stock-intelix-mcp.git
cd stock-intelix-mcp

# Install dependencies
npm install

# Test run locally
STOCK_INTELIX_API_KEY="sik_test" node index.js

Disclaimer

All forecasts and quantitative metrics provided by Stock Intelix are informational models and data analytics only. They do not constitute financial advice, buy/sell recommendations, or endorsements.

License

MIT © 2026 Stock Intelix

Available Tools

2 tools
get_forecastB

Retrieve probabilistic stock price range forecasts, directional probability, uncertainty intervals, and catalyst risk for an equity ticker across 34 global exchanges.

NameRequiredDescriptionDefault
symbolYesEquity symbol / ticker (e.g., AAPL, NVDA, RELIANCE.BSE, SAP.XETRA).
horizonNoForecast horizon in trading days (5 to 120, default is 20).

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden; it discloses that forecasts are probabilistic, include directional probability, uncertainty intervals, catalyst risk, and cover 34 global exchanges. However, it does not mention permissions, rate limits, data freshness or caching, or any limitations of the forecast.

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

Conciseness5/5

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

The description is a single dense sentence that front-loads the core action and then enumerates outputs and scope. Every clause contributes useful information without redundancy.

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

Completeness4/5

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

For a two-parameter read tool with complete schema coverage and no output schema, the description sufficiently explains what the tool returns and its exchange scope. It could be stronger with usage conditions or behavioral caveats, but nothing critical for invocation is missing.

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

Parameters3/5

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

Schema coverage is 100%, so both the symbol and horizon parameters are fully documented in the input schema. The description adds only a general reference to equity tickers and global exchange coverage, not parameter-specific semantics beyond what the schema provides.

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

Purpose4/5

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

The description names a specific verb and resource ('Retrieve probabilistic stock price range forecasts') and enumerates the kinds of outputs returned. It does not explicitly differentiate itself from the sibling search_securities tool, but the forecast function is distinct enough that an agent can identify what it does.

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

Usage Guidelines2/5

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

The description gives no guidance on when to use this tool versus search_securities or any other alternative, and it states no prerequisites or exclusions. Usage is only implied by the purpose statement.

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

search_securitiesA

Search for equities by company name or ticker across 34 supported global exchanges.

NameRequiredDescriptionDefault
queryYesCompany name or ticker fragment (at least 2 characters, e.g. 'Apple' or 'AAPL').
exchangeNoOptional exchange code filter (e.g., NASDAQ, NYSE, LSE, BSE, XETRA).

TDQS

A3.5/5.0
Behavior2/5

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 implies a read-only search by nature but does not disclose authentication needs, rate limits, result caps, pagination behavior, or what the response contains.

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

Conciseness5/5

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

The description is a single front-loaded sentence with zero waste, stating the verb, resource, query modes, and scope efficiently.

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

Completeness3/5

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

For a simple two-parameter search tool with full schema coverage, the description is adequate but leaves gaps: it does not indicate what the results contain or whether there are limits on returned matches. With no output schema, some return-value context would be helpful.

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

Parameters3/5

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

Schema description coverage is 100%, and both parameters are already documented with examples and a minimum length. The description reinforces that search works by company name or ticker and mentions exchange coverage, but adds no syntax or constraints beyond what the schema provides.

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

Purpose5/5

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

States a specific verb ('Search') and resource ('equities'), along with the query modes ('company name or ticker') and scope ('34 supported global exchanges'). The sibling tool get_forecast is clearly unrelated, so there is no ambiguity about what this tool does.

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

Usage Guidelines3/5

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

The description implies usage for finding equities by name or ticker and mentions the exchange filter context, but it does not explicitly state when to use this tool versus alternatives or when not to use it. With only an unrelated sibling, the implied usage is sufficient but not strong guidance.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv1.0.0
    • First observedget_forecast
    • First observedsearch_securities
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: search_securities finds securities by name or ticker, while get_forecast retrieves forecasts for a known ticker. There is no meaningful overlap, so an agent should not confuse them.

Naming Consistency5/5

Both names use the same snake_case verb_noun convention: get_forecast and search_securities. There is no mixing of styles or abbreviations.

Tool Count3/5

Only two tools are exposed, which is thin even for a focused forecast/search server. They are well chosen, but the surface feels minimal rather than fully scoped.

Completeness4/5

The core read-only workflow is covered: find a security by name or ticker, then retrieve a probabilistic forecast. Minor gaps remain around batch comparisons or exchange metadata, but there is no obvious dead end for the stated purpose.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers