Insights

Remote MCP Server for Stock Data Research

Alphanume Team · August 15, 2026

A remote MCP server for stock data lets a compatible research client connect to one hosted endpoint, discover tools, and query maintained datasets without running a local server package.

For stock data research, the main operational benefit is consistency. Alphanume hosts the MCP service at https://mcp.alphanume.com/mcp for browser OAuth and at https://mcp.alphanume.com/key/mcp for API-key clients. The hosted server exposes 25 read-only tools that proxy the same deterministic point-in-time records available through REST.

A local MCP package adds another environment to install, configure, and update. Two researchers can wind up with different package versions or stale tool definitions. A hosted Streamable HTTP connection centralizes that server code. Each client still has its own MCP support, credentials, network path, model, and conversation state, so the hosted endpoint removes one source of drift rather than every source.

What moves to the hosted service

Layer	Hosted responsibility	Client responsibility
Transport	Serve the remote MCP endpoint over HTTPS	Support Streamable HTTP and maintain connectivity
Tool catalog	Publish the current 25 tool schemas	Discover the catalog at connection time
Data calls	Forward validated filters to Alphanume REST	Choose the intended tool and arguments
Authentication	Resolve OAuth or validate an API key	Protect credentials and approve access
Research record	Return structured API payloads	Save prompts, calls, rows, and interpretations

The MCP transport specification describes Streamable HTTP as a standard server transport. That makes the connection portable across compatible clients. It does not make every client configuration identical, so use the client's current remote-server instructions and the Alphanume endpoint shown in the hosted MCP connection guide.

Connect without leaking the key

OAuth is the simplest path for a client that can open a browser. Add the hosted OAuth URL, complete the Alphanume sign-in and consent flow, then return to the client. A client without browser OAuth can use the key endpoint with an X-API-Key or Bearer header. Keep that secret in the client's credential store or environment, never inside a research prompt.

Remote connection checklist

OAuth endpoint: https://mcp.alphanume.com/mcp
API-key endpoint: https://mcp.alphanume.com/key/mcp
Transport: Streamable HTTP
First tool call: check_api_status
Expected purpose: verify connectivity and credential status
Secret handling: client credential store or environment
Research log: tool name, arguments, response status, row count

The two endpoints expose the same tools and apply the same account tier. check_api_status verifies that the server can reach the API with the supplied credential. It does not certify that every dataset has a row for a requested date, and it does not tell you whether a model interpreted a response correctly.

Check status before a multi-tool screen

A multi-tool workflow should fail early when the connection or credential is broken. Begin with status, then run a small fixed-date request, inspect the raw structure, and only then ask for a join. This keeps an authentication failure from becoming a long agent response built around missing data.

Use the hosted Alphanume MCP server only.

1. Call check_api_status and stop if it reports an error.
2. Call get_optionable_tickers for one exact returned snapshot date.
3. Call get_historical_market_cap for the same date.
4. Join only on date plus ticker.
5. Return each tool name, exact arguments, count, cursor state,
   truncation marker, and unmatched-row count.
6. Preserve nulls and do not infer missing values.
7. Describe the result as a research screen, not a validated strategy.

That staged prompt also makes debugging more useful. If status passes and the data call fails, inspect the date format, range, access tier, and tool filters. If both calls pass but the join is sparse, inspect observation dates and coverage instead of assuming the remote transport lost rows.

Hosted removes one kind of drift

Failure mode	What you see	First check
Expired or rejected credential	Status or tool call returns an authorization error	Reconnect OAuth or replace the stored key
Unsupported client transport	Server cannot be added or initialized	Confirm current Streamable HTTP support
Restricted date range	403 DATE_RANGE_RESTRICTED	Compare requested dates with account tier
MCP response cap	truncated_to_max_rows appears	Narrow dates or tickers
Model chose the wrong tool	Valid response with the wrong schema	Require tool names and arguments in output

Network outages, client updates, OAuth-session expiry, and model variability remain possible. A hosted server also does not independently validate a hypothesis or guarantee profit. Production research still benefits from translating a settled workflow into direct REST calls with fixed parameters, retries, and durable logs.

Run a five-minute connection audit

Add the appropriate hosted URL, authenticate, and call check_api_status. Save its result and the client's reported tool catalog. Then run one fixed-date data call, verify the expected count and data shape, and record any truncation marker before attempting a multi-tool screen.

The practical win is a shared server contract without local package upkeep. Review the access tiers if the test needs older history, and use the agent-research topic hub for adjacent patterns on audit logs, point-in-time joins, and REST handoffs.