Loading ToolBench
A .NET-based local LLM inference engine with support for GGUF models, GPU acceleration, and MCP server integration for tool calling
SharpInfer exposes 2 tools (web_search, read_url) with minimal definitions. Both tools have descriptions (10-20 chars) that fall below the rubric baseline of 194 chars. Input schemas are present and correctly structured with types and required fields, but parameter descriptions are entirely absent. The tools follow a simple verb_noun naming pattern (search, read) which is good, but lack the depth and guidance expected of production tools. No output schemas are documented. Error handling exists at the MCP bridge level but provides generic error wrapping rather than actionable recovery guidance. Overall, the definitions are sparse and would require significant enrichment for LLM-guided agent use.
Fetch and read the text content of a web page.
Search the web for current information. Use when you need up-to-date facts, news, or data.
Parameter descriptions missing entirely. The 'query' parameter in web_search and 'url' parameter in read_url have no descriptions. LLMs cannot infer from the name alone what format or constraints apply.
Tool descriptions are extremely brief (10-20 chars). Baseline for production tools is 194 chars (p10=34, p90=392). Current descriptions ('Search the web for current information' and 'Fetch and read the text content of a web page') lack context on when to use, prerequisites, and return value expectations.
Output schemas not documented. LLMs need to know what fields to expect from web_search and read_url results to plan downstream operations and extract relevant data.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 36 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 30 | - | v1 |
No input validation constraints documented. The 'query' and 'url' parameters accept unbounded strings with no length limits, format patterns, or validation rules described. LLMs may pass absurdly long or malformed inputs.
Error handling in McpToolBridge returns generic catch-all messages ('MCP Error', 'Error calling MCP tool') without actionable recovery guidance. An LLM receives 'Error: No results found' with no indication whether to retry, adjust the query, or try a different tool.
No tool composition guidance. The two tools (web_search, read_url) appear independent, but in practice agents always chain them: search for URLs, then read them. No documentation hints that agents should call read_url after web_search, nor does web_search output document what fields (URLs, titles, metadata) it returns.