Loading ToolBench
MCP server + Roslyn analyzers for Microsoft Agent Framework (MAF) — migration, audit, prompt-lint, cost auditor, scaffolder, simulator.
maf-doctor has 6 tools with solid descriptions and complete input schemas, but lacks output schema documentation, error handling guidance, and tool annotations. Tool names follow verb_noun patterns (MafApiSafety, MafCompatibility, etc.) but are domain-specific and somewhat opaque to LLMs unfamiliar with MAF terminology. Parameter descriptions are present and adequate (20-60 chars on average), but output structures are not documented, LLMs cannot plan downstream calls or extract return values with confidence. No tool has readOnlyHint/destructiveHint annotations despite clear read/write distinctions. Error responses likely lack recovery guidance. The auto-fix tool (MafAutoFix) accepts a dryRun boolean but no confirmation pattern is evident for the write path, violating pattern:confirmation-request. Overall, this is a well-intentioned domain-specific server that meets the minimum bar (descriptions + schemas) but falls short of A-grade production quality due to missing output docs, annotations, and error handling.
Scan C# source code for anti-pattern violations including security (DefaultAzureCredential, API keys), concurrency (AIContextProvider mutable fields), observability (agents without OpenTelemetry), and agent configuration issues.
Check if an API name is safe to use or if it has been marked as obsolete/removed in the MAF registry.
Automatically fix anti-pattern violations in C# code by rewriting violations of specified rule IDs.
Generate a unified diff showing before/after changes for a specific rule without applying them.
Get compatibility matrix for a specific MAF version, showing .NET runtime, Microsoft.Extensions.AI, Azure.AI.OpenAI, and Microsoft.Agents.AI.Workflows.Generators dependency versions.
Build a project and extract CS0618 (obsolete) and CS0246 (type not found) diagnostics, filtering against the MAF obsolete API registry to identify migration targets.
No output schema documentation. LLMs cannot plan downstream calls or extract return values. Every tool must document what it returns (fields, types, structure).
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). MafAutoFix performs writes but lacks destructiveHint; read-only tools lack readOnlyHint. Annotations help LLMs reason about safety and retry logic.
MafAutoFix accepts dryRun boolean but lacks explicit confirmation pattern or multi-round-trip request (result: 'input_required') for destructive write operations. Should require user confirmation before applying fixes to disk.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | 2026-07-28+ | v2 |
Error handling strategy not visible. Tools return diagnostics/results but no documented error responses, recovery guidance, or classification (retryable vs user-fixable vs fatal).
Tool names use domain-specific prefixes ('Maf*') that are opaque to LLMs unfamiliar with Microsoft Agent Framework. Names like 'MafAutoFix' do not start with action verbs (e.g., 'fix_code_violations', 'scan_for_antipatterns'). Verb-first names improve LLM discoverability.
projectPath parameter appears in multiple tools but lacks format/validation constraints in descriptions. Is it an absolute path? Relative? Does it require a .csproj file? Undocumented constraints invite invalid input.
ruleIds parameter in MafAutoFix and MafBeforeAfter is a comma-separated string with no enum constraint or validation. Should provide an enum of valid rule IDs or document the format explicitly (e.g., 'Comma-separated MAF rule IDs like MAF-AP-SEC-001').