Loading ToolBench
Model Context Protocol server for Document360 - search, retrieve, and interact with your knowledge base articles, categories, and project versions through AI assistants
This server has 5 READ-ONLY tools with clear action-verb naming (get_*, list_, search_). All tools have descriptions and input schemas are visible in the code. However, there are significant gaps: (1) Descriptions lack WHEN-to-use context and dependencies between tools. (2) Output schemas are completely undocumented, callers cannot see what fields will be returned. (3) Parameter descriptions are minimal; several params lack guidance on valid ranges or formats (e.g., hits_per_page accepts 1-1000 but no validation shown). (4) No pagination guidance in list_project_versions despite the pattern being standard. (5) Error handling is present but generic, errors raised are not categorized for the LLM (retryable vs user-fixable vs fatal). Average per-tool score is 58, placing this in the 'Fair' range with noticeable gaps in schema documentation and error guidance.
Get article by ID from Document360 Args: article_id: Document360 article ID (UUID string) ctx: MCP context for logging and error handling Returns: Article information including title, content, tags, and metadata
Get category by ID from Document360 Args: category_id: Document360 category ID (UUID string) ctx: MCP context for logging and error handling Returns: Category information including name, description, articles, and metadata
Get category page content by ID from Document360 Args: category_id: Document360 category ID (UUID string) page_id: Document360 page ID (UUID string) ctx: MCP context for logging and error handling Returns: Full page content including HTML/text content and formatting
List all project versions from Document360 Args: ctx: MCP context for logging and error handling Returns: List of project versions
Search inside a project version and return related articles/categories in Document360 Args: project_version_id: Document360 project version ID (UUID string) query: Optional free-text phrase to search across articles/categories (server-side) hits_per_page: Maximum number of ranked results to return ctx: MCP context for logging and error handling Returns: Ranked list of hits (articles/categories) from the project version search endpoint
Output schemas completely undocumented. No tool describes what fields will be returned (e.g., get_article returns 'Article data from Document360 API' but no field list). LLMs cannot plan downstream calls without knowing output structure.
Parameter descriptions are generic and lack actionable constraints. 'hits_per_page: Maximum number of ranked results to return (1-1000)' states the range in text but provides no guidance on what happens when exceeded, or recommended defaults for different use cases.
Error handling raises exceptions without categorizing them for LLM decision-making. Errors are logged but not classified as retryable, user-fixable, or fatal. 'Invalid API key' error is detected but not surfaced with recovery guidance like 'Check configuration and retry'.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 39 | - | v1 |
list_project_versions has no pagination or limit parameters, despite being a discovery tool that could return many items. No description of expected result count or guidance on whether pagination is needed.
Tool descriptions lack WHEN-to-use context and dependency hints. For example, search_in_project requires a project_version_id but no description suggests calling list_project_versions first to discover valid IDs.
get_category_page_content and get_article do not clarify relationship. Both fetch document content but no description explains when to use one vs the other (e.g., 'Use get_article for full article metadata and content; use get_category_page_content for specific pages within a category').