Loading ToolBench

Reading the current corpus…

mcp-server-azure-devops MCP server · F · ToolBench

← Browse

mcp-server-azure-devops

github.com/estebanjosse/mcp-server-azure-devops

Azure DevOps reference server for the Model Context Protocol (MCP)

2026-07-28+STREAMABLE_HTTP44 tools

47/100

Definition Quality40

Protocol Readiness72

Supportability41

Spec posture

Inferred effective spec 2026-07-28+·current baseline 2026-07-28

Static source inference · medium confidence · evidence: Streamable HTTP

Current-spec patterns detected

Summary

Server has 44 tools with consistent naming (verb_noun pattern) and basic descriptions. However, parameter descriptions are largely absent or minimal, and output schemas are not documented in the visible code. Tool definitions use Zod schemas converted to JSON Schema, but the actual schema constraints and parameter documentation are not visible in the provided source. Most tools are READ_ONLY (low risk), but WRITE operations (trigger_pipeline, create_pull_request, create_commit, etc.) lack confirmation patterns and detailed error guidance. Descriptions average ~80-120 chars, below the 194-char baseline for A+ tools. No tool annotations (readOnlyHint, destructiveHint) detected.

Tools (44)

add_pull_request_commentwriteauthsource verified

Add a comment to a pull request (repositoryId optional; derived from pullRequestId when omitted)

create_branchwriteauthsource verified

Create a new branch from an existing one

create_commitwriteauthsource verified57/100

Create a commit on an existing branch using file changes. - Provide plain branch names (no "refs/heads/"). - ⚠️ Each file path may appear only once per commit request—combine all edits to a file into a single change entry. - Prefer multiple commits when you have sparse or unrelated edits; smaller focused commits keep review context clear. 🎯 RECOMMENDED: Use the SEARCH/REPLACE format (much easier, no line counting!). **Option 1: SEARCH/REPLACE format (EASIEST)** Simply provide the exact text to find and replace: ```json { "changes": [{ "path": "src/api/services/function-call.ts", "search": "return axios.post(apiUrl, payload, requestConfig);", "replace": "return axios.post(apiUrl, payload, requestConfig).then(r => { processResponse(r); return r; });" }] } ``` The server fetches the file, performs the replacement, and generates the diff automatically. No line counting, no hunk headers, no context lines needed! **Option 2: UNIFIED DIFF format (Advanced)** If you prefer full control, provide complete unified diffs: - Each patch MUST have complete hunk headers: @@ -oldStart,oldLines +newStart,newLines @@ - CRITICAL: Every @@ marker MUST include line numbers. Do NOT use @@ without line ranges. - Include 3-5 context lines before and after changes. - For deletions: `--- a/filepath` and `+++ /dev/null` - For additions: `--- /dev/null` and `+++ b/filepath` Example unified diff: ```json { "changes": [{ "patch": "diff --git a/file.yaml b/file.yaml\n--- a/file.yaml\n+++ b/file.yaml\n@@ -4,7 +4,7 @@ spec:\n spec:\n type: ClusterIP\n ports:\n- - port: 8080\n+ - port: 9090\n targetPort: http\n" }] } ```

create_pull_request

Issues (5)

HIGHtool-description ↗

Parameter descriptions missing or minimal. Visible schema files (e.g., ListPipelinesSchema, GetPipelineSchema) are imported but not shown; cannot verify if parameters have descriptions explaining format, constraints, or dependencies. This violates pattern:tool-description which requires every parameter to have a non-empty description.

list_pipelinesget_pipelinelist_pipeline_runstrigger_pipelinecreate_pull_requestsearch_codelist_work_items

HIGHtool ↗

Output schemas not documented. Tool definitions show inputSchema but no outputSchema or return type documentation. LLMs cannot plan downstream tool calls or extract required fields (e.g., IDs for chaining). Violates pattern:tool and mxe:include-chaining-ids.

list_organizationslist_pipelinesget_pipelinecreate_pull_requestcreate_commitlist_work_items

HIGH

Recommendations

Add parameter descriptions to all Zod schemas. For each parameter, include format (e.g., 'ISO 8601 date'), constraints (e.g., 'max 100 chars'), and dependencies (e.g., 'required if status=draft'). Example: 'organization_name (string, 1-255 chars): The Azure DevOps organization name. Required.'
Document output schemas for all tools. Add a 'returns' section to each tool definition listing field names, types, and descriptions. Example: 'Returns: { pipelines: [{ id: string, name: string, url: string }], total: number }'.
Add tool annotations (readOnlyHint, destructiveHint, idempotentHint) to tool definitions. Mark all READ_ONLY tools with readOnlyHint=true; mark WRITE tools with destructiveHint=true if they modify/delete state. Example: { name: 'trigger_pipeline', destructiveHint: true, ... }
Implement confirmation pattern for WRITE operations. Add an optional 'dry_run' parameter to trigger_pipeline, create_commit, create_pull_request, and update_work_item. When dry_run=true, return what would happen without executing. When false, require explicit confirmation via a separate 'confirm_*' tool or a confirmation_token flow.
Enhance error messages with recovery guidance. When a resource is not found (e.g., pipeline not found), return available alternatives. Example: 'Pipeline "my-pipeline" not found in project "MyProject". Available pipelines: build-pipeline, deploy-pipeline, test-pipeline. Try list_pipelines to see all options.'

Score history

Overall score trend

First recorded score · v2 rubric

47/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	F	47	2026-07-28+	v2