Loading ToolBench
Claude Research-style MCP server implementing Anthropic's multi-agent research methodology with source quality assessment and iterative searching
Kiro Research MCP provides a single web_search tool with a comprehensive description outlining Claude Research methodology. The tool has a well-defined schema with three parameters (query, maxResults, sessionId) and clear type information. However, the schema completeness is moderate, parameters lack detailed constraints and validation rules, and the output schema is not explicitly documented in the source code. The description is excellent (1,800+ chars) and educationally rich, but parameter descriptions are brief and lack actionable constraints (e.g., query length guidance, maxResults bounds, sessionId format). No error handling guidance is visible. The tool name 'web_search' is appropriately verb-noun and unambiguous. The implementation includes sophisticated source quality assessment logic with scoring heuristics, but this is business logic internal to the tool, not exposed in the parameter/output schema for LLM planning. Overall: solid description and naming, moderate schema quality, no visible error recovery patterns.
Search the web for information using Claude Research methodology. ## CLAUDE RESEARCH METHODOLOGY Based on Anthropic's multi-agent research system that outperforms single-agent by 90.2%: ### SEARCH STRATEGY (Critical!) 1. START BROAD, THEN NARROW - Agents default to overly specific queries that return few results - Begin with short, broad queries (2-4 words) - Evaluate what's available, then progressively narrow focus 2. PARALLEL EXPLORATION - Execute multiple searches exploring different aspects simultaneously - Each search should cover a distinct angle/subtopic - This mirrors how Claude Research spawns 3-5 subagents in parallel 3. SCALING RULES (from Anthropic's prompts) - Simple fact-finding: 3-10 tool calls total - Direct comparisons: 10-15 tool calls per aspect (2-4 aspects) - Complex research: 25+ tool calls with clearly divided responsibilities ### SOURCE QUALITY Results are scored 1-10 based on Anthropic's source quality heuristics: - Score 10: Primary sources (official docs, research papers, company blogs) - Score 9: Authoritative (.gov, .edu, major institutions) - Score 7: Quality journalism, analysis - Score 5: General web - Score 3: SEO content farms, social media (deprioritized) PRIORITIZE PRIMARY SOURCES over SEO-optimized content! ### RECOMMENDED WORKFLOW 1. First search: Broad overview query 2. Searches 2-5: Different aspects/angles in parallel 3. Searches 6-10: Fill gaps, verify claims 4. Searches 11+: Deep dive on specific findings
Output schema not documented. The tool description is extensive, but there is no explicit declaration of what fields the response contains, their types, or how they map to source quality scores and pagination. LLMs cannot plan downstream actions without knowing what data is returned.
Parameter descriptions lack actionable constraints. 'query' says 'start broad (2-4 words), then refine' but does not specify minimum/maximum length, forbidden characters, or error behavior if constraints are violated. 'maxResults' has a default (10) but no bounds (e.g., 1-100). 'sessionId' has no format guidance (UUID? alphanumeric? optional?).
No error handling or recovery guidance. The source code does not show how the tool handles invalid queries, malformed sessionIds, API failures, or rate limiting. LLMs receive no guidance on whether errors are retryable, user-fixable, or fatal.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2026-07-28+ | v2 |
Source quality assessment logic is internal and not exposed via output schema. The code contains sophisticated scoring (primary sources 10, authoritative 9, SEO farms 3) and domain heuristics, but the LLM cannot see this scoring in parameter descriptions or output documentation. The agent cannot reason about why certain sources are preferred.
sessionId parameter purpose is unclear. The description mentions 'Session ID to track search progress' but does not explain how the LLM should generate or manage session IDs, whether they persist across multiple tool calls, or what happens if the same sessionId is reused.