Loading ToolBench
MCP server for NewsAPI Nikola 4 API with D402 HTTP 402 payment protocol support
The NewsAPI server has three tools with reasonable naming and generally complete parameter schemas, but exhibits notable gaps in documentation quality and output schema definition. Tool descriptions exist but are truncated (cut off mid-sentence for search_everything), and parameter documentation is present but inconsistent in depth. The code sample shows incomplete tool implementations and truncated descriptions, which limits confidence in schema completeness. No error handling guidance, recovery hints, or output schema documentation visible. Parameter validation (enums for language, country, category, sort_by) is declared in the schema but descriptions lack actionable constraint details. The server is HTTP-based with D402 payment protocol integration, but the tool definitions themselves do not leverage current patterns like tool annotations (readOnlyHint, destructiveHint, idempotentHint) or structured error categorization.
Get the subset of news publishers that top headlines are available from
Get live top and breaking headlines for a country, category, or query
Search through millions of articles from over 80,000 sources with advanced filtering options
Tool descriptions are truncated or incomplete. 'search_everything' description ends mid-sentence ('Search through millions of articles from over 80,0'). This violates the pattern:tool-description requirement that every tool has a complete, actionable description (10 - 1024 chars). Incomplete descriptions force LLMs to guess when/why to select the tool.
No output/return schema documentation visible. The code shows tool definitions but no documented return types. Without this, LLMs cannot reliably extract data or chain tools.
Parameter descriptions lack actionable constraints. Language, country, sort_by, and category parameters declare enums in schema but descriptions do not state 'must be one of: ...' or explain the options. 'Language code (ar, de, en, es, fr, he, it, nl, no, pt, ru, sv, zh)' is present, but 'sort_by' description is missing detail on valid values (relevancy, popularity, publishedAt).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 17 | - | v1 |
No error handling guidance or recovery hints. Tools have no documented error responses, error categorization (retryable vs user-fixable vs fatal), or actionable error messages. Per pattern:recovery-guide, error responses must tell the LLM what to do next. A user providing an invalid language code should get 'Invalid language: got "xyz", must be one of: ar, de, en, ...' not a raw 400 error.
Tool annotations missing. Tools are marked as READ_ONLY in metadata but not using the current spec's tool annotations (readOnlyHint, destructiveHint, idempotentHint). The code shows '@mcp.tool()' decorators but no annotation declarations. This means LLMs cannot programmatically detect that these are safe read-only operations and may apply conservative retry/confirmation logic unnecessarily.
Result set size not limited or documented. The search_everything and get_top_headlines tools accept page_size parameters with 'max 100' mentioned in descriptions, but no guidance on pagination strategy (cursor vs offset, max total results, default page_size). Per mxe:enforce-result-limits, tools should cap results at reasonable limits (20-50) and document pagination. Large result sets blow context windows.
Parameter from_ uses underscore naming, likely to avoid Python keyword conflict. While pragmatic, descriptions do not explain that from_ is the 'start date' parameter, the underscore suffix could confuse LLMs. Consider renaming to start_date or documenting the alias clearly in parameter description.