This server lets MCP-capable AI assistants browse, read, and search structured daily AI news from AI Daily Insights without HTML scraping.
Get the latest issue with all its structured news items in one call (get_latest).
List recent issues with date, title, summary, tags, and URLs (list_latest).
Fetch a specific issue by date, with news items parsed into index, title, signal, and body (get_article).
Retrieve every issue in an inclusive date range, fetched in parallel (get_range).
List issues by tag (company/topic), matched case-insensitively (list_by_tag).
Search across all news items by keyword, tag, or both, with snippets (search).
All tools validate inputs, return structured data, and need no API key.
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., "@ai-daily-insights-mcp List the latest 5 AI news items"
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.
A Model Context Protocol server for AI Daily Insights — a daily AI briefing built for both humans and agents.
It lets any MCP-capable assistant (Claude Desktop, Claude Code, Cursor, …) list, read and search the daily AI news, fully structured — no HTML scraping.
Each entered tool handler sends a best-effort background event to the configured AI_DAILY_BASE_URL (the public site by default). It contains only the tool name and package version: no arguments, search queries, results, session IDs or user identifiers. The hosting infrastructure still sees standard request metadata. Events include cached calls and errors, but exclude tool discovery and rejected input schemas. They are self-reported usage, not verified AI users.
Set AI_DAILY_ANALYTICS=0 in the MCP server environment to disable these events. Data fetches still use the package/version User-Agent for HTTP attribution. Reporting never waits on the tool response path, has a 1.5-second timeout, at most 16 outstanding events and no retries; offline/shutdown/opt-out may undercount. Existing data caching is unchanged.
Related MCP server: News API MCP Server
Tool | What it does |
| The newest issue with all its news items in one call. |
| List recent issues: date, title, summary, tags, URLs. |
| Fetch one issue ( |
| Every issue in a date range (e.g. the past week), fetched in parallel. |
| Issues carrying a given tag (company/topic), matched case-insensitively. |
| Full-text + tag search across all news items, in one server-side call. |
Data comes from the public JSON endpoints (/index.json, /{date}.json, /search) — the server is stateless and needs no API key. Responses are cached in-memory briefly (default 5 min, override with AI_DAILY_CACHE_TTL_MS) to avoid hammering the site on repeated calls.
claude mcp add ai-daily-insights -- npx -y ai-daily-insights-mcp{
"mcpServers": {
"ai-daily-insights": {
"command": "npx",
"args": ["-y", "ai-daily-insights-mcp"]
}
}
}Then ask: "用 ai-daily-insights 列出最近 5 天的 AI 资讯，挑 SpaceX 相关的讲讲。"
Env var | Default | Purpose |
|
| Override the site origin (e.g. a preview deploy). |
|
| In-memory cache TTL for fetched JSON, in milliseconds. |
npm install
npm test
npm run inspect # opens the MCP InspectorRequires Node.js 20 or newer. Every tool declares explicit MCP safety annotations, validates its inputs with Zod, and converts upstream failures into structured MCP error results.
MIT
Fetch a single daily issue by date, parsed into structured news items: each item has index, title, signal (the one-line judgment) and body. Date format: YYYY-MM-DD.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Issue date, e.g. 2026-06-24. |
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 discloses the output structure (index, title, signal, body) and date format, but does not mention side effects, permissions, or error handling. This is adequate for a simple fetch operation but lacks depth.
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 long, front-loads the key action and output structure, and contains no unnecessary words. Every sentence adds value.
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 simple single-parameter nature and no output schema, the description adequately explains the input format and output structure. It does not cover error cases or mention rate limits, but for a straightforward fetch tool the completeness is good.
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 description coverage is 100%, so baseline is 3. The description adds a redundant date format hint and context about the output, but does not significantly enrich the parameter meaning beyond what the schema already provides with pattern and description.
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 'Fetch' and the resource 'single daily issue by date', and specifies the output as structured news items with fields. It distinguishes from siblings like get_latest and get_range by focusing on a single issue retrieved by date.
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 retrieving a single issue by a specific date, but it does not explicitly discuss when to use this tool versus alternatives like get_latest or search. The context is clear but lacks explicit guidance on exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the most recent issue, parsed into structured news items {index, title, signal, body}. Use this when the user asks for today's / the latest AI news and does not give a date.
| 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 bears full burden. It discloses the return format (index, title, signal, body) and that it fetches data. For a read-only tool with no parameters, this is sufficiently transparent.
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—two sentences with no filler. The first sentence clearly states the action and output, the second clarifies the usage context. Every sentence 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?
Given no output schema, the description explains the return fields. It also specifies the triggering condition. Minor ambiguity: 'structured news items' might imply multiple items, but the number is not specified. Overall, it covers the essential details.
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, and schema coverage is 100%. The description adds no parameter information, which is appropriate. Baseline for no 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 the tool fetches the most recent issue and returns structured news items. It distinguishes from siblings by specifying the use case for when no date is given, but does not explicitly compare to 'list_latest' or 'get_article'.
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 guidance on when to use ('when the user asks for today's / the latest AI news and does not give a date'), implying when not to use. It does not name alternative tools 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.
Fetch every issue whose date falls within [from, to] (inclusive), each parsed into structured news items. Use for "the past week", "between X and Y", etc. Dates are YYYY-MM-DD. Issues are fetched in parallel.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | End date (inclusive), e.g. 2026-06-30. | |
| from | Yes | Start date (inclusive), e.g. 2026-06-24. | |
| limit | No | Max issues to return (default 14). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions inclusive range, date format, parallel fetching, and structured output. Adequate for a read-only tool.
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 sentences, no waste. First sentence covers action, second examples, third format and behavior. Front-loaded and efficient.
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?
Tool is simple; description covers purpose, usage, date format, parallelism. Lacks detail on output structure, but not critical. Good for the given complexity.
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 descriptions. Description adds date format (redundant with pattern) and parallel fetching (not parameter-specific). Base score 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 tool fetches every issue in an inclusive date range, parsed into structured items. It is distinct from siblings like get_latest (single latest) and list_by_tag (tag filter).
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?
Description gives concrete examples ('the past week', 'between X and Y'). Does not explicitly exclude other tools, but context from sibling names implies appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List issues that carry a given tag (e.g. a company or topic like "OpenAI", "融资", "芯片"). Returns issue-level entries; use search() to find specific news items by keyword.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | Yes | Tag to filter by, matched case-insensitively. | |
| limit | No | Max issues to return (default 10). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses that tool returns issue-level entries and tag matching is case-insensitive. Lacks details on pagination or sorting, but adequate for a read-only filter.
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?
Extremely concise: two sentences, front-loaded with purpose, no redundant information. Every sentence adds value.
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 simple tool (2 params, no output schema, no annotations), description covers core purpose, usage comparison, and output type. Could mention ordering or empty results, but mostly 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 covers 100% of parameters with descriptions. Description adds value by providing concrete examples (e.g., 'OpenAI') and clarifying output level (issue-level vs news items).
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 verb 'list' and resource 'issues', specifies filtering by tag, and explicitly distinguishes from sibling tool search() by noting to use search() for specific news items.
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?
Provides explicit context: when to use (list issues by tag) and when not to (use search() for keyword news items). Offers alternatives and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the most recent AI Daily Insights issues (date, title, one-line summary, tags, URLs). Start here to discover what is available.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many recent issues to return (default 5). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It lists returned fields (date, title, etc.) but omits ordering (e.g., most recent first) and whether more pages exist. Adequate but not comprehensive.
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 efficiently communicates purpose, return fields, and primary use case. No redundant information; every word earns its place.
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 simple list tool with one optional param and no output schema, the description covers return fields and purpose adequately. Lacks explicit mention of sorting order or pagination, but generally 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 already fully describes the 'limit' parameter with default, min, max. Description adds no additional semantics beyond what schema provides, meeting the baseline for high schema coverage.
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 the verb 'List' and the resource 'most recent AI Daily Insights issues' with specific fields. It distinguishes from siblings by indicating it's a starting point for discovery.
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?
Explicitly suggests 'Start here to discover what is available,' providing clear usage context. However, it does not mention when not to use or compare to sibling tools like 'get_latest' or 'search'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text + tag search across all news items. Provide a keyword query, a tag, or both. Returns matching items with date, title, signal and a short snippet. Backed by the site search endpoint (one call); falls back to the flat index if unavailable.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Restrict to items whose issue carries this tag. Optional. | |
| limit | No | Max matching items (default 10). | |
| query | No | Keyword or phrase. Optional if tag is given. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It reveals that the tool returns matching items with specific fields, uses a primary endpoint with a fallback, and is essentially a read operation. Missing explicit statement about read-only nature, but sufficiently transparent.
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 sentences, concise and informative. First sentence states purpose and parameter options. Second sentence describes output. Third sentence provides implementation detail. No redundancy or fluff.
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 covers key aspects: what it searches, how parameters work, what is returned, and backend behavior. Could mention ordering, but overall sufficiently complete for an agent to use 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 coverage is 100% with descriptions for each param. The description adds value by explaining that query and tag can be used individually or together, and that limit controls max items. This goes beyond the schema's individual param descriptions.
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 'Full-text + tag search across all news items' and specifies return fields (date, title, signal, snippet). Distinguishes itself from sibling tools like get_article or list_by_tag by focusing on combined full-text and tag search.
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?
Description explains that query, tag, or both can be provided, and mentions fallback behavior ('backed by site search endpoint... falls back to flat index'). However, it does not explicitly contrast with sibling tools or list when not to use this tool.
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.
v0.4.0get_articleget_latestget_rangelist_by_taglist_latestsearchScored across 6 tools
Each tool has a distinct purpose: fetching by date, latest, range, listing by tag, listing latest issues, and full-text search. There is minor overlap between list_latest and get_latest, and between list_by_tag and search, but descriptions clarify the differences (issue-level vs. item-level).
All names use lowercase snake_case and follow a verb-based structure. However, the pattern is mixed: get_article, get_latest, get_range are consistent; list_by_tag and list_latest use 'list', and search is a bare verb. This is minor inconsistency overall.
With 6 tools, the count is well-scoped for a news retrieval service. Each tool covers a specific access pattern (by date, latest, range, tag, list, search), and none feel redundant or out of place.
The tool surface covers the main ways to retrieve articles: by date, latest, range, tag listing, and full-text search. A notable gap is the lack of a tool to list all available tags, which would assist in using list_by_tag and search effectively.
Real-time curated crypto news for AI agents with sentiment, recaps, and search.
Your curated sources (RSS, YouTube, podcasts, Google News) as context for any AI agent. 26 tools.
Real-time financial news for AI agents: search by ticker and source, with sentiment and entities.
One call instead of crawling 29 news/finance/AI sources mid-task. 100 free queries/day.
