Loading ToolBench
MCP server for developer workflow automation — smart commits, secret scanning, PR descriptions, and more.
DevNarrate has 3 tools with reasonable naming and comprehensive descriptions, but significant gaps in schema completeness, parameter validation, and error handling prevent higher scores. Tool names follow verb_noun pattern (get_*, commit_*). Descriptions are lengthy (200-800+ chars) and include workflow context, which exceeds the ideal 50-200 char range for LLM-optimized clarity but provides explicit step-by-step instructions. All parameters have descriptions. However, input/output schemas lack formal JSON Schema type definitions and constraints (enums, min/max, patterns). Error handling guidance is minimal, most tools describe what they do but not what to do when they fail. The server demonstrates awareness of security (staging workflow, secret scanning) and composition (multi-step workflows), but lacks the structured output schema documentation and parameter validation rules needed for production-grade agent reliability.
Execute git commit with a user-approved commit message. CRITICAL WORKFLOW - YOU MUST FOLLOW THESE STEPS IN ORDER: 1. Call get_commit_context to get the diff 2. Generate a commit message based on the actual diff 3. SHOW the generated commit message to the user in your response 4. ASK the user: "Should I proceed with this commit?" and WAIT for their response 5. ONLY call this tool AFTER the user explicitly approves (says "yes", "proceed", "commit it", etc.) 6. Set user_approved=True when calling this tool DO NOT call this tool in the same response where you generate the commit message. The user MUST see the message and approve it first.
REQUIRED FIRST STEP: Get git diff and file changes to analyze before writing a commit message. IMPORTANT: You MUST call this tool FIRST before generating any commit message. Never write a commit message without first seeing the actual git diff from this tool. This tool ONLY shows STAGED changes. We intentionally do not support unstaged changes to ensure users have explicit control over what gets committed and prevent accidental commits. CRITICAL: If the diff is empty and there are no files: 1. STOP immediately - do NOT proceed with generating a commit message 2. Tell the user: "No staged changes found. Please stage the files you want to commit first using: git add <file1> <file2>" 3. DO NOT attempt to stage files automatically 4. Wait for the user to stage their changes Returns file changes and diff output with TOKEN-BASED pagination (MCP limit: 25k tokens). Large diffs are automatically paginated to stay under the token limit.
Get diff and commits between branches for PR description. IMPORTANT: After calling this tool, you should: 1. Check if .devnarrate/pr-templates/ directory exists (use ls or Bash) 2. If templates exist, list them and ask user which template to use 3. Read the chosen template file (use Read tool) 4. If no templates exist, use git_operations.DEFAULT_PR_TEMPLATE 5. Analyze the diff and commits to fill the template
Input and output schemas lack formal JSON Schema type definitions. Parameters are documented in descriptions but not declared with 'type', 'enum', 'minimum', 'maximum', or 'pattern' constraints. This forces LLMs to infer validity rules from text and invites invalid inputs (e.g., max_diff_tokens as string instead of integer, cursor with no format constraint).
No documented output/return schema. Tools describe what they return in text (e.g., 'JSON string with: has_changes, files, secret_scan, diff, next_cursor...') but do not provide formal JSON Schema with field types and structure. Agents cannot plan downstream tool calls or validate extracted data without explicit schemas.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 24 | - | v1 |
Descriptions exceed 200 characters and mix workflow guidance with parameter documentation. The 50-200 char baseline is designed for LLM scanning and decision-making speed. Lengthy descriptions (e.g., get_commit_context ~900 chars with nested lists and sub-steps) risk token waste and cognitive overload. Split workflow instructions into separate guidance or examples rather than embedding in tool description.
No error handling guidance. Tools describe happy paths but do not tell LLMs what to do on failure. For example, if git operations fail (no repo, invalid branch, permission denied), what should the agent retry, ask the user, or skip? No error classification (retryable, user-fixable, fatal) is documented.
commit_changes requires user_approved=True but does not explain what happens if an LLM passes False, or how to recover if the LLM calls commit before user approval. The description says 'user_approved=True' but does not document the constraint or error behavior.
Parameter descriptions contain example values (e.g., 'e.g., "main", "dev"' for base_branch), which LLMs frequently reuse literally. Replace with enum constraints or format declarations, or remove examples entirely and rely on formal schema constraints.
No pagination/result limits documented for get_commit_context and get_pr_context. While max_diff_tokens is exposed as a parameter, there is no documented absolute limit, minimum, or safe default. Agents could request arbitrarily large diffs, risking context exhaustion.