Loading ToolBench
An MCP server for serving Gno documentation, tutorials, and guides with markdown file access and document retrieval capabilities.
The server exposes three read-only tools with basic but incomplete definitions. Tool naming follows verb_noun convention and is clear (get_document, list_documents, list_documents_by_category). Descriptions exist but lack actionable detail for LLM selection, they are generic overviews without specific guidance on WHEN to use each tool or HOW they differ from each other. The `get_document` and `list_documents_by_category` tools have schemas with required parameters and descriptions, but output schemas are completely absent from the code, LLMs cannot see what fields to expect from results. Error handling is present (filepath validation, input type checking) but returns bare error messages ('invalid arguments type', 'filename must be a string') without recovery guidance. The `list_documents` tool accepts no parameters, which is reasonable, but the category tool lacks an enum constraint on the category parameter, it accepts a free-form string and relies on description to hint at valid values, inviting hallucinated inputs.
Retrieve Gno documentation, tutorials, and guides. Access comprehensive materials about Gno, gno.land, and Gnolang, including smart contract examples, language specifications, and best practices.
Browse all available Gno documentation and learning resources. Includes development guides, language tutorials, smart contract examples, API documentation, and user guides for Gno, gno.land, and Gnolang.
Browse Gno documentation by category. Choose from: builders (development guides, tools, smart contract examples), resources (language reference, API docs, specifications), or users (getting started guides, tutorials).
No output schemas documented. LLMs cannot plan downstream tool calls or extract expected fields from results. The code shows tools execute and return results, but what fields/structure those results contain is invisible to the MCP client.
The `category` parameter in `list_documents_by_category` is a free-form string with no enum constraint. Description mentions 'builders', 'resources', 'users' but LLMs often hallucinate similar values like 'builder', 'resource', 'tutorial'. Should declare category as an enum: ['builders', 'resources', 'users'].
Tool descriptions are generic and lack WHEN/WHY guidance. All three descriptions emphasize content breadth ('comprehensive materials', 'development guides, language tutorials') but do not explain when to use list_documents vs list_documents_by_category, or how get_document relates to both. This forces LLMs to guess at tool selection.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Error messages lack recovery guidance. Handlers return bare errors like 'invalid arguments type', 'filename must be a string', 'only markdown files are supported'. These do not tell the LLM what to do next. E.g., 'only markdown files are supported' should be 'Filename must end in .md (e.g., getting-started.md). Call list_documents() to see available files.'
`list_documents` tool accepts no parameters and no description explains what it returns or how many results to expect. If this returns 100+ docs, response bloat will dilute the LLM context. No pagination support visible.