APITube News
Server Details
Real-time news search across 500,000+ sources in 60+ languages with sentiment and entities.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- apitube/news-api-mcp
- GitHub Stars
- 0
Available Tools
2 toolssearch_newsNews SearchARead-onlyInspect
Search news articles using APITube News API with comprehensive filtering.
IMPORTANT INSTRUCTIONS FOR QUERY CONSTRUCTION:
DO NOT use dots in parameter names directly in the root object. Use nested objects instead.
The system will automatically convert nested objects to dot notation for the API. Example: Use { language: { code: "en" } } instead of { "language.code": "en" }.
For multiple values in one parameter, use COMMA separation (e.g., "en,ru,fr" for multiple languages).
Integer filters (has_*, is_*) accept ONLY 0 or 1 (e.g., has_image=1, is_duplicate=0).
Date format: ISO 8601 (YYYY-MM-DD or YYYY-MM-DDTHH:MM:SSZ).
Sentiment scores range: -1.0 (negative) to 1.0 (positive).
Default sorting: published_at DESC (newest first).
Unknown parameters are rejected with an error (-32602) instead of being silently ignored — check the spelling against the list below.
By default the response returns id, title, href, published_at, description and source.domain. The article body is NOT included — request it explicitly with fl (e.g. fl: "title,href,body").
AVAILABLE PARAMETERS:
Content Search
title: Search by article title (supports up to 3 keywords with comma separation) IMPORTANT: a title search covers at most a 31-day published_at window. Omit the dates and the last 31 days are searched; pass a range wider than 31 days and the call fails with 400 ER0110. To cover a longer period, make one call per month-sized window.
ignore: { title: "keyword" } - Exclude articles with specific titles
Languages (60+ supported)
language: { code: "en,ru,fr" } - Filter by language codes (up to 3)
ignore: { language: { code: "fr" } } - Exclude specific languages
Categories (IPTC taxonomy)
category: { id: "medtop:04000000" } - Filter by category ID (up to 3)
ignore: { category: { id: "315" } } - Exclude categories
Topics
topic: { id: "crypto_news,climate_change" } - Filter by topic ID (up to 3)
ignore: { topic: { id: "2" } } - Exclude topics
Industries
industry: { id: "246771,246772" } - Filter by industry ID (up to 3)
ignore: { industry: { id: "246772" } } - Exclude industries
Entities
entity: { id: "1278268,1282301" } - Filter by entity ID (up to 3)
ignore: { entity: { id: "315" } } - Exclude entities
Persons
person: { name: "Elon Musk,Tim Cook" } - Filter by person name (up to 3)
ignore: { person: { name: "John Doe" } } - Exclude persons
Locations
location: { name: "Tokyo,New York" } - Filter by location (up to 3)
ignore: { location: { name: "Paris" } } - Exclude locations
Organizations
organization: { name: "Tesla,Apple,Google" } - Filter by organization (up to 3)
ignore: { organization: { name: "Microsoft" } } - Exclude organizations
Disasters
disaster: { name: "Earthquake,Tsunami" } - Filter by disaster type (up to 3)
ignore: { disaster: { name: "Flood" } } - Exclude disasters
Diseases
disease: { name: "COVID-19,Influenza" } - Filter by disease (up to 3)
ignore: { disease: { name: "Flu" } } - Exclude diseases
Events
event: { name: "Olympics,World Cup" } - Filter by event (up to 3)
ignore: { event: { name: "Super Bowl" } } - Exclude events
Brands
brand: { name: "Nike,Adidas" } - Filter by brand (up to 3)
ignore: { brand: { name: "Puma" } } - Exclude brands
Authors
author: { id: "123,456" } - Filter by author ID (up to 3)
author: { name: "John Doe,Jane Smith" } - Filter by author name (up to 3)
ignore: { author: { id: "789" } } - Exclude author IDs
ignore: { author: { name: "Bob Jones" } } - Exclude author names
has_author: 1 - Articles with attributed authors (0 for without)
Sentiment Analysis
sentiment: { overall: { score: { min: 0.5, max: 1.0 } } } - Sentiment score range
sentiment: { overall: { polarity: "positive" | "negative" | "neutral" } } - Sentiment polarity
sentiment: { title: { score: { min: -1.0, max: 1.0 } } } - Title sentiment
sentiment: { body: { score: { min: -1.0, max: 1.0 } } } - Body sentiment
sentiment: { mixed: 1 } - Articles with mixed sentiment (title/body differ)
sentiment: { consistent: 1 } - Articles with consistent sentiment
Media Content
media: { images: { count: { min: 2, max: 10 } } } - Filter by image count
media: { videos: { count: { min: 1 } } } - Filter by video count
media: { images: { width: { min: 1200, max: 1920 } } } - Filter by image width
media: { images: { height: { min: 800, max: 1080 } } } - Filter by image height
has_image: 1 - Articles with at least one image
has_video: 1 - Articles with at least one video
has_hq_images: 1 - Articles with high-quality images (width >= 1200px)
is_media_rich: 1 - Articles with both images and videos
Source Filtering
source: { id: "314,315" } - Filter by source ID (up to 3)
source: { domain: "cnn.com,bbc.com" } - Filter by domain (up to 3)
source: { country: { code: "us,uk,de" } } - Filter by country (up to 3)
source: { rank: { opr: { min: 0.5, max: 0.9 } } } - OpenPageRank range (0-7)
source: { bias: "left,center,right" } - Filter by media bias (up to 3)
ignore: { source: { id: "315" } } - Exclude source IDs
ignore: { source: { domain: "example.com" } } - Exclude domains
ignore: { source: { country: { code: "fr" } } } - Exclude countries
ignore: { source: { bias: "left" } } - Exclude biases
is_premium_source: 1 - Premium sources (OPR >= 6)
is_verified_source: 1 - Verified sources (OPR >= 5, not duplicates)
Date/Time Filtering
published_at: { start: "2024-01-01", end: "2024-01-31" } - Date range
published_at: "2024-09-26" - Specific date
Supported formats: YYYY-MM-DD, YYYY-MM-DDTHH:MM:SSZ, DD-MM-YYYY, RFC3339
Max 31 days between start and end WHEN the same call also searches titles (title, ignore.title patterns or query); a wider range returns 400 ER0110. Without a title filter the range is unlimited.
An open-ended start ({ start: "2024-01-01" } with no end) runs to the current time, so with a title filter it exceeds the window too — always pair an archive start with an end date.
Sorting
sort: { by: "published_at" | "created_at" | "source.rank.opr" | "read_time" | "sentiment.overall.score" | "sentiment.title.score" | "sentiment.body.score" | "media.images.count" | "media.videos.count" | "media.images.width.min" | "media.images.width.max" | "media.images.height.min" | "media.images.height.max" | "media_richness" | "relevance" | "engagement" | "quality" | "controversy" | "trust" }
sort: { order: "asc" | "desc" }
Advanced sorting: relevance (search ranking), engagement (viral potential), quality (editorial), controversy (polarization), trust (credibility)
Pagination
page: 1 - Page number (default: 1)
per_page: 10 - Results per page (default: 10). One response carries at most 25 articles, so a larger per_page is clamped to 25 — use page to walk through more.
Content Filters
is_duplicate: 0 - Exclude duplicates (0=unique, 1=include duplicates)
is_paywall: 0 - Exclude paywalled content (0=free, 1=paywall)
is_breaking: 1 - Breaking news only
read_time: { min: 1, max: 10 } - Filter by reading time (minutes)
is_long_read: 1 - Articles with read time >= 5 minutes
is_short_read: 1 - Articles with read time < 3 minutes
Field Selection (fl)
Default (no fl): id, title, href, published_at, description, source.domain — body excluded
fl: "id,title,source.name,published_at" - Return only specific fields
fl: "title,href,body" - Ask for the full article text explicitly when you need to read it
Supports nested fields with dot notation: source.name, sentiment.overall.score
Faceting
facet: true - Enable faceting
facet: { field: "source.id,language.id,sentiment.overall.polarity", limit: 20, mincount: 5 }
Supported facet fields: source.id, source.country.id, source.bias, category.id, topic.id, industry.id, language.id, author.id, sentiment.*.polarity, is_duplicate, is_free, is_important, media.images.count, media.videos.count, read_time, published.year, published.month, published.day_of_week, published.hour
Range Faceting
facet: { range: { field: "published_at", start: "2024-01-01", end: "2024-12-31", gap: "1MONTH" } }
facet: { range: { field: "sentiment.overall.score", start: -1, end: 1, gap: 0.25 } }
Date gaps: 1HOUR, 1DAY, 1WEEK, 1MONTH, 1YEAR
Numeric gaps: 0.1, 0.25, 0.5, 1, 5, 10
Highlighting
hl: true - Enable highlighting
hl: { fl: "title,description,body", fragsize: 300, snippets: 5, tag: { pre: "", post: "" } }
Auto-expands search terms using synonyms and morphology
QUERY BUILDING EXAMPLES:
Basic search: {title: "Bitcoin", language: {code: "en"}}
Sentiment analysis: {organization: {name: "Tesla"}, sentiment: {overall: {polarity: "positive"}}}
High-quality sources: {source: {rank: {opr: {min: 0.7}}}, is_verified_source: 1}
Date range (no title filter, so any width): {published_at: {start: "2024-01-01", end: "2024-12-31"}}
Title search over an archive month: {title: "Bitcoin", published_at: {start: "2024-01-01", end: "2024-01-31"}}
Multiple filters: {title: "AI", organization: {name: "Google,Microsoft"}, language: {code: "en"}, is_breaking: 1}
With media: {has_image: 1, media: {images: {count: {min: 2}}}}
Sorted by engagement: {sort: {by: "engagement", order: "desc"}}
With faceting: {facet: true, facet: {field: "source.id,language.id", limit: 10}}
With highlighting: {title: "innovation", hl: true, hl: {fl: "title,body"}}
Breaking news: {is_breaking: 1, sort: {by: "published_at"}}
Long-form quality: {is_long_read: 1, sort: {by: "quality", order: "desc"}}
| Name | Required | Description | Default |
|---|---|---|---|
| fl | No | Comma-separated fields to return (dot-notation supported), e.g. "id,title,source.name,sentiment.overall.score". | |
| hl | No | Enable highlighting (true) or object form. | |
| page | No | Page number (default 1). | |
| sort | No | ||
| brand | No | ||
| event | No | ||
| facet | No | Enable faceting (true) or object form for analytics. | |
| media | No | Media-content filter. | |
| title | No | Search by article title. Up to 3 keywords comma-separated (OR). Phrase in quotes for exact match. | |
| topic | No | ||
| author | No | ||
| entity | No | Named-entity filter. | |
| ignore | No | Exclusion filters — exclude articles matching these. Mirror the positive filters. | |
| person | No | ||
| source | No | Source filter. | |
| disease | No | ||
| category | No | IPTC category filter. | |
| disaster | No | ||
| industry | No | ||
| language | No | Language filter. | |
| location | No | ||
| per_page | No | Results per page (default 10). One response carries at most 25 articles. | |
| has_image | No | Articles with at least one image. | |
| has_video | No | Articles with at least one video. | |
| read_time | No | Reading time in minutes. | |
| sentiment | No | Sentiment filter. Scores range -1.0..1.0. | |
| has_author | No | Has an attributed author. | |
| is_paywall | No | 0 to exclude paywalled content. | |
| is_breaking | No | Breaking news only. | |
| is_duplicate | No | 0 to exclude duplicates. | |
| is_long_read | No | Read time >= 5 minutes. | |
| organization | No | ||
| published_at | No | Publication date range (ISO 8601). | |
| has_hq_images | No | High-quality images (width >= 1200px). | |
| is_media_rich | No | Both images and videos. | |
| is_short_read | No | Read time < 3 minutes. | |
| is_premium_source | No | Premium sources (OPR >= 6). | |
| is_verified_source | No | Verified sources (OPR >= 5). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description reveals important behavior: default sorting and returned fields, that article body is excluded unless requested via fl, that per_page clamps at 25, and that unknown parameters trigger error -32602. It also documents the 31-day title-search window and the 400 ER0110 failure mode.
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 long, but appropriately so for a 38-parameter API with no output schema and complex nested filters. It is front-loaded with the most critical query-construction caveats, grouped into clear sections, and includes examples that earn their place by showing valid composed queries.
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 tool with no output schema and this much nested complexity, the description is complete: it states defaults, limits, failure modes, response field selection, pagination, faceting, sorting, and date handling. Nothing critical for invoking the tool correctly is missing.
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 71%, but the description substantially compensates by explaining practical semantics: nested-object requirements, comma-separation up to N values, date formats, integer 0/1 filters, pagination clamping, default sorts, and field-selection behavior. It also clarifies many parameters that the schema only lists without functional meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: "Search news articles using APITube News API with comprehensive filtering." This clearly differentiates it from the sibling suggest tool, since it is explicitly a search/filter operation over news articles rather than a suggestion generator.
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 is packed with usage context: how to construct nested parameters, when to use comma-separated values, how date ranges behave differently with title filters, and when the API returns errors. It does not explicitly name the sibling suggest tool as an alternative for non-search cases, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
suggestResolve Taxonomy IDsARead-onlyInspect
Resolve a name or prefix to APITube taxonomy IDs so you can use them in the search_news tool's filters.
The search_news tool's most precise filters require IDs you cannot guess:
entity.id — numeric (persons, organizations, locations, brands, events...)
category.id — IPTC slug, e.g. "medtop:04000000"
topic.id — slug
industry.id — numeric
Use this tool FIRST to look those IDs up, then pass them into search_news.
USAGE:
type: which taxonomy to autocomplete — one of "entities", "categories", "topics", "industries".
prefix: the name (or its beginning) to search, e.g. "Tesla", "Elon", "spo".
Returns an array of matches; take the id of the best match and put it into search_news:
suggest({ type: "entities", prefix: "Tesla" }) → [{ id: 12345, name: "Tesla, Inc.", ... }]
search_news({ entity: { id: "12345" } })
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Which taxonomy to autocomplete. | |
| prefix | Yes | Name or prefix to search, e.g. "Tesla", "Elon", "spo". |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite having readOnlyHint and openWorldHint annotations, the description adds substantial behavioral detail: it states the return type (array of matches), instructs the user to pick the best match's ID, and illustrates the output-to-input flow with inline examples. This goes well beyond what annotations convey.
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 moderately long but highly structured: purpose, why needed, usage instructions, and a concrete example. Every sentence earns its place—no filler or repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description fully compensates by showing the exact return structure and a complete usage example. It explains the different taxonomy ID formats and how to integrate with the sibling tool, making the whole workflow comprehensible.
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 input schema already covers 100% of parameters with descriptions, so baseline is 3. The description adds value by providing concrete enum examples ('entities', 'categories', etc.) and prefix examples ('Tesla', 'Elon', 'spo'), plus explaining how the returned ID should be used in search_news.
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 uses a specific verb ('Resolve') and identifies the exact resource (APITube taxonomy IDs) plus the downstream purpose (use in search_news filters). It clearly distinguishes this tool from its sibling search_news by explaining that this is a lookup step, not a search step.
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 explicitly instructs to 'Use this tool FIRST' and explains why (IDs cannot be guessed), with detailed guidance on which `type` values map to which ID formats. It also gives a concrete example of passing the result into search_news, making the intended workflow unmistakable.
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.
1 tool update
- Changed
search_news6 fields changed- added
Input schema / properties / event / properties / categoryAdded value: +{ + "description": "Event family.", + "enum": [ + "business", + "society", + "environment" + ], + "type": "string" +} - changed
Input schema / properties / event / properties / name / descriptionPrevious value: -"Event name(s), comma-separated up to 3."New value: +"Named event entity, comma-separated up to 3. The directory is nearly empty — prefer type/category; an unknown name returns 400 ER0228." - added
Input schema / properties / event / properties / typeAdded value: +{ + "description": "Event codes, comma-separated (max 5) — see /v1/news/event-types, e.g. layoffs, ipo, recall, wildfire.", + "type": "string" +} - added
Input schema / properties / ignore / properties / event / properties / name / descriptionAdded value: +"Exclude these named events (up to 3)." - added
Input schema / properties / ignore / properties / event / properties / typeAdded value: +{ + "description": "Exclude these event codes (max 5).", + "type": "string" +} - changed
Input schema / properties / sort / properties / by / enumPrevious value: -[ - "published_at", - "created_at", - "id", - "source.rank.opr", - "read_time", - "sentences_count", - "paragraphs_count", - "characters_count", - "sentiment.overall.score", - "sentiment.title.score", - "sentiment.body.score", - "media.images.count", - "media.videos.count", - "media.images.width.min", - "media.images.width.max", - "media.images.height.min", - "media.images.height.max", - "media_richness", - "shares.facebook.min", - "shares.facebook.max", - "shares.twitter.min", - "shares.twitter.max", - "shares.reddit.min", - "shares.reddit.max", - "relevance", - "engagement", - "quality", - "controversy", - "trust" -]New value: +[ + "published_at", + "created_at", + "id", + "source.rank.opr", + "read_time", + "sentiment.overall.score", + "sentiment.title.score", + "sentiment.body.score", + "media.images.count", + "media.videos.count", + "media.images.width.min", + "media.images.width.max", + "media.images.height.min", + "media.images.height.max", + "media_richness", + "shares.facebook.min", + "shares.facebook.max", + "shares.twitter.min", + "shares.twitter.max", + "shares.reddit.min", + "shares.reddit.max", + "relevance", + "engagement", + "quality", + "controversy", + "trust" +]
2 tool updates
- First observed
search_news - First observed
suggest
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
Real-time financial news for AI agents: search by ticker and source, with sentiment and entities.
Real-time news and trending topics from major sources
Live global news signals: ranked wire, story timelines, coverage volume/tone/surges. Free, no auth.
AI-enriched financial news for AI agents & trading bots: search, trending, insider, scored 1-10.
Related MCP Servers
- AlicenseBqualityDmaintenanceEnables access to real-time news articles through search, topic headlines, full story coverage, and geo-based local news across multiple countries and languages using the Real Time News Data API.7MIT
- AlicenseNot gradedqualityCmaintenanceProvides news sentiment scores, media volume trends, and historical coverage data for any topic, enabling AI to analyze positive or negative coverage over time.1MIT
- AlicenseAqualityBmaintenanceProvides news sentiment scores and media volume trends for any topic, enabling AI assistants to analyze whether news coverage is positive or negative.31MIT
- AlicenseAqualityCmaintenanceEnables querying and aggregating Chinese and international news along with multi-platform trending topics, featuring deduplication, event clustering, and article extraction for AI clients.7MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
search_news handles article querying, filtering, and retrieval, while suggest is specifically a taxonomy-ID and autocomplete resolver. Even though search_news accepts some plain-text names, suggest's output is explicitly intended to feed into search_news, so the two tools are not in ambiguity.
Both tool names use lowercase and an imperative style, with search_news following a clear verb_noun pattern. The odd one out is suggest, which is just a verb and would fit better as suggest_taxonomy_id, but there is no mixing of naming conventions.
Although two tools is on the smaller side, the pair is well matched to the API's purpose: search_news is a very large query surface, and suggest handles the ID/taxonomy lookups that search_news needs. It feels slightly minimal but not unnecessary or insufficient.
The read-only news-domain workflow is covered end-to-end: search, filter, sort, paginate, select fields, retrieve article bodies, facet, highlight, and resolve taxonomy IDs. I do not see an obvious gap for the stated purpose of searching APITube News articles.