This server gives AI agents real-time financial news search, enrichment, and source discovery through MCP tools.
search_articles: Search financial news with boolean queries and filters for tickers, sources, countries, categories, language, and date ranges; returns sentiment scores, confidence, and optional full content and tagged company entities.
get_article_by_link: Retrieve a specific article by URL to get full metadata, sentiment analysis, and optional content and entity enrichment.
list_sources: List available news sources with metadata like default status and content availability, useful for targeting or expanding coverage.
Works with Claude, Cursor, ChatGPT, and other MCP clients via remote HTTP or local stdio, with OAuth 2.0 or API-key authentication.
mcp-name: me.finlight/news
Real-time financial news for AI agents. Connect Claude, ChatGPT, Cursor, or any MCP client to finlight, a financial news API covering global markets, geopolitics, and company-level news with sentiment analysis and entity tagging.
Endpoint: https://mcp.finlight.me (remote, streamable HTTP)
Auth: OAuth 2.0 (you'll be prompted for your finlight API key during connection)
Registry: me.finlight/news
Ask your AI assistant things like:
"What's the latest news on NVDA? Summarize sentiment."
"Any market-moving headlines in the last 2 hours?"
"Compare news coverage of the Fed decision across sources."
"Find recent articles about semiconductor export restrictions and list the companies mentioned."
"Which sources does finlight cover for Chinese market news?"
Related MCP server: BrunoSan AI News MCP Server
Tool | Description |
| Search financial news articles with filters for query, tickers, sources, countries, language, and date range. Returns articles with metadata, sentiment scores, and tagged company entities. |
| Retrieve a specific article by its URL, including full enrichment (sentiment, confidence, tagged companies with tickers and ISINs). |
| List all available news sources with country of origin and content availability. |
You need a finlight API key. Sign up at app.finlight.me — the free tier is enough to try every tool below.
Go to Settings → Connectors → Add custom connector
Enter https://mcp.finlight.me
Complete the OAuth flow: you'll be asked to paste your finlight API key once
claude mcp add --transport http finlight https://mcp.finlight.meAdd to your MCP settings (.cursor/mcp.json):
{
"mcpServers": {
"finlight": {
"url": "https://mcp.finlight.me"
}
}
}Add https://mcp.finlight.me as a remote MCP server and complete the OAuth flow with your API key.
For MCP clients that only support stdio transport (or if you prefer a locally spawned process), use the npm wrapper:
npx finlight-mcpThis bridges stdio to the remote server via mcp-remote. Add it to any client config that takes a command + args:
{
"mcpServers": {
"finlight": {
"command": "npx",
"args": ["-y", "finlight-mcp"]
}
}
}The OAuth flow is the same — a browser window will open for you to enter your API key on first use.
For headless or CI environments where no browser is available, set FINLIGHT_API_KEY to skip OAuth and authenticate directly:
{
"mcpServers": {
"finlight": {
"command": "npx",
"args": ["-y", "finlight-mcp"],
"env": {
"FINLIGHT_API_KEY": "your-api-key"
}
}
}
}The server supports two authentication methods:
OAuth 2.0 (default): Dynamic client registration with PKCE. A browser window opens for you to enter your finlight API key. Works out of the box with any MCP client that speaks OAuth.
API key via header: Set the FINLIGHT_API_KEY environment variable to skip the browser flow. The key is sent as a Bearer token directly.
finlight aggregates and enriches financial news from curated, finance-relevant sources including major wire services, financial publishers, and regional sources in Chinese, Japanese, Korean and Arabic (with English canonical entity tagging). Articles include:
Sentiment score with confidence
Tagged company entities with tickers, ISINs, and exchange listings
Source, language, country, and publish metadata
The MCP server uses the same data as the REST and WebSocket APIs.
MCP requests count toward your API quota. See pricing for the current free-tier limit and for paid tiers with real-time access, higher limits, and additional features.
Website: finlight.me
MCP landing page: finlight.me/mcp
API docs: docs.finlight.me
Discord: discord.gg/XUs9JYZd24
Support: support via app.finlight.me or Discord
Issues and feature requests for the MCP server are welcome here on GitHub. For API questions, use Discord or the support channels above.
Retrieve a specific financial news article by its URL from the Finlight database.
Use this when you have an article URL and want to get its full details including:
Title, summary, and publication date
Source domain and language
Sentiment analysis (positive/negative/neutral) with confidence score
Optionally: full article content and tagged company entities
This is useful for getting details about a specific article you found elsewhere or for enriching article data with sentiment and entity information.
| Name | Required | Description | Default |
|---|---|---|---|
| link | Yes | The full URL of the article to retrieve. Example: "https://www.reuters.com/technology/nvidia-reports-record-revenue-2024" | |
| includeContent | No | Include the full article text content. Requires a subscription plan with content access. Default: false | |
| includeEntities | No | Include tagged company entities with ticker symbols, exchange info, sector/industry classification, ISIN codes, and OpenFIGI identifiers. Requires subscription. Default: false |
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 lists the returned data (title, summary, date, source, language, sentiment, optional content/entities), which gives a solid picture of behavior. It does not mention error cases or rate limits, but for a simple retrieval 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 well-structured with a clear purpose statement, a usage context paragraph, and a bulleted list of return fields. There is slight redundancy between 'Use this when' and 'This is useful for', but overall it is efficient and readable.
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 3-parameter tool with full schema coverage and no output schema, the description explains the purpose, use case, and expected return fields well. It could mention subscription requirements in the body (covered in schema), but it is otherwise 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 description coverage is 100%, with detailed descriptions for link, includeContent, and includeEntities. The description's mention of optional content/entities adds little beyond the schema, so it meets the high-coverage baseline.
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 'Retrieve a specific financial news article by its URL from the Finlight database,' which clearly identifies the verb and resource. It distinguishes from siblings by specifying 'Use this when you have an article URL,' implying search_articles/list_sources are for different needs.
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 explicit when-to-use guidance: 'Use this when you have an article URL' and 'This is useful for getting details about a specific article you found elsewhere.' It does not explicitly name the alternative tools or give a when-not-to-use scenario, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of all available news sources.
Returns metadata for each source including:
domain: The source website domain (e.g., "www.reuters.com")
isDefaultSource: Whether this source is included by default in search results
isContentAvailable: Whether full article content can be retrieved for this source (requires subscription)
Use this to discover available sources before filtering with the search_articles tool. Default sources are high-quality financial news outlets included automatically. Non-default sources can be added using the optInSources parameter in search_articles.
| 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 the full burden. It discloses the return metadata fields, notes that isContentAvailable requires subscription, and explains default vs non-default sources. This provides meaningful behavioral context beyond just 'list sources', though it omits minor details like pagination or authentication.
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 concise, front-loaded with the main purpose, and uses bullet points for clarity. Every sentence adds value, and it avoids redundancy with the schema or the tool name.
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 low complexity (no params, no output schema), the description fully covers what the tool returns (domain, isDefaultSource, isContentAvailable), how to use it, and its relationship to sibling tools. It is complete for its scope.
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 tool has zero parameters, so schema coverage is 100% (empty schema). The description adds semantic context about how to interpret default sources and their relationship to search_articles, which is valuable beyond the schema.
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 'Get a list of all available news sources' with a specific verb and resource. It also distinguishes itself from sibling tools by positioning as the discovery step before using search_articles, making its 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?
It explicitly says 'Use this to discover available sources before filtering with the search_articles tool' and mentions the optInSources parameter, giving clear context on when and how to use it. It does not explicitly say when not to use it, but the guidance is sufficient for a discovery tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for financial news articles. Returns market-relevant news enriched with sentiment analysis and optional company entity tagging.
Key features:
Advanced query language with boolean operators (AND, OR, NOT) and field filters (ticker:AAPL, source:reuters.com)
Filter by stock tickers, countries, categories, sources, date ranges, and language
Each article includes sentiment analysis (positive/negative/neutral) with confidence scores
Optional full article content and tagged company entities (requires subscription)
Response includes: title, summary, publishDate, source, language, sentiment, confidence, and optionally content and companies array.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | End date for article search. Accepts YYYY-MM-DD format or full ISO 8601 datetime. Example: "2024-12-31" | |
| from | No | Start date for article search. Accepts YYYY-MM-DD format or full ISO 8601 datetime. Example: "2024-01-01" or "2024-01-01T00:00:00Z" | |
| page | No | Page number for pagination. Default: 1. Max offset (page * pageSize) is 10,000. | |
| order | No | Sort order for results. DESC = newest first (default), ASC = oldest first. | |
| query | No | Advanced query string supporting boolean operators and field filters. Examples: "Nvidia earnings", "(ticker:AAPL OR ticker:NVDA) AND NOT source:www.reuters.com", "CEO resignation AND ticker:TSLA" | |
| orderBy | No | Field to sort by. publishDate = when article was published (default), createdAt = when article was indexed. | |
| sources | No | Limit to specific news sources by domain. Overrides the default source set. Example: ["www.reuters.com", "www.bloomberg.com"]. Use list_sources to see all available sources. | |
| tickers | No | Filter articles mentioning specific stock tickers. Example: ["AAPL", "NVDA", "TSLA"]. Articles are tagged with companies using NLP entity recognition. | |
| language | No | Filter by article language code. Default: "en". Other options: "de", "fr", "es", etc. | |
| pageSize | No | Number of articles per page. Range: 1-100. Default: 20 | |
| countries | No | Filter by ISO 3166-1 alpha-2 country codes of tagged companies. Example: ["US", "GB", "DE"] for US, UK, and German companies. | |
| categories | No | Filter by article categories. Available categories: markets, economy, business, politics, geopolitics, regulation, technology, energy, commodities, crypto, health, climate, security. | |
| optInSources | No | Add additional sources to the default source set (instead of replacing it). Useful for including specialty sources. | |
| excludeSources | No | Exclude specific sources from results. Example: ["www.foxbusiness.com"] | |
| includeContent | No | Include full article text content in response. Requires a subscription plan with content access. Default: false | |
| includeEntities | No | Include tagged company entities with details like ticker, exchange, sector, industry, ISIN codes, and OpenFIGI identifiers. Requires subscription. Default: false | |
| excludeEmptyContent | No | Skip articles where content scraping failed or is unavailable. Useful when includeContent is true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well by disclosing subscription requirements for content/entities, describing the response structure, and highlighting key behavioral features like advanced query syntax and default source handling. It does not explicitly state it is read-only, but the term 'search' implies a safe operation.
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 well-structured with a clear opening sentence, a concise 'Key features' bullet list, and a response overview. Every sentence earns its place, providing a strong summary without unnecessary repetition or bloat, especially given the large number of 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?
The description gives a good high-level overview but lacks important details for a tool with zero required parameters—for example, the default behavior when no query is provided, or the default date range. It also does not mention how search results are ordered by default (though schema covers it). Given the complexity and absent output schema, it's adequate but has clear gaps around default behavior and edge cases.
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%, so the baseline is 3. The description adds no significant new meaning beyond the schema; it repeats filter capabilities and mentions subscription requirements, which are already documented in the schema. It adds value in summarizing the query language but does not clarify any parameters beyond what schema descriptions already provide.
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 searches for financial news articles with sentiment analysis and optional entity tagging. It distinguishes itself from sibling tools (get_article_by_link retrieves specific articles, list_sources lists sources) by emphasizing its broad search, filtering, and enrichment capabilities.
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 (searching with filters, sentiment, etc.), though it does not explicitly mention alternatives or exclusion criteria. It implies this is the go-to for article search rather than retrieving by link or listing sources.
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.
v0.1.0get_article_by_linklist_sourcessearch_articlesEach tool has a clearly distinct function: search_articles performs query-based search with advanced filters, get_article_by_link retrieves a specific article by URL, and list_sources provides metadata on available news sources. There is no overlap or ambiguity between them.
All three tools follow the same verb_noun pattern: search_articles, get_article_by_link, list_sources. This is perfectly consistent and predictable, making the tool surface easy to navigate.
Three tools is well-scoped for a financial news article service. Each tool covers a distinct, necessary operation (search, retrieve by URL, list sources) without redundancy or unnecessary bloat.
The tool set covers the full lifecycle of accessing articles: discovering sources, searching/filtering articles, and retrieving full details by URL. There are no obvious missing operations for the stated purpose of financial news lookup with sentiment analysis.
Real-time curated crypto news for AI agents with sentiment, recaps, and search.
Real SEC, 13F, insider, congress & macro data your AI agent can cite. Hosted MCP, 24 tools.
Real-time corroborated news events + 5-year archive, for agents. Free tier, no key.
AI-enriched financial news for AI agents & trading bots: search, trending, insider, scored 1-10.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/callbk/finlight-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
