A
licenseNot graded
qualityC
maintenanceReal-time news events, clustered by AI from hundreds of sources, classified by topic and geography, ranked by importance.
42
MIT
NewsMCP
by com.newsmcp
Server Details
Live world news deduplicated into story events, with corroboration counts and source links.
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Available Tools
5 toolscheck_coverageAInspect
Judge how widely and how independently a claim has been reported.
Answers "is this real?" rather than returning a list. Reports the number of INDEPENDENT newsrooms — outlets that reported it themselves — separately from the number of domains that carried it, which includes syndication. A story on 200 domains from 3 newsrooms is one story reprinted, not 200 confirmations.
Because upstream clustering splits a story across languages, this totals the likely variants of the same story and presents that total as an upper bound, listing what was combined so the caller can check it is really one story.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| claim | Yes | The claim or headline to check, phrased in the words a headline would use. Matched literally against headlines and summaries, not by meaning, so "atomic arsenal" will not find stories about nuclear weapons. | |
| api_key | No | Optional NewsMCP API key for this call; forwarded upstream as x-api-key. Only one request may be in flight at a time, so never call in parallel. | |
| days_back | No | How far back to look, in days. Defaults to 14. Clamped down to whatever the caller's plan allows, with a note saying so. | |
| response_format | No | markdown (default), text, or json. Pass the format the user asked for rather than reformatting afterwards. | markdown |
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden and does so well. It reveals the critical nuance that independent newsrooms are counted separately from syndicated domains, and it explains the language-clustering behavior that causes the total to be presented as an upper bound with combined variants listed for caller inspection. This goes far beyond a generic 'check coverage' statement.
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 efficiently structured with three purposeful paragraphs: what the tool does, how it distinguishes independent reporting from syndication, and how it handles cross-language clustering. Every sentence adds non-obvious information, and the core purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description adequately explains the return semantics: independent newsroom count, domain count, and the upper-bound total with a list of combined variants. The parameter schema covers all inputs, and the described behavior is sufficiently complete for an agent to invoke the tool correctly and interpret its result.
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?
Schema description coverage is 100%, so the baseline is 3. The description does not add substantial parameter-level meaning beyond what the schema already provides; the schema already explains literal matching, days_back clamping, and response_format choices. The description's focus is on output semantics rather than parameter details.
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 opens with a specific verb and resource: 'Judge how widely and how independently a claim has been reported.' It then distinguishes the tool's purpose by saying it 'Answers "is this real?" rather than returning a list,' which clearly separates it from retrieval-style sibling tools like get_story or news.
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?
The description gives clear context for when to use this tool: when the agent needs to assess whether a claim is credible based on independent reporting, not when it wants a list of articles. It implies the distinction from list-returning siblings but does not explicitly name alternatives or state 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.
check_healthAInspect
Check whether the NewsMCP REST API is reachable and healthy.
Does not require an API token. Use when diagnosing connectivity, not for searching news.
For allowances and remaining budget use check_limits instead.
Returns: str: Health status reported by the API.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden and does disclose the key facts: no API token is required, it is a read-only connectivity diagnostic, and it returns the API health status. It does not go deeper into error handling or timeout behavior, but for a trivial health check this is sufficient.
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 compact, front-loaded with the main purpose, and organized into clear usage and return sections. Every sentence contributes either purpose, routing, auth, or return-value information with no repetition or filler.
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?
For a simple parameterless health check, the description covers purpose, auth, routing, and return type. The only minor gap is not distinguishing check_health from the sibling check_coverage, though the explicit 'API reachable and healthy' wording makes confusion unlikely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters and 100% coverage, so there are no parameters to document; the baseline is 4. The description reinforces this by noting no API token is required, preventing an agent from inventing an auth parameter.
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 uses a specific verb and resource ('Check whether the NewsMCP REST API is reachable and healthy') and immediately differentiates itself from sibling tools by saying it is not for searching news and that check_limits covers allowances. The core purpose is unambiguous and distinct from the sibling set.
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?
It states exactly when to use the tool ('Use when diagnosing connectivity'), gives an explicit exclusion ('not for searching news'), and names the correct alternative for a different need ('For allowances and remaining budget use check_limits instead'). This is near-ideal routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_limitsAInspect
Report what this caller may do right now — and never spend any of it to find out.
Answers the questions the news tool descriptions cannot: how many searches are left
this hour, how far back this plan reaches, the largest limit it allows, how many
searches may run at once, and how long to wait if the budget is spent. These ceilings
are per-plan and change without a release, so trust this over any number written into a
description.
Checking is free: the endpoint is exempt from every metering stage, so calling it does not consume an hourly call, a concurrency slot, or a credit.
Reach for it before planning a batch of calls, and after any plan-limit or rate-limit error instead of guessing the ceiling that was hit.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | Optional NewsMCP API key. Report the ceilings for this key's plan; omit to report the keyless ceilings. | |
| response_format | No | `text` (default) for a readable summary, `json` for the raw payload. | text |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries behavioral disclosure. It explicitly states the call is free: 'the endpoint is exempt from every metering stage, so calling it does not consume an hourly call, a concurrency slot, or a credit.' It also discloses that limits are per-plan and change without a release, preventing the agent from trusting stale values.
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 tight paragraphs with a front-loaded definition, followed by concrete details and usage timing. Every sentence adds value: the free-check behavior, the dynamic nature of limits, and the pre/post-error usage guidance. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (zero required params), has full schema coverage, and an output schema exists so return values need not be described. The description covers purpose, usage timing, and the key behavioral trait (free to call), making it complete for agent invocation.
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?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds broader context about per-plan limits but does not need to compensate for missing parameter documentation. Baseline 3 is appropriate.
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 opens with a clear verb and resource: 'Report what this caller may do right now.' It then enumerates exactly what the tool answers (searches left, plan horizon, largest limit, concurrency, wait time), making its purpose unmistakable and distinct from sibling tools.
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?
The description gives explicit when-to-use guidance: 'Reach for it before planning a batch of calls, and after any plan-limit or rate-limit error instead of guessing the ceiling that was hit.' It also positions the tool as authoritative over numbers in other descriptions, telling the agent to prefer it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_storyAInspect
Expand one story: full summary, classification, actors, and source links.
Use this after any search, when the user wants more than the digest line for a particular story. It is the only tool that can return a story's complete source list.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | Optional NewsMCP API key for this call; forwarded upstream as x-api-key. Only one request may be in flight at a time, so never call in parallel. | |
| event_id | Yes | The `event_id` of a story from an earlier result (e.g. `evt_...`). A story folded into a more complete one answers 404 naming its replacement id — fetch that instead. | |
| include_sources | No | False (default) returns a sample of source links; True returns every one. A large story can carry several hundred, so leave this off unless the user asked for the full list. This is the only place the complete list is available — the search endpoints cap it. | |
| response_format | No | markdown (default), text, or json. Pass the format the user asked for rather than reformatting afterwards. | markdown |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses that the tool expands a story into a full record and uniquely returns the complete source list. It is clearly a read operation with no side effects implied. It does not mention the 404-with-replacement-id behavior, but that is documented in the event_id parameter description, so the agent is not misled.
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 two short sentences plus a usage note, with the core purpose front-loaded. Every sentence earns its place: it states what the tool returns, when to use it, and what makes it unique. There is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-required-parameter expansion tool with no output schema, the description is complete: it lists the return contents, gives the trigger condition, and flags the unique full-source-list capability. The schema covers parameter details like response_format and the api_key concurrency constraint, so nothing an agent needs to call it correctly is missing.
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?
Schema description coverage is 100%, so the schema already documents all four parameters thoroughly. The description adds no additional parameter-level meaning beyond what the schema provides, which matches the baseline of 3 for high schema coverage.
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 opens with a specific verb and resource: 'Expand one story.' It then lists the concrete contents returned (full summary, classification, actors, source links) and contrasts itself with the 'digest line' from search results, making its purpose unambiguous and distinguishing it from sibling tools like news.
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?
The description gives explicit when-to-use guidance: 'Use this after any search, when the user wants more than the digest line for a particular story.' It also states the tool's unique capability as the only source of the complete source list. It does not name alternative tools explicitly, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
newsAInspect
Search already-synthesized news events — pre-built story digests — or fetch one by id.
Each story comes with a generated headline, one-liner, abstract, key actors, and
industry/event-type labels. Use it for a quick digest of what happened, for
deal/incident-type or industry filtering, and for corroboration ranking. Nothing is
required: a bare call returns the most-corroborated stories of the last 24 hours.
Limits — keyless: 7-day from_ lookback, 20 calls/hour, 20 stories per call, over-limit
narrowed with a notice. With a key: per-plan ceilings (free tier today 14 days, 50
calls/hour, 50 stories), over-limit rejected rather than narrowed. Call check_limits
for the live numbers; it is free and never spends the budget it reports on.
Filters combine with AND; event_type, content_type, and sector each accept
several comma-separated values combined with OR.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Optional search terms, matched case-insensitively against the story's headline, one-liner, abstract, and named actors (no article body text, no stemming). Space-separated words are ANDed, so ALWAYS quote a multi-word phrase: `layoffs OR "workforce reduction"` works, `layoffs OR workforce reduction` is read as a mix of AND/OR and rejected. Supports AND/OR/NOT (aliases &&, ||, !), ( ) grouping, and `*` wildcards. NEAR() and MULTIPLE() are NOT supported here — they are silently read as ordinary words instead of erroring, so never use them. Omit q entirely for a filter-only digest ("banking news today" needs no q at all). | |
| sort | No | What "best" means for this call. **Omit it** unless the user asked for a specific ordering: the API then picks `relevance` when `q` or `subject` is set and `newsrooms` when neither is, which is almost always right. Forcing `newsrooms` on a keyword search ranks by story size rather than match, so `subject="Bank of America"` returns "India Now Asia's Least Preferred Stock Market" ahead of "Bank of America Warns of European Stock Decline" — big stories that merely mention the words. `newsrooms`: most independently-corroborated first. `trending`: corroboration weighted by freshness on an 8-hour half-life — the one for "what is blowing up right now". `relevance`: best semantic match to q first, and REQUIRES q. `last_seen`: most recently active. `first_seen`: most recently started. `size`: most articles. `source_count`: most publisher domains, mirrors included. `confidence`: highest label confidence, unlabeled last regardless of order. | |
| from_ | No | Inclusive lower bound on when the story BEGAN (its first_seen) — NOT the publish date of any one article, so a story still running today but started last week falls outside the default window. ISO 8601 (`2026-07-01T00:00:00`) or a relative phrase (`now-6h`, `2 days ago`, `yesterday`); all dates are UTC. Default: 24 hours ago, much narrower than a general news search — widening this is the FIRST thing to try when a query that should match something returns nothing — but the lookback is capped: 7 days keyless (narrowed with a notice), and per-plan with a key (14 days on the free tier today, rejected rather than narrowed). `check_limits` reports the caller's live ceiling. | |
| limit | No | Stories per page, 1–50, default 20, but capped for the caller: keyless 20 (softly, with a notice), and per-plan with a key (50 on the free tier today, over it is a validation error naming the maximum). `check_limits` reports the live cap. Raise it when the user asks for breadth — one call with a a flat ceiling rather than a page size: there is no paging past it, since the hourly call budget is the scarce resource (keyless 20/hour, 50/hour on the free tier). | |
| sector | No | Industry the story belongs to. Comma-separated for OR (`software_it_services,semiconductors` = "tech and chips"). One of: government_public_sector, media_entertainment, financial_services, healthcare_pharma, energy_utilities, retail_consumer, real_estate, agriculture_food, telecommunications, automotive, manufacturing_industrial, transport_logistics, aerospace_defense, mining_metals, construction_infrastructure, education, hospitality_travel, sports_recreation, nonprofit_ngo, legal_services, insurance, software_it_services, ecommerce, banking, defense_security, chemicals, fashion_apparel, gaming_esports, biotechnology, semiconductors, other_sector. | |
| api_key | No | Optional NewsMCP API key for this call; forwarded upstream as x-api-key. Keyless: 7-day `from_` lookback, 20 calls/hour (shared per network address), 20 stories per call — over-limit requests are narrowed with a notice, not rejected. With a key the ceilings come from the plan (free tier today: 14 days, 50 calls/hour, 50 stories) and over-limit requests are rejected with a validation error instead of narrowed. Those per-plan numbers change without a release — call `check_limits` for the live values and the hourly budget left; it costs nothing. A keyed caller may have only one request in flight at a time, so never call in parallel. | |
| subject | No | A single company, person, place, or organisation to centre the search on — plain name, no quoting. Quoted for you, which is the difference between a phrase and a bag of words: `Bank of America` unquoted ANDs three common terms and surfaces "Medtronic Revenue Grows" first, while the quoted phrase surfaces Bank of America. Combines with `q` (subject AND query), so `subject="Tesla", q="recall OR lawsuit"` reads as expected. Setting it also widens the default window from 24 hours to 30 days (clamped to the plan), because a company can go a fortnight without news — that is the single most common reason a name search comes back empty. Pass an explicit `from_` to override. | |
| event_id | No | Superseded by the `get_story` tool, which does this with two arguments instead of nineteen and can return every source link. Kept for compatibility. Fetch ONE story directly by the `event_id` of an earlier result (e.g. `evt_...`) — use it for "pull that story up again". When set, every other filter is ignored. Stories are occasionally folded into a more complete story as coverage develops: that returns 404 naming the replacement id, so fetch that id instead. An id that never existed returns a plain not-found. | |
| verbosity | No | Controls ONLY the source-link list; headline, summary, actors, and labels are always present. `compact`: no links. `standard` (default): up to 3. `full`: every link, uncapped — use it for "show me every source", but it makes a large `limit` very long. | standard |
| event_type | No | What KIND of event the story is, independent of industry. Exact `family.leaf` value; a bare family (`deals`) is invalid and unknown values are rejected naming them. Comma-separated for OR (`deals.merger_acquisition,funding.venture_funding_round` = "M&A or funding news"). The taxonomy is 59 leaves across 21 families, plus the standalone value `unclassifiable` for a labeled-but-uncategorizable story. Families: corporate_finance, markets, deals, governance, society_environment, sports, justice_crime, security, macro_policy, research_science, religion_society, politics, legal_regulatory, culture_media, product, accidents_disasters, operations, funding, local_civic, geopolitics, corporate_comms. The complete set of accepted values: corporate_finance.earnings_report, corporate_finance.analyst_rating, corporate_finance.dividends, markets.stock_move, markets.commodity_price, markets.currency_move, deals.merger_acquisition, deals.ipo_filing, deals.asset_sale, governance.board_change, governance.shareholder_vote, governance.executive_departure, society_environment.climate_event, society_environment.public_health, society_environment.environmental_incident, sports.match_result, sports.transfer_signing, sports.championship, justice_crime.arrest_charge, justice_crime.trial_verdict, justice_crime.investigation, security.cyberattack, security.data_breach, security.physical_security_incident, macro_policy.central_bank_decision, macro_policy.trade_policy, macro_policy.fiscal_policy, research_science.scientific_discovery, research_science.clinical_trial_result, research_science.publication, religion_society.religious_event, religion_society.social_movement, politics.election, politics.policy_announcement, politics.diplomacy, legal_regulatory.regulatory_action, legal_regulatory.lawsuit_filed, legal_regulatory.compliance_ruling, culture_media.celebrity_news, culture_media.entertainment_release, culture_media.award, product.product_launch, product.product_recall, product.feature_update, accidents_disasters.natural_disaster, accidents_disasters.industrial_accident, accidents_disasters.transport_accident, operations.plant_closure, operations.layoffs, operations.supply_chain_disruption, funding.venture_funding_round, funding.grant_award, local_civic.local_government_action, local_civic.infrastructure_project, geopolitics.armed_conflict, geopolitics.sanctions, geopolitics.diplomacy_summit, corporate_comms.press_release, corporate_comms.leadership_statement, unclassifiable. | |
| content_type | No | The FORM the reporting takes, independent of what it is about. Comma-separated for OR. One of: news_report, press_release, service_info, human_interest, explainer, commentary, analysis, opinion, interview, obituary. There is no NOT on this field, so for "analysis, not straight news" name the forms wanted (`analysis`) rather than the ones to exclude. | |
| min_newsrooms | No | Minimum outlets that reported INDEPENDENTLY, mirrors excluded — the strongest is-this-real signal. Reach for this over min_sources whenever the user wants to exclude a story that one outlet ran and everyone else reprinted. `3` ≈ "well-corroborated only". | |
| response_format | No | Output shape in content[0].text. Default `markdown` (readable digest). `text` = plain lines. `json` = full API payload. Match what the user asks for. | markdown |
TDQS
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations, the description carries the full behavioral burden and delivers: keyless vs. keyed rate limits (20 vs. 50 calls/hour), lookback caps (7 vs. 14 days), over-limit behavior (narrowed with a notice vs. rejected), per-call story caps, filter-combination semantics (AND across filters, comma-separated OR within fields), default bare-call behavior (most-corroborated stories of the last 24 hours), and the output shape (headline, one-liner, abstract, key actors, labels). This is exceptionally rich disclosure for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose, then use cases, default behavior, limits, and filter semantics — each sentence earns its place. It is not maximally concise because the rate-limit and lookback details are repeated across the main description and the api_key/from_/limit parameter descriptions, but for a 13-parameter tool with no annotations, the density-to-value ratio is strong.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 13 parameters, no annotations, and no output schema, the description covers everything an agent needs at the call level: the return shape, default behavior when nothing is provided, applicable limits, filter semantics, and a pointer to check_limits for live numbers. The schema supplies the remaining parameter-level detail (sort order nuances, subject window widening, 404-on-fold behavior), so nothing is left unaddressed.
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?
Schema description coverage is 100% and every one of the 13 parameters carries a detailed, example-rich description, so the baseline is 3. The tool description adds one genuine cross-parameter insight — filters combine with AND while event_type/content_type/sector accept comma-separated OR values — which no single param description fully conveys. That is a modest bonus but the schema does the heavy lifting overall.
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 opens with a specific verb and resource — 'Search already-synthesized news events — pre-built story digests — or fetch one by id' — and immediately distinguishes the tool from its check_* siblings by stating that this is the search/fetch tool while others like check_limits are referenced as auxiliary calls. The mention of filtering by deal/incident type, industry, and corroboration ranking further scopes what the tool is for.
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?
The description gives explicit use cases ('quick digest of what happened', 'deal/incident-type or industry filtering', 'corroboration ranking') and explicitly routes the agent to check_limits for live budget numbers, with a reason ('free and never spends the budget it reports on'). However, it presents fetch-by-id as a first-class capability in the main description without noting that get_story supersedes it for that purpose — that caveat lives only in the schema, and no contrast with check_coverage/check_health is given, so the sibling differentiation is slightly incomplete.
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. Dates show when Glama detected each change.
5 tool updates
- First observed
check_coverage - First observed
check_health - First observed
check_limits - First observed
get_story - First observed
news
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
Live global news signals: ranked wire, story timelines, coverage volume/tone/surges. Free, no auth.
Real-time corroborated news events + 5-year archive, for agents. Free tier, no key.
Cross-source news (AP, BBC, NPR, HN, Google News) with topic filtering and dedup.
Real-time news and trending topics from major sources
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceProvides current headlines from 17 news outlets across the political spectrum with bias tags and blindspot detection for stories covered by only one side.1MIT
- AlicenseAqualityDmaintenanceProvides AI agents with global tech news from 500+ sources across regions, with translated titles, scoring, and clustering tools for real-time intelligence.852MIT
- AlicenseAqualityAmaintenanceRead-only, source-linked news intelligence for AI agents: search The Neural Ledger's stories, retrieve story details with citations and revision history, and resolve related entities and assets. It is an evidence layer, not a trading or execution service.82MIT
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
A4.4/5.0
Disambiguation4/5
Each tool has a clear primary role: news searches digests, get_story expands one story, check_coverage verifies claim independence, check_limits reports quotas, and check_health tests API connectivity. The only mild overlap is that news can fetch by id while get_story also expands a story, but their descriptions make the distinction clear.
Naming Consistency3/5
Three tools use a consistent check_ prefix, and get_story follows a verb_noun pattern, but the primary search tool is simply named news, which breaks the convention. The naming is readable and all lowercase snake_case, but the mix of check_, get_, and a bare noun is not fully consistent.
Tool Count5/5
Five tools is well-scoped for a news-focused MCP server: search, detail expansion, coverage verification, usage limits, and health checking each earn their place. There is no bloat or obvious redundancy.
Completeness5/5
The tool surface covers the full intended workflow: search synthesized news, expand a story to full details, verify claim coverage, check live plan limits, and diagnose connectivity. Users can discover stories, dive deeper, and understand constraints without hitting dead ends.