MCP server providing database tools (SQL Server connector, schema introspection, query execution) and XAML validation tools for the A2v10 framework
A2V10.MCP exhibits significant gaps in definition quality. Of 9 tools, 6 have acceptable descriptions (40-80 chars), but schema completeness varies widely. XAML tools (GetAllTags, GetAttributesForTag, SuggestTags, SuggestAttributes, ValidateElement, ValidateXamlDocument) have descriptions but lack explicit output schema documentation. The Execute tool accepts an 'options' parameter typed as generic 'object' with no schema constraints. Parameter descriptions exist but lack detail on ranges, formats, and constraints required for LLM reasoning. The ListProjectRoots tool references server and cancellationToken as 'object' types, these are internal implementation details that should not be exposed as tool parameters. No tool declares error handling guidance, recovery steps, or validation rules. Tool names follow verb_noun convention (positive), but composition shows a single Execute tool handling both read and write SQL, violating single-responsibility. Per-tool scores range from 25 (ListProjectRoots, due to invalid parameter exposure) to 65 (SuggestTags, due to clamping details), averaging 42.
Executes the specified SQL query and returns the result.
Returns all unique tag names from A2v10.ViewEngine.Xaml.
Returns all attributes for the specified tag name from A2v10.ViewEngine.Xaml.
Lists the user's project roots
Returns attributes for a tag filtered by prefix.
Returns tags starting with the specified prefix.
Test database connection initialization
Validates that tag and attributes exist in A2v10.ViewEngine.Xaml.
ListProjectRoots exposes internal implementation types (server as 'object', cancellationToken as 'object') as tool parameters. These are not inputs the LLM should control; they are framework artifacts. Tool parameters must accept user-meaningful values (file paths, identifiers, natural language), not internal objects.
Execute tool combines read and write SQL execution in a single tool. Splitting into separate tools (ExecuteReadSQL, ExecuteWriteSQL) or using a 'mode' enum would signal intent clearly and enable fine-grained permission control per Agentic Tool Patterns.
No output schemas documented for any tool. XAML tools return JSON strings (per GetAllTags/GetAttributesForTag code review: 'JsonSerializer.Serialize'), but the shape of returned objects is not declared. LLMs cannot plan downstream operations or extract fields without knowing the response structure.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 39 | <=2025-11-25 | v2 |
Validates full XAML document and returns unknown tags/attributes with locations.
Execute tool's 'options' parameter is typed as generic 'object' with no schema. The code shows ExecuteOptions supports MaxRows (int) and ReadOnly (bool), but the tool definition lacks this structure, forcing LLMs to guess at the object shape.
No error handling guidance in any tool description. Execute and TestDatabaseInit interact with databases but provide no recovery hints (e.g., 'If connection fails, verify DSN and retry' or 'Invalid SQL, check syntax'). Error responses lack classification (retryable vs. fatal).
SuggestTags and SuggestAttributes mention 'clamped to 1-100' in the limit parameter description, but do not explain what happens if the user passes 150 (is it silently clamped, or does it error?). This ambiguity can cause unexpected behavior in agent retry loops.
ValidateElement parameter 'attributes' is typed as array but no itemType schema provided. Is it an array of strings, objects with name/value pairs, or full attribute definitions? The lack of clarity invites malformed input.
GetAllTags, GetAttributesForTag, and ValidateXamlDocument lack input parameter validation hints. No description of what happens if a tag name does not exist, or if XAML is malformed. Silent failures or cryptic errors harm agent reasoning.