Loading ToolBench
MCP-compatible HTTP API for Fabric AI augmentation framework. Provides tool endpoints for pattern execution, YouTube transcription, web scraping, and chat functionality.
The Fabric MCP server exposes 11 tools with basic descriptions and some input schemas, but falls short of production quality. Most tool descriptions are extremely brief (10-50 chars), below the 50-200 char target for LLM-optimized tools. Input schemas are present for most tools but lack complete descriptions for parameters. No output schemas are documented. Error handling is not visible in the code provided. Tool naming follows verb conventions (list_, run_, etc.) but some tools (summarize, extract_wisdom, analyze_claims) lack clear descriptions of when to use them vs. similar tools. The server relies on HTTP transport (positive for protocol readiness) but shows no evidence of modern MCP patterns like tool annotations, structured error responses, or pagination support. Overall, this is a functional but immature implementation suitable for prototyping, not production deployment.
Analyze claims in text
Send a chat message to an AI model
Extract wisdom from text
Get the content of a specific pattern
List all available contexts
List all available AI models
List all available Fabric patterns
Run a Fabric pattern on input text
Tool descriptions critically underdeveloped. 'List all available Fabric patterns' (24 chars), 'Summarize text using the summarize pattern' (41 chars), 'Extract wisdom from text' (24 chars) are all below the production baseline of 50-200 chars. LLMs cannot distinguish when to use summarize vs. extract_wisdom vs. analyze_claims based on these descriptions.
No output schemas documented for any tool. The rubric requires that 'LLMs need to know what fields to expect so they can plan downstream tool calls.' Without documented return types, agents cannot chain tools effectively. E.g., does list_patterns return [{name, description, tags}] or just [string]? Does run_pattern return {output, usage, model_used}?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 27 | - | v1 |
Scrape and convert a webpage to markdown
Summarize text using the 'summarize' pattern
Get transcript from a YouTube video
Parameter descriptions missing or trivial. 'run_pattern' accepts 'temperature' but provides no range (0.0-2.0?), no guidance on when to adjust it, no default. The rubric requires: 'The project key (2-10 uppercase letters, e.g. PROJ)' level specificity. Current: bare parameter names.
No error handling or recovery guidance visible. The rubric requires: 'Error responses must tell the LLM what to do next.' No evidence of try/catch blocks, fallbacks, or error categorization (retryable vs. user-fixable vs. fatal) in the source code provided.
No pagination support visible. Tools like 'list_patterns', 'list_models', 'list_contexts' provide no limit, offset, or next_cursor parameters. If the Fabric system has 1000+ patterns, a naive list returns all, blowing the context window.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) detected. The current MCP spec (2026-07-28) rewards tool annotations to guide agent planning. Tools like 'delete' or 'send' should be marked destructive; 'list_*' should be marked readonly.
Semantic ambiguity: 'summarize', 'extract_wisdom', and 'analyze_claims' all process text but lack clear differentiation. The rubric warns: 'When multiple tools operate on the same resource, their names must make the distinction obvious.' Current names invite LLM confusion. Recommend expanding descriptions to explain use cases (e.g., 'summarize reduces to key points; extract_wisdom distills actionable insights; analyze_claims evaluates factual accuracy').