Loading ToolBench
MCP server providing DuckDuckGo search capabilities with specialized searches for GitHub code, Malaysia news, and Azure documentation
This server has 5 tools with significant definition gaps. Tool naming is mostly verb-initial and clear (search_*, read_*, add_*), which is good. However, parameter descriptions are minimal or absent, input schemas lack detail, and output schemas are entirely undocumented. Three search tools (search_github_code, search_malaysia_news, search_azure_docs) have identical parameter structure (single 'topic' string) with descriptions that are present but generic (10-15 words each). The add_note and read_notes tools are slightly better documented but still lack output schema clarity. No tool includes error handling guidance, validation rules, or pagination info. The server mixes concerns (some tools read from files, others hit external APIs) without clear error recovery paths. Overall, definitions are functional but fall short of production quality, parameters lack type constraints and ranges, outputs are documented as plain strings without field definitions, and there's no guidance on handling failures.
Append a new note to the sticky note file.
Read and return all notes from the sticky note file.
Search for Azure resource documentation on learn.microsoft.com using DuckDuckGo.
Search for code related to a specific topic on GitHub using DuckDuckGo.
Search for Malaysia local news from NST website using DuckDuckGo.
Output schemas are completely undocumented. All tools return unstructured strings ('str') with no field definitions, requiring LLMs to parse free-text responses. Search tools return formatted text blocks; read_notes and add_note return confirmation strings. This violates the 'Document the output schema' rule and makes downstream tool composition fragile.
Parameter descriptions are generic and lack actionable constraints. The 'topic' parameter across all search tools is described as 'The topic to search for...' (10-15 chars) with no examples of valid values, format hints, or length constraints. This violates the 'Every parameter needs a description explaining what it controls' and 'Describe the expected format, range, and allowed values' rules.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 34 | - | v1 |
No error handling guidance. Search tools can return 'No [resource] results found.' but do not explain what the LLM should do next, retry with different keywords? Try a different tool? This violates the 'Error responses must tell the LLM what to do next' rule.
Search tools lack pagination or result limits. max_results=5 is hardcoded in the code but not documented in tool descriptions. If an LLM expects 20 results and gets 5, it has no hint to ask for pagination. Violates 'Tools returning lists should accept page/offset and limit parameters and return a total count.'
Input schemas are present in code but bare of constraints. All 'topic' parameters are typed as 'string' with no minLength, maxLength, or enum constraints. An LLM could pass empty strings, 10,000-char topics, or SQL injection payloads without validation feedback.
read_notes output schema is undocumented. Returns a string that could be multiline notes or 'No notes yet.', the structure is implicit and forces the LLM to guess whether to expect newlines, timestamps, or formatted entries.
Tool descriptions do not explain when to use each search tool vs others. 'Search for code related to a specific topic on GitHub' does not clarify how this differs from a generic web search or why an LLM should pick this tool over search_azure_docs or search_malaysia_news for a code question.
add_note has no idempotency guarantees. Calling it twice with the same message appends twice, side effects are not idempotent. This violates 'Make tools produce the same result on repeated calls with the same input.'