Loading ToolBench

Reading the current corpus…

palena-websearch-mcp MCP server · D · ToolBench

palena-websearch-mcp

github.com/PalenaAI/palena-websearch-mcp

Enterprise-grade web search MCP server with PII detection, prompt-injection screening, content scraping, and reranking capabilities. Returns LLM-ready markdown with full audit trail and compliance boundaries.

<=2025-11-25STDIO1 tools

59/100

Definition Quality72

Protocol Readiness32

Supportability55

Spec posture

Inferred effective spec <=2025-11-25·current baseline 2026-07-28

Static source inference · medium confidence · detected: Logging

Deprecated protocol patterns detected

Summary

Single tool 'web_search' has a well-structured input schema with 5 parameters, all typed and described. Tool description is clear and actionable (145 chars). Parameters include enums (category, timeRange), numeric bounds (maxResults 1-20), and language codes. However, output schema is not documented in the visible code, the tool description mentions 'scraped and optionally reranked content with citations and source URLs' but no formal output structure is defined. Error handling and recovery guidance are absent. The tool follows verb_noun naming and accepts natural parameters (query, language codes) rather than opaque IDs, which is good. Missing: output schema documentation, error classification, and recovery hints.

Tools (1)

web_searchread onlysource verified72/100

Search the web and retrieve relevant content from result pages. Returns scraped and optionally reranked content with citations and source URLs. Content is checked for PII according to deployment policy.

Issues (5)

HIGHtool ↗

Output schema not documented. Tool description mentions 'scraped content with citations and source URLs' but no formal JSON schema for the response is visible in code or docs. LLMs cannot plan downstream operations without knowing response structure.

web_search

HIGHrecovery-guide ↗

No error handling or recovery guidance. Tool description does not explain what happens on network failure, invalid query, or PII detection. LLMs have no guidance on retry strategy or fallback actions.

web_search

MEDIUMtool-description ↗

PII filtering mentioned in description but not exposed as a parameter or configuration. Description states 'Content is checked for PII according to deployment policy' but no control or transparency mechanism is visible.

web_search

MEDIUMpaginated-result ↗

No pagination or result limiting guidance. maxResults caps at 20, but description does not explain what happens if query matches thousands of results or how to iterate through pages.

Recommendations

Document the output schema explicitly. Define a JSON structure with fields like 'results' (array of {title, url, snippet, source}), 'total_count', and 'search_time_ms'. Include this in internal/transport/tools.go or a separate schema file.
Add error handling guidance to the tool description. E.g., 'Returns error if query is empty, network timeout occurs, or PII is detected in results. Retry with a refined query or check network connectivity.'
Expose PII filtering as an optional parameter (e.g., 'filter_pii': boolean, default true) so agents can control sensitivity vs. completeness tradeoff.
Document pagination behavior. If maxResults=20 is a hard cap, state: 'Returns up to 20 results per call. For more results, refine the query or use timeRange to narrow scope.'
Migrate from STDIO to HTTP+SSE or Streamable HTTP transport to enable remote client access and hosted MCP deployments.

Spec posture evidence

Inferred effective spec: <=2025-11-25.

Relies on Logging (deprecated) - log to stderr or use OpenTelemetry

Score history

Overall score trend

First recorded score · v2 rubric

59/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	D	59	<=2025-11-25	v2