Loading ToolBench
MCP Gateway with Azure DevOps and Confluence/Docupedia servers
The MCP Connector exposes 5 tools across Azure DevOps and Confluence integrations. All tools have basic descriptions and parameter schemas are visible in the source code. However, there are significant gaps: descriptions are terse (many under 100 chars, some lack actionable detail), parameter descriptions are minimal or missing context about constraints, output schemas are not explicitly documented, and error handling lacks recovery guidance. The server is HTTP-based (good for transport), but tool definitions feel rushed rather than LLM-optimized. Naming is clear and follows verb_noun conventions (list_work_items, get_work_item, search_content, get_page, list_spaces), which is a positive. However, descriptions lack the depth needed for confident LLM tool selection, and there is no evidence of output schema documentation, which blocks downstream tool chaining design.
Get a Confluence page by ID or title
Get a specific work item from Azure DevOps by ID
List Confluence spaces
List work items from Azure DevOps using WIQL query
Search for content in Confluence using CQL (Confluence Query Language)
Output schemas not documented. The code shows parameter input schemas, but tool return types are not explicitly defined in the source. LLMs cannot plan downstream tool calls without knowing what fields to extract (e.g., does list_work_items return a 'work_item_id' field that get_work_item accepts?).
Parameter descriptions lack specificity. Most input parameter descriptions in the tool definitions are one-line placeholders (e.g., 'Azure DevOps organization name (defaults to config)', 'Project name (defaults to config)', 'WIQL query (default: returns recent items)'). These do not explain constraints, valid formats, or dependency relationships. For example, 'wiql_query' lacks any hint about WIQL syntax or examples of valid queries.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 65 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 14 | - | v1 |
Tool descriptions are too brief to guide LLM selection. Descriptions like 'List work items from Azure DevOps using WIQL query' (53 chars) and 'Get a specific work item from Azure DevOps by ID' (49 chars) meet the minimum length threshold but lack context about WHEN to use each tool versus alternatives, what they return, and whether they support pagination. A description should answer: What does it do? When should I call this instead of a similar tool?
No pagination guidance. list_work_items and search_content accept max_results but do not document whether they support offset/limit patterns, whether results are capped by default, or how to retrieve the next page of results. Large result sets may blow the LLM context window.
Error handling does not guide recovery. The source code (mcp-ado/mcp_server.py) shows error handling with status codes (404, 401, 403) and helpful error messages for HTTP errors. However, the tool definitions themselves do not document what errors the LLM should expect or how to recover (e.g., 'If work item not found, try search_content first to verify project and ID').
Parameter types not fully constrained. For example, 'content_type' in search_content is described as 'Type of content to search (page, blogpost, comment, attachment) - defaults from config' but is not declared as an enum in the parameter schema. This forces LLMs to hallucinate valid values instead of picking from a validated set.
Missing dependency hints. Parameters with defaults (e.g., 'organization defaults to config', 'space_key defaults to CONLP') do not explain when to override them or what happens if they are missing. An LLM does not know whether omitting 'organization' is safe or will cause a failure.