Static source inference · medium confidence · detected: Roots
Deprecated protocol patterns detected
Summary
d365fo-mcp exposes 20 tools covering D365 Finance & Operations metadata, analysis, and code generation. While most tools have descriptions and declared input schemas, the quality is inconsistent. Tool naming lacks consistent verb-noun patterns (e.g., 'search', 'find_references', 'extension_info', 'object_patterns' mix conventions). Parameters are mostly described but lack type constraints and validation guidance. Output schemas are undocumented, no evidence of return type specifications, pagination support, or chaining IDs. Error handling is minimal. The server is STDIO-only, capping protocol readiness at 50. Average per-tool score across 20 tools is 52, reflecting moderate structural quality offset by missing output documentation and weak error guidance.
Output schemas completely undocumented. No evidence of return type specifications for any of the 20 tools. LLMs cannot plan chaining calls or extract required fields without knowing what each tool returns.
Inconsistent tool naming conventions. Some follow verb_noun (get_object_info, validate_code), others use bare nouns (search, extension_info, object_patterns, prepare). LLMs cannot reliably infer intent from inconsistent naming.
searchextension_infoobject_patternsprepare
Recommendations
Document output schemas for all 20 tools. For each, specify: (a) the fields returned, (b) the types of those fields, (c) any references/IDs that chained tools accept. Example: 'search returns {results: [{name: string, objectType: string, relevance: number}], total: number, nextCursor?: string}'
For all 'mode' parameters, replace vague descriptions with explicit enum lists. Example: mode: string (enum: 'events'|'table-merge'|'points'|'strategy'|'coc'), do not make LLM guess.
Add error handling to tool descriptions: e.g., 'Returns 400 with message if target object not found, call search() to find valid names. Retry is safe if error is 503 (service unavailable).' This guides agent recovery.
Add dry-run or confirm_before_execute pattern to d365fo_file, labels, build_d365fo_project. Destructive operations must offer a preview or confirmation step before committing changes.
Expand 'prepare' description: 'Prepares context for a given object (table or form), returning full metadata, available patterns, related objects, and recent changes. Call this before code-generation tools to ground the LLM in domain facts.'
Document pagination for search and find_references: 'Returns up to 20 results per call. Pass nextCursor from response to fetch the next page. Combine all results client-side if needed.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Roots (deprecated) - pass files/dirs via tool parameters, resource URIs, or configuration
No error handling guidance. Tools do not return actionable error messages. When 'search' fails, does the LLM retry with different parameters, call a different tool, or ask the user? No classification (retryable/user-fixable/fatal) provided.
Parameter descriptions lack explicit constraints. 'mode' parameter appears in 6+ tools (extension_info, analyze_code, security_info, get_knowledge, validate_code, labels, d365fo_file, generate_object) but valid enums are never listed. LLMs must guess which values are valid.
Destructive tools (d365fo_file, labels, build_d365fo_project) lack confirmation/dry-run support. No evidence of safeguards preventing accidental deletion or overwrite. Agents can irreversibly modify D365FO objects without confirmation.
'params' field in d365fo_file is an untyped object. No schema or documentation for operation-specific parameters (add-method, add-field, modify-property). LLMs cannot know what sub-parameters each operation accepts.
No pagination support documented. 'search' accepts 'queries' array and 'find_references' returns references, but no limit/offset/page_size or next_cursor returned. Large result sets will blow context windows.
prepare and object_patterns have vague descriptions. 'Prepare grounded context' and 'Patterns (table/form)' do not explain WHAT context/patterns are returned or WHEN to call these tools. LLMs cannot determine if they should be called before other tools.
prepareobject_patterns
Define d365fo_file.params schema explicitly. Create separate tool methods or document required sub-parameter sets for each operation type (add-method requires {paramName, paramType, description}, add-field requires {fieldName, fieldType, label}, etc.).
Add parameter type constraints in descriptions where JSON Schema alone is insufficient. Example: 'projectPath: string (absolute path to D365FO project root, must exist and contain packages.config).'
Implement per-tool limit caps. Many tools accept arrays (queries, objects) but no max length documented. Add 'batch_size_max: 50' guidance to prevent runaway calls.