This server is a read-only market-research toolset for querying public financial, macro, and company data without an API key or trading access.
search_markets: Search Nomina's catalog (crypto, FX, gold, Treasury yields, macro series, SEC registrants) and get recent headlines.
research_asset: Get latest value, period change, drawdown/volatility, dated history, and headlines for a single symbol.
compare_assets: Align 2–6 symbols on shared observation dates for comparison.
market_overview: View period changes for major assets (BTC, ETH, SOL, gold, SPY, QQQ, EUR/USD, US yields, CPI).
company_fundamentals: Retrieve latest annual and quarterly financials and SEC filings for a US-listed registrant.
Leverages Chainlink price feeds to supply current and historical asset prices, enabling research, comparison, and market overview tools for crypto, FX, metals, and more.
Reads on-chain price feed data from the Ethereum blockchain to provide market data for cryptocurrencies, FX, gold, and select US equities/ETFs.
Click on "Deploy 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., "@Nomina Compare Apple and Microsoft over the last month, with price history and related news."
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.
Markets research for agents from public data.
Five read-only tools, no API key, no account, no trading access:
search_markets — find symbols in Nomina's catalog (on-chain price feeds, Treasury
tenors, macro series, SEC registrants) and recent headlines.
research_asset — latest value, period change, drawdown and volatility, dated history,
and headlines for one symbol, over a named period or an exact date window.
compare_assets — align 2–6 symbols on shared observation dates, each in its own unit.
market_overview — period changes for BTC, ETH, SOL, gold, SPY, QQQ, EUR/USD, US 2y
and 10y yields and CPI.
company_fundamentals — latest annual and quarterly financials and filings for an SEC
registrant.
Data: Chainlink price feeds read from the Ethereum blockchain (crypto, FX, gold and silver, a few US equities/ETFs), the US Treasury yield curve, Bureau of Labor Statistics series, SEC EDGAR filings, and GDELT headlines: public-domain government statistics, public blockchain state, and openly released news records, each source's obligations documented and met in Data sources and limits.
Hosted (no install): add https://mcp.nomina.io/mcp as a custom connector in
Claude (Settings → Connectors → Add custom connector), or
claude mcp add --transport http nomina https://mcp.nomina.io/mcp. First request
after an idle period can take about a minute.
Claude Desktop: Settings → Extensions → Advanced settings → Extension Developer →
Install Extension… → select Nomina.mcpb from a
release (or build it yourself, see below). Requires a Claude Desktop
release with MCPB v0.4 UV-runtime support and internet access on first install.
Any other MCP client (Claude Code, etc.): point it at this as a local stdio server:
{
"mcpServers": {
"nomina": {
"command": "uv",
"args": ["run", "--frozen", "--no-dev", "--directory", "/path/to/nomp", "server.py"]
}
}
}Self-hosted (Streamable HTTP): docker run --rm -p 8000:8000 ghcr.io/nomina-xyz/nomina-mcp:2.0.6,
then connect to http://localhost:8000/mcp. Details in the docs below.
Related MCP server: Portfolio Research MCP Server
Install guides, tool reference, privacy policy, and data-source limits: https://nomina-xyz.github.io/nomina-mcp/ — see especially Data sources and limits.
Full policy: https://nomina-xyz.github.io/nomina-mcp/privacy/ · Terms of use: https://nomina-xyz.github.io/nomina-mcp/terms/
Collection: when a tool runs, only its inputs — search terms, symbols, tickers, and the
requested period or date window — are sent to the public sources that answer it: Ethereum
JSON-RPC gateways (ethereum.publicnode.com, rpc.mevblocker.io) and Chainlink's feed
directory, home.treasury.gov, api.bls.gov, www.sec.gov/data.sec.gov, and
api.gdeltproject.org. Nothing else leaves the process.
Usage and storage: Nomina stores nothing. No accounts, no logs of requests or their contents, no telemetry. Source responses are held in memory (ten minutes for headlines up to a day for catalogs; immutable on-chain rounds for the process lifetime) to avoid repeat requests; nothing is written to disk.
Third parties: each source processes those requests under its own policy. Your MCP host handles the conversation under its own policy. Operators of a hosted instance may keep infrastructure connection logs; Nomina adds none.
Retention: none beyond the in-memory cache of the running process.
Requires uv.
uv sync
uv run python scripts/build_bundle.py # writes dist/Nomina.mcpb
uv run pytest -q # 12 tests
uv run ruff check .Code in this repository is MIT-licensed (see LICENSE).
Latest reported financials and filings for a US-listed SEC registrant, from EDGAR XBRL.
Example: AAPL, NVDA, TSLA. Returns latest annual (10-K) and quarterly (10-Q) revenue, net
income, operating income, diluted EPS, assets, liabilities, equity, cash and operating cash
flow with period dates, plus recent filing links. No prices, estimates or valuations.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety and side effects. The description adds valuable behavioral detail: the specific data fields returned (revenue, net income, EPS, etc.), the period types (10-K/10-Q), and the source (EDGAR XBRL). It also discloses the limitation 'No prices, estimates or valuations,' which extends transparency without contradicting the annotations.
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 three sentences with no filler. The first sentence immediately states the core purpose, the second enumerates the returned data, and the third states limitations. Every sentence earns its place, and the structure is front-loaded with the most important 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?
For a single-parameter tool with an output schema present, the description is complete. It lists the key financial figures returned, the filing types, and the limitation on other data types. An agent can decide when to use this tool and what to expect without needing any additional information.
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 provides no description for the sole parameter 'ticker' (0% coverage), so the description must compensate. It does so by giving concrete examples (AAPL, NVDA, TSLA) and the context 'US-listed SEC registrant,' which makes the expected input unambiguous. While it doesn't explicitly define 'ticker' as a stock symbol, the examples and pattern in the schema suffice for an agent to infer the meaning.
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 opens with a clear, specific statement: 'Latest reported financials and filings for a US-listed SEC registrant, from EDGAR XBRL.' This defines the verb (returns), resource (financials/filings), and scope (US-listed SEC registrant). The mention of 'No prices, estimates or valuations' further distinguishes it from market-data tools like search_markets or market_overview, so it is clearly differentiated from 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 description provides clear context for when to use this tool: it returns fundamentals (10-K/10-Q data) and explicitly states what it does NOT return (prices, estimates, valuations). This implies that for price-related queries one should use another tool, but it does not explicitly name sibling alternatives, so the guidance is strong but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare 2–6 symbols over shared observation dates, each in its own unit.
Example: ['BTC/USD', 'ETH/USD', 'SPY/USD'] or ['US2Y', 'US10Y']. Prices compare in percent,
yields in percentage points; mixed selections are flagged as not directly comparable.
Give start and end (YYYY-MM-DD) for an exact window instead of period.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | ISO date, inclusive; requires start. | |
| start | No | ISO date, inclusive; requires end. | |
| period | No | 3mo | |
| symbols | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds useful behavioral detail beyond that: shared observation dates, per-unit comparison, percent vs percentage-point treatment, and a warning flag for mixed selections.
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 short sentences plus a compact example list carry the full meaning. Every sentence adds value, and the key scope is front-loaded before the examples and unit caveat.
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 read-only comparison tool with an output schema, the description covers the essential calling decisions: symbol count, date mode, unit handling, and mixed-selection behavior. It could be more explicit about the relationship between period and start/end when both are provided, but the schema covers the mutual requirement.
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 only 50%; start and end have descriptions, while period and symbols rely on their enum/pattern constraints. The description compensates partly by giving symbol examples and explaining the start/end exact-window mode, but it does not fully define all parameter semantics.
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 a specific verb ('Compare') and resource ('assets'), with a clear scope of 2–6 symbols over shared observation dates. It is unambiguous on its own, though it does not explicitly name sibling tools or differentiate from them.
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 implied: this is the tool for multi-symbol comparison, and the examples reinforce that. However, there is no explicit guidance on when to choose this over alternatives such as research_asset or market_overview, and no stated exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Snapshot of BTC, ETH, SOL, gold, SPY, QQQ, EUR/USD, US 2y/10y yields and CPI with period changes.
Read-only; not a recommendation.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | 1mo |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds 'Read-only; not a recommendation', which reinforces the read-only nature and adds a disclaimer about non-advice, but it does not disclose additional behavioral traits such as how the period parameter affects the data or whether any state changes occur (which are already covered by annotations). The added value beyond annotations is modest.
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 two sentences and front-loads the core content (asset list and period changes) before the disclaimer. It is concise with no fluff. The only minor improvement would be to separate the disclaimer more clearly, but overall it is efficient 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 lists the covered assets and metrics, giving an idea of what the snapshot includes. However, it does not explain how the period parameter affects the output (e.g., whether it shows performance over that period or just current values), nor does it specify the format of the snapshot. Since the tool has an output schema (as indicated by context signals), the return format may be inferred, but the description still lacks clarity on the period's role. This leaves a notable gap for an agent to correctly interpret the tool's behavior.
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%, meaning the description carries the full burden of explaining the 'period' parameter. The description only says 'with period changes' without specifying what the period does, how it influences the snapshot, or mapping to the enum values (1mo, 3mo, etc.). The enum values are self-explanatory to a degree, but the description fails to clarify that the period likely selects the time range for the snapshot, leaving ambiguity.
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 a snapshot of a specific list of assets and metrics (BTC, ETH, SOL, gold, SPY, QQQ, EUR/USD, US 2y/10y yields, CPI) and mentions period changes. This distinguishes it from sibling tools like search_markets or research_asset, which are more specific. The verb 'Snapshot' and resource list make the purpose 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 provides no guidance on when to use this tool versus its siblings (search_markets, research_asset, etc.). It does not mention conditions, alternatives, or exclusions. An agent cannot tell whether this should be used for a broad market overview versus a targeted search or deep research from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Research one symbol: latest value, period change, drawdown/volatility, dated history, headlines.
Symbols: on-chain feeds like BTC/USD, ETH/USD, SPY/USD, EUR/USD, XAU/USD (BTC, btc-usd,
BTCUSD also work); Treasury yields US1M..US30Y (e.g. US10Y); macro CPI, UNRATE, PAYEMS,
AHE. Daily observations, weekly beyond two years, monthly for macro series. Give start and
end (YYYY-MM-DD) for an exact window instead of period.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | ISO date, inclusive; requires start. | |
| start | No | ISO date, inclusive; requires end. | |
| period | No | 3mo | |
| symbol | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: data frequency changes by horizon, symbol aliases are accepted, and start/end require each other. It doesn't mention pagination or rate limits, but for a read-only research tool with rich annotations, this is strong.
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: the first sentence states the tool's purpose and outputs, the second covers symbol formats, and the third covers data frequency and window usage. Every sentence earns its place; no filler or repetition of schema fields.
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 read-only research tool with an output schema, the description covers the essential invocation details: what data comes back, which symbols are valid, how frequency changes, and how to request a custom window. The output schema handles return-value documentation, and annotations handle safety. Nothing critical is missing for an agent to call this correctly.
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 50%: symbol has no description in the schema, while start/end/period have basic descriptions. The description compensates by explaining symbol formats and aliases, period semantics (daily/weekly/monthly), and the start/end window behavior. It doesn't detail every enum value, but the enum is self-documenting and the description clarifies the key ambiguity around date windows.
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 opens with a specific verb ('Research') and resource ('one symbol'), then enumerates the exact data points returned: latest value, period change, drawdown/volatility, dated history, headlines. It also lists supported symbol families (on-chain feeds, Treasury yields, macro series), which distinguishes it from siblings like search_markets or compare_assets. This is a clear, specific statement of what the tool does.
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 explicit usage context: it handles one symbol at a time, lists accepted symbol formats and aliases, explains data frequency (daily, weekly beyond two years, monthly for macro), and tells the agent to provide start/end for an exact window instead of period. This effectively routes the agent away from siblings like compare_assets (multi-asset) and search_markets (discovery).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find symbols in Nomina's catalog and recent headlines for an asset, company or topic.
Catalog: Chainlink on-chain feeds (crypto, FX, gold, SPY/QQQ/NVDA/TSLA), Treasury tenors
(US2Y, US10Y), BLS macro series (CPI, UNRATE), SEC registrants (for company_fundamentals).
Examples: 'bitcoin', 'gold', 'nvidia', 'inflation'. Returns headlines, not article text.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum instruments per source and headlines. | |
| query | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: the return type is 'headlines, not article text,' the catalog scope is enumerated, and 'recent' signals time-bounded results. This is more behavioral detail than typical read-only search tools provide.
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 four tight sentences, front-loaded with the core action, then a compact catalog list, then examples, then a boundary statement on return type. Every sentence adds distinct value and there is no filler or repetition of annotation or schema content.
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 modest complexity (2 params, 1 required), a rich output schema, and annotations covering safety/idempotency, the description is complete enough. It states purpose, scope, acceptable query examples, the return boundary (headlines not article text), and even hints at linkage to company_fundamentals. An agent can confidently invoke this tool without needing additional detail.
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 50%: the limit parameter is fully described in the schema, but query has no schema description. The description compensates by listing concrete example queries ('bitcoin', 'gold', 'nvidia', 'inflation') and the acceptable catalog domains, which materially clarifies what can go into the query parameter. It does not need to restate limit semantics, as the schema already covers that.
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 leads with a specific verb+resource: 'Find symbols in Nomina's catalog and recent headlines for an asset, company or topic.' It enumerates the catalog contents and example queries, making it clear this is a search/discovery tool. It implicitly differentiates from siblings like research_asset and company_fundamentals by framing results as catalog matches plus headlines, not analysis or fundamentals data.
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 context for when to use this tool: when you need symbols or recent headlines for a covered asset/company/topic. The parenthetical 'for company_fundamentals' explicitly connects search results to one sibling tool. However, it does not name alternatives like research_asset or market_overview or state when not to use them, so it falls short of fully explicit routing.
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.
v2.0.6company_fundamentalscompare_assets1 field changedInput schema / properties / symbols / items / patternPrevious value: -"^[A-Za-z0-9^=._-]+$"New value: +"^[A-Za-z0-9/:._-]+$"research_asset1 field changedInput schema / properties / symbol / patternPrevious value: -"^[A-Za-z0-9^=._-]+$"New value: +"^[A-Za-z0-9/:._-]+$"search_markets1 field changedInput schema / properties / limit / descriptionPrevious value: -"Maximum symbols and headlines each."New value: +"Maximum instruments per source and headlines."v1.3.0compare_assets2 fields changedInput schema / properties / endAdded value: +{
+ "anyOf": [
+ {
+ "format": "date",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "ISO date, inclusive; requires start.",
+ "title": "End"
+}Input schema / properties / startAdded value: +{
+ "anyOf": [
+ {
+ "format": "date",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "ISO date, inclusive; requires end.",
+ "title": "Start"
+}market_overviewresearch_asset2 fields changedInput schema / properties / endAdded value: +{
+ "anyOf": [
+ {
+ "format": "date",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "ISO date, inclusive; requires start.",
+ "title": "End"
+}Input schema / properties / startAdded value: +{
+ "anyOf": [
+ {
+ "format": "date",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "ISO date, inclusive; requires end.",
+ "title": "Start"
+}v1.0.0compare_assetsresearch_assetsearch_marketsScored across 5 tools
Each tool has a broadly distinct role: discovery, single-asset research, comparison, predefined overview, and fundamentals. There is minor overlap (search_markets and research_asset both return headlines; research_asset and market_overview both give period changes), but the descriptions are clear enough to guide selection.
The first three tools follow a verb_noun pattern (search_markets, research_asset, compare_assets), while the last two are noun phrases (market_overview, company_fundamentals). All names use snake_case and are readable, but the mixed verb/noun convention prevents a higher score.
Five tools is well-scoped for a financial research server. Each tool covers a distinct major workflow without redundancy or bloat.
The surface covers the core research lifecycle: discover symbols, research a single asset, compare multiple assets, get a market snapshot, and retrieve company fundamentals. Stated exclusions like full article text and valuations are explicit, so there are no obvious dead ends.
Stock market data for AI agents: real-time quotes, financials, options, SEC filings and news.
Licensed, cited financial data for AI agents: news, filings, transcripts, research and tearsheets.
Live market data, financial analysis, and portfolio research tools across 10,000+ tickers.
Real-time financial news for AI agents: search by ticker and source, with sentiment and entities.
