What can you do with this server?

This MCP server provides multi-language, editorially curated crypto/blockchain/Web3 news with sentiment labels, importance scores, and source attribution. Use its tools to search, browse, and retrieve stories: * search(query, lang?, category?, limit?): Full-text search across the news catalogue, ordered by recency. * get_latest(lang?, category?, limit?): Most recent stories from the past 24 hours. * get_breaking(lang?, limit?): High-importance stories (score ≥ 75) from the past 24 hours — market-moving events. * get_featured(lang?, limit?): Editor-curated highlights with no time window restriction. * get_post(slug_or_id, lang?): Full article content including body, categories, hashtags, and source attribution. * list_categories(lang?): Browse the full 35-category taxonomy to find valid slugs for filtering. Key features across all tools: * 8 supported languages: English, Turkish, Spanish, Russian, Portuguese, French, German, Italian * Sentiment labels: Every story tagged BULLISH, NEUTRAL, or BEARISH * Importance scores: 0–100 scale (≥ 75 = breaking news) * Source attribution: Original publisher name and URL on every item

zipp-mcp

by deficlow

Overview Schema Source Related Servers Discussions Admin

Python

Remote

Zipp MCP

Multi-language crypto news for AI assistants — editorial summaries, sentiment labels (BULLISH / NEUTRAL / BEARISH), importance scores (0–100), and every story credited to its original publisher.

MCP Endpoint MCP Registry Smithery Transport Auth Languages License

This repository hosts the public listing manifest and the zipp-mcp Python package. The canonical Zipp MCP server is hosted at https://zippfeed.com/mcp/ — most clients should connect to that URL directly. The PyPI / Docker package is for the cases where they can't: stdio-only desktop clients, locked-down networks, or anywhere you want a self-contained install.

🌐 Website: zippfeed.com
🔌 MCP endpoint: https://zippfeed.com/mcp/
📡 Transport: Streamable HTTP (MCP spec 2025-06-18)
🔓 Auth: none — public, rate-limited at the Cloudflare edge
📰 Coverage: crypto / blockchain / Web3 across 8 languages
✍️ Editorial: every item carries sentiment + importance + source attribution
📦 PyPI: uvx zipp-mcp · Docker: ghcr.io/deficlow/zipp-mcp (Day 3 follow-up)

Self-host

Three install paths. All three speak the same protocol and call the same upstream API; the right choice depends on the client.

`uvx` — no install, one command

For stdio MCP clients (Claude Desktop, Cursor's stdio mode, Cline, Zed, etc.) that prefer launching a local subprocess:

uvx zipp-mcp

Claude Desktop config (claude_desktop_config.json):

{
  "mcpServers": {
    "zipp": {
      "command": "uvx",
      "args": ["zipp-mcp"]
    }
  }
}

`pip install` — for embedded use

pip install zipp-mcp
zipp-mcp --transport stdio

Or import the client directly in your own code:

from zipp_mcp import ZippClient

async with ZippClient() as zipp:
    payload = await zipp.search(query="bitcoin etf", lang="en-US", limit=5)
    for item in payload["items"]:
        print(item["title"], item["sentiment"], item["importance"])

Docker — for hosted / sandboxed environments

docker run -i --rm ghcr.io/deficlow/zipp-mcp

For Streamable HTTP transport on a server (Railway, Fly, Render):

docker run -p 8080:8080 -e MCP_HOST=0.0.0.0 \
  ghcr.io/deficlow/zipp-mcp \
  zipp-mcp --transport http

Configuration

All flags read from env vars too; everything is optional.

Env var	Default	What it does
`ZIPP_API_BASE`	`https://zippfeed.com`	Upstream Zipp deployment (staging, mirror, etc.)
`ZIPP_API_TIMEOUT_S`	`30`	HTTP client timeout (1–120s)
`MCP_HOST`	`127.0.0.1`	Bind host for HTTP/SSE transports (set `0.0.0.0` in containers)
`MCP_PORT`	`8080`	Bind port; also aliased as `PORT` for Railway/Fly/Render/Heroku

The package is read-only — there is nothing to authenticate; the upstream API is public and rate-limited at the Cloudflare edge.

Related MCP server: crypto-rss-mcp

Why Zipp?

Most news connectors are pure aggregators that hand the model a raw headline list. Zipp adds an editorial layer on top of the firehose:

Signal	What it does
Sentiment	Each story labelled `BULLISH` / `NEUTRAL` / `BEARISH` (editorial, not advice)
Importance	0–100 score; `≥ 75` is the breaking threshold
Multi-language	8 languages, native-quality summaries (not auto-translate)
Attribution	Original publisher name + URL on every item, always
Taxonomy	7 categories × 5 sub-leaves = 35 leaves, stable slugs

Quick start

Zipp speaks Streamable HTTP at https://zippfeed.com/mcp/ — no auth, no install. Below are copy-paste configs for the major MCP-capable clients, plus two ways to smoke-test the endpoint.

Claude Desktop

Add to your claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/claude_desktop_config.json):

{
  "mcpServers": {
    "zipp": {
      "type": "http",
      "url": "https://zippfeed.com/mcp/"
    }
  }
}

Restart Claude Desktop. You should see Zipp in the tool list and be able to ask things like "What's breaking in crypto right now?" or "Search Zipp for Bitcoin ETF inflows in Turkish."

Claude Code (CLI)

One-liner — registers Zipp at user scope so every project sees it:

claude mcp add --scope user --transport http zipp https://zippfeed.com/mcp/

Verify with claude mcp list.

Claude.ai web (Connectors)

Settings → Connectors → Add custom connector → URL: https://zippfeed.com/mcp/ → no authentication.

ChatGPT (Custom Connectors)

Settings → Connectors → Add → Custom connector → URL: https://zippfeed.com/mcp/ → Authentication: None.

Cursor

~/.cursor/mcp.json:

{
  "mcpServers": {
    "zipp": {
      "url": "https://zippfeed.com/mcp/"
    }
  }
}

Windsurf

~/.codeium/windsurf/mcp_config.json:

{
  "mcpServers": {
    "zipp": {
      "serverUrl": "https://zippfeed.com/mcp/"
    }
  }
}

Cline (VS Code extension)

Open the Cline panel → MCP Servers → Edit Configuration, then add Zipp to cline_mcp_settings.json:

{
  "mcpServers": {
    "zipp": {
      "url": "https://zippfeed.com/mcp/",
      "type": "streamableHttp"
    }
  }
}

Zed

~/.config/zed/settings.json — Zed's context_servers interface is stdio-only today, so use the mcp-remote bridge:

{
  "context_servers": {
    "zipp": {
      "command": {
        "path": "npx",
        "args": ["-y", "mcp-remote", "https://zippfeed.com/mcp/"]
      }
    }
  }
}

Gemini CLI

~/.gemini/settings.json:

{
  "mcpServers": {
    "zipp": {
      "httpUrl": "https://zippfeed.com/mcp/"
    }
  }
}

OpenAI Responses API

from openai import OpenAI

client = OpenAI()
resp = client.responses.create(
    model="gpt-5",
    tools=[{
        "type": "mcp",
        "server_label": "zipp",
        "server_url": "https://zippfeed.com/mcp/",
        "require_approval": "never",
    }],
    input="What's breaking in crypto right now? Cite the original publisher.",
)
print(resp.output_text)

Anthropic Messages API

The MCP connector is a beta — pass the header below until it goes GA:

import anthropic

client = anthropic.Anthropic()
msg = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=1024,
    mcp_servers=[{
        "type": "url",
        "url": "https://zippfeed.com/mcp/",
        "name": "zipp",
    }],
    messages=[{"role": "user", "content": "What's breaking in crypto right now?"}],
    extra_headers={"anthropic-beta": "mcp-client-2025-04-04"},
)
print(msg.content)

Smoke test

Verify the server from your shell — no client needed:

curl -s -X POST "https://zippfeed.com/mcp/" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"smoke","version":"1.0"}}}'

Expected: a JSON-RPC initialize result where serverInfo.name = "Zipp" and the server advertises tools, resources, and prompts capabilities.

For an interactive UI, run the official MCP Inspector:

npx @modelcontextprotocol/inspector

In the browser tab that opens, pick Streamable HTTP as the transport, paste https://zippfeed.com/mcp/, click Connect, then browse the Tools / Resources / Prompts tabs to exercise the server end-to-end.

Tools

Tool	Signature	What it returns
`search`	`(query, lang?, category?, limit?)`	Full-text search, recency-first
`get_latest`	`(lang?, category?, limit?)`	Stories from the last 24 hours
`get_breaking`	`(lang?, limit?)`	Importance ≥ 75 within the last 24 hours
`get_featured`	`(lang?, limit?)`	Editor-curated highlights
`get_post`	`(slug_or_id, lang?)`	Full post body + all categories + hashtags
`list_categories`	`(lang?)`	The 7 × 5 taxonomy (35 leaves)

lang defaults to en-US. See Languages below for the full list.

Sample response

get_latest(lang="en-US", limit=1) returns shape:

{
  "items": [
    {
      "id": 1234,
      "slug": "bitcoin-etf-inflows-500m",
      "url": "https://zippfeed.com/en-US/a/bitcoin-etf-inflows-500m",
      "title": "Bitcoin ETF inflows hit $500M",
      "summary": "Spot Bitcoin ETFs absorbed $500M in net inflows…",
      "category": "markets-etfs",
      "sentiment": "BULLISH",
      "importance": 82,
      "published_at": "2026-05-13T15:08:55Z",
      "language": "en-US",
      "tags": ["markets-etfs", "btc", "etf"],
      "source": {
        "name": "CoinDesk",
        "url": "https://www.coindesk.com/..."
      },
      "image_url": "https://cdn.zippfeed.com/images/rss/abc.jpg"
    }
  ]
}

get_post additionally returns the full body, hashtags, and an expanded categories[] array.

Languages

Code	Language
`en-US`	English
`tr-TR`	Türkçe
`es-ES`	Español
`ru-RU`	Русский
`pt-PT`	Português
`fr-FR`	Français
`de-DE`	Deutsch
`it-IT`	Italiano

Every story is editorially summarised in every supported language; sentiment and importance scoring are computed once and shared across language variants.

Attribution policy

Every Zipp story carries the original publisher in the source field. When you surface Zipp content in an AI response, please credit both Zipp and the original publisher, e.g.:

via Zipp — original: CoinDesk

Linking to the original source.url is encouraged. Zipp's own canonical URL (item.url) is the right link when pointing to the editorial summary.

Editorial methodology

Zipp's editorial process — feed selection, AI-assisted summarisation, sentiment + importance scoring, human review — is documented at zippfeed.com/en-US/p/methodology.

Sentiment is editorial labelling, not investment advice.

Zipp is published to the official MCP Server Registry as com.zippfeed/zipp — directories that aggregate the registry (Smithery, Glama, mcp.so, PulseMCP, etc.) pick it up automatically.

If you're building tooling around Zipp, the following endpoints are also public:

/llms.txt — AI-discoverable URL map
/sitemap.xml, /news_sitemap.xml, /image_sitemap.xml
/rss.xml + /feed.json (per-language + per-category + per-slice variants)

The standalone developer REST API was retired on 2026-05-14 — GET /developer/v1/* now returns 410 Gone with a pointer to the MCP endpoint. AI-agent integrations should use MCP; long-form content readers should use the RSS or JSON Feed surfaces above.

Legal

Methodology
Privacy
Terms
Contact: hello@zippfeed.com

License

This repository — README, manifest, and the example client — is released under the MIT License. It covers the public documentation and listing manifest only; the MCP server implementation itself is proprietary and hosted by Zipp.

Available Tools

6 tools

get_breakingAInspect

Breaking news only — last 24 hours, importance score >= 75. Lower volume than get_latest but every item is market-moving by Zipp's editorial threshold.

ParametersJSON Schema

Name	Required	Description	Default
`lang`	No		en-US
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations, the description discloses selection criteria (24h, importance threshold) and editorial threshold (Zipp's). It does not mention rate limits or authentication, but as a read operation, 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.

Conciseness5/5

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

Two sentences, front-loaded with the key purpose and differentiation, no wasted words.

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?

Output schema exists, so return values are covered. Description adequately explains what is returned, but missing parameter details slightly reduces completeness for parameter usage.

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

Parameters1/5

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

Schema coverage is 0% and the description does not mention the two parameters (lang, limit), leaving the agent to infer their meaning from names alone.

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?

Clearly states it returns breaking news from last 24 hours with importance score >= 75, and distinguishes itself from get_latest.

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

Usage Guidelines4/5

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

Provides clear context for when to use this tool vs get_latest (lower volume, market-moving items), but does not explicitly exclude other siblings like get_featured or search.

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

get_featuredAInspect

Editor-picked feature stories (is_featured=TRUE). No time window. Use when the user wants curated highlights rather than the firehose.

ParametersJSON Schema

Name	Required	Description	Default
`lang`	No		en-US
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior3/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. It mentions 'no time window' and 'editor-picked', but does not explicitly state that it is read-only or disclose other behavioral traits like rate limits. However, the name and context imply a safe read operation.

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 only two sentences, front-loading the key purpose and usage condition. Every sentence adds value with no unnecessary words.

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?

Given no annotations and 0% schema coverage, the description is short but covers purpose and usage. However, it misses parameter explanations and additional behavioral context, making it somewhat incomplete for an agent to fully understand invocation.

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

Parameters2/5

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

Schema description coverage is 0%, and the description does not explain the parameters (lang, limit). Basic parameters like lang and limit are not described, leaving the agent to infer their meaning from the names and defaults.

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?

The description clearly states the tool returns 'Editor-picked feature stories' with a condition 'is_featured=TRUE', and distinguishes it from other tools like get_breaking and get_latest by mentioning 'curated highlights rather than the firehose'.

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

Usage Guidelines5/5

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

Explicitly says 'Use when the user wants curated highlights rather than the firehose', providing clear context for when to choose this tool over siblings.

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

get_latestAInspect

Latest news from the last 24 hours. Optionally scoped to a category. Returns posts ordered newest-first. Use for 'what's new today?' or 'what happened in DeFi today?'.

ParametersJSON Schema

Name	Required	Default
`lang`	No	en-US
`category`	No
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.8/5.0

Behavior3/5

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

No annotations provided, so the description must carry behavioral info. It mentions temporal scope (24 hours) and ordering (newest-first), but omits details like authorization, rate limits, or caching behavior.

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?

Three concise sentences, front-loaded with core purpose, no redundancy or waste.

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?

Output schema exists, but the description lacks parameter explanations and usage guidelines for alternatives, making it somewhat incomplete for a tool with 3 parameters and 0% schema coverage.

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

Parameters2/5

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

Schema description coverage is 0%, so the description needs to compensate. It explains the category parameter's optional scoping but does not clarify 'lang' or 'limit' parameters, leaving their meaning implicit.

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?

The description clearly states it retrieves latest news from the last 24 hours, optionally filtered by category, and returns posts newest-first. This distinguishes it from siblings like get_breaking, get_featured, and search.

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

Usage Guidelines4/5

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

Provides concrete use cases ('what's new today?' and 'what happened in DeFi today?'), but does not explicitly contrast with alternatives or state when not to use.

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

get_postAInspect

Full detail of a single post — title, summary, full body, all categories, hashtags, source attribution. Accepts either a slug (from a previous tool call) or a numeric id.

ParametersJSON Schema

Name	Required	Description	Default
`slug_or_id`	Yes
`lang`	No		en-US

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.8/5.0

Behavior4/5

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

Describes what data is returned (title, summary, full body, etc.). No annotations exist, so description carries burden; side effects are absent, but auth needs or rate limits are not mentioned.

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?

Two sentences with no wasted words, clearly front-loading capability and input options.

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?

Given an output schema exists, the description covers input and output well. Still, could note that it reads a specific post, not a list, and lacks error handling context.

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?

Clarifies that 'slug_or_id' can be a slug or numeric id, adding value beyond schema. However, the 'lang' parameter is left undescribed, and with 0% schema coverage, more detail would help.

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 clearly states it retrieves full details of a single post, listing specific fields. It distinguishes from siblings like get_latest or get_featured by emphasizing a single post, but does not explicitly contrast usage.

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?

Mentions acceptable inputs (slug or numeric id), but lacks guidance on when to choose this over sibling tools or when not to use it.

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

list_categoriesAInspect

List the full Zipp taxonomy (7 main groups × 5 leaves = 35 categories total). Use to discover valid category slugs for the search / get_latest tools.

ParametersJSON Schema

Name	Required	Description	Default
`lang`	No		en-US

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.7/5.0

Behavior3/5

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

No annotations are provided, so the description assumes full burden. It adds structural detail (7×5) and purpose but does not explicitly state read-only behavior or other side effects beyond listing. Minimal behavioral insight.

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?

Two sentences, no filler. First sentence describes the output (taxonomy structure), second gives usage guidance. Extremely efficient.

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?

Given a simple tool with one optional param and an output schema, the description covers purpose and usage well. However, it neglects to mention the 'lang' parameter's effect, which would complete the picture.

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

Parameters1/5

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

Schema coverage is 0%, yet the description adds no explanation for the lone 'lang' parameter. The description focuses entirely on the output, offering zero insight into param meaning or expected values.

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?

The description clearly states it lists the full Zipp taxonomy with exact structure (7 groups × 5 leaves = 35 categories) and specifies the purpose of discovering valid slugs for sibling tools, effectively distinguishing it.

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

Usage Guidelines4/5

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

Explicitly states when to use ('to discover valid category slugs for search / get_latest tools'), providing clear context. Lacks explicit when-not-to-use but implies its role.

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

searchAInspect

Full-text search across Zipp's news catalogue. Returns recent matching stories ordered by recency (with relevance as a tiebreaker). Use for questions like 'what's happening with Bitcoin ETFs?' or 'find news about Solana hacks'.

ParametersJSON Schema

Name	Required	Default
`query`	Yes
`lang`	No	en-US
`category`	No
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.7/5.0

Behavior3/5

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

Discloses ordering (recency with relevance tiebreaker) and recency of results, but no annotations exist so description should also mention that it is a read operation and any rate limits or other constraints.

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?

Two sentences, no wasted words, front-loaded with purpose, highly concise.

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

Completeness2/5

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

Given output schema exists, return info is partially covered, but 4-parameter search tool with 0% schema coverage requires more parameter guidance than provided.

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

Parameters2/5

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

With 0% schema description coverage, the description must compensate but only implies the 'query' parameter via 'full-text search'. Does not explain 'lang', 'category', or 'limit', leaving agent guessing.

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?

Description clearly states verb 'search' and resource 'news catalogue', distinguishing it from siblings like get_breaking or get_featured which target specific subsets.

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

Usage Guidelines4/5

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

Provides concrete examples of questions ('what's happening with Bitcoin ETFs?') that indicate when to use, but does not explicitly exclude cases or mention alternatives.

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.

6 tool updatesv0.1.0May 17, 2026
- First observedget_breaking
- First observedget_featured
- First observedget_latest
- First observedget_post
- First observedlist_categories
- First observedsearch

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

A4.2/5.0

Scored 2026-05-17 03:10 across 6 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: get_breaking for high-importance news, get_featured for curated stories, get_latest for recent news by category, get_post for full details, list_categories for taxonomy, and search for full-text queries. No overlaps.

Naming Consistency5/5

All tools follow a verb_noun pattern with underscores (e.g., get_breaking, list_categories, search). Consistent naming makes it easy to predict tool behavior.

Tool Count5/5

Six tools is an appropriate size for a news reading service. Each tool addresses a distinct retrieval need without being excessive or insufficient.

Completeness5/5

The set covers all common access patterns: breaking news, featured stories, latest by category, search, taxonomy listing, and full post details. No obvious gaps for a read-only news server.

Maintenance

ActivityInactive

ResponsivenessUnresponsive

Resources

Need Help?

Related Servers

Related MCP Connectors

Crypto Prices Mcp
io.github.varvararatta
Unlock the power of real-time cryptocurrency data with our Crypto Price Insights MCP server.
Cryptocurrency Finance
2
Crypto Feeds A
io.github.pipeworx-io
Crypto Feeds MCP.
Cryptocurrency Finance
342
Gate News MCP A
io.github.gateio-dev
Gate news MCP for crypto news, structured events, announcements, and social sentiment.
Cryptocurrency Search Blockchain
18239
Gloria AI A
io.github.cryptobriefing-labs
Real-time curated crypto news for AI agents with sentiment, recaps, and search.
Cryptocurrency AI & Machine Learning Search
711

Related MCP Servers

crypto-news-mcp
Cryptocurrency Search
kukapay
A
license
Not graded
quality
D
maintenance
An MCP server that provides real-time cryptocurrency news sourced from NewsData for AI agents.
Updated 9 months ago (2025-12-10 10:47 UTC)
15
MIT
crypto-rss-mcp
Cryptocurrency RAG Systems Web3 & Decentralized Tech
kukapay
A
license
A
quality
D
maintenance
An MCP server that aggregates real-time cryptocurrency news from multiple RSS feeds.
Updated a year ago (2025-07-24 13:17 UTC)
2
17
MIT
gloria-mcp
Cryptocurrency Search
cryptobriefing-labs
A
license
A
quality
B
maintenance
MCP server for Gloria AI curated crypto news. Provides curated, real-time cryptocurrency news digests, recaps, and search.
Updated 24 days ago (2026-08-25 19:45 UTC)
7
1
MIT
opennews-mcp
Cryptocurrency Finance Search
beare
F
license
A
quality
D
maintenance
Crypto news aggregation MCP server with AI ratings, trading signals, and real-time updates. Enables searching, filtering, and subscribing to news from various sources.
Updated 6 months ago (2026-03-10 02:34 UTC)
11
-

Zipp MCP

Self-host

uvx — no install, one command

pip install — for embedded use

Docker — for hosted / sandboxed environments

Configuration

Why Zipp?

Quick start

Claude Desktop

Claude Code (CLI)

Claude.ai web (Connectors)

ChatGPT (Custom Connectors)

Cursor

Windsurf

Cline (VS Code extension)

Zed

Gemini CLI

OpenAI Responses API

Anthropic Messages API

Smoke test

Tools

Sample response

Languages

Attribution policy

Editorial methodology

Related discovery surfaces

Legal

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

`uvx` — no install, one command

`pip install` — for embedded use