Loading ToolBench
MCP server for Dataverse integration with Dynamics 365 and Microsoft CRM
Mixed quality across 8 tools. All tools have descriptions (good), but most descriptions are brief and lack important detail about side effects, prerequisites, and recovery paths. Input schemas are present and have types, but descriptions for parameters are minimal. No tool annotations (readOnlyHint/destructiveHint/idempotentHint). Output schemas are inferred but not formally documented. Error handling exists but lacks actionable recovery guidance. The server supports real Dataverse workloads with proper distinction between read/write/destructive operations (via Risk labels), but the MCP tool definitions do not encode these constraints in a way agents can act on.
Create a new record in a Dataverse table.
Delete a record from a Dataverse table.
Get detailed metadata for a specific Dataverse table by name or schema name.
List Dataverse table metadata (entity definitions). Use this tool to find the exact EntitySetName if you only know the display name.
Query records from a Dataverse table using OData filters.
Retrieve a single record from a Dataverse table by ID.
Update an existing record in a Dataverse table.
Destructive tool lacks actionable error guidance. dataverse_delete_record has minimal description ('Delete a record from a Dataverse table.') with no mention of irreversibility, no confirmation/dry-run pattern, and no recovery guidance if deletion fails. Agents need explicit 'this action cannot be undone' messaging and should support a confirmation step.
Write/create tools lack side-effect declaration. dataverse_create_record and dataverse_update_record descriptions do not state that these modify state and create audit records. Agents need explicit 'this modifies state' warnings to plan retries correctly and understand idempotency constraints.
Tool annotations missing. No tools declare readOnlyHint, destructiveHint, or idempotentHint in their schemas. The server marks Risk labels externally (READ_ONLY, WRITE, DESTRUCTIVE), but these are not encoded in the MCP tool registration where agents can parse them. Modern MCP spec rewards tool annotations.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 44 | - | v1 |
Validate Dataverse connectivity and return user identifiers.
Parameter descriptions are minimal or absent. Example: dataverse_create_record accepts 'data' (type object) with description 'The record data to create', this tells the agent nothing about required vs optional fields, expected field names for the given table, or common errors. The OData parameter descriptions in query tools are slightly better but still lack examples of valid filters/selects.
Output schema not formally documented. Tools return structured JSON responses (via toJsonResponse helper), but the MCP tool registrations do not declare output schemas. Agents cannot know what fields to expect, is there an 'id' in the response, a 'count', a 'nextLink'? This forces agents to discover structure at runtime.
No pagination parameters. dataverse_list_tables and dataverse_query_records accept 'top' but do not expose 'skip'/'offset' or next_token/cursor. Large result sets cannot be iterated without consuming all records in one call. Pagination is essential for agents to avoid context explosion.
Error messages in callDataverse() helper do not provide recovery guidance. Example: 'Dataverse API failed (404): resource not found', the agent cannot know if the record was deleted, the table name is wrong, or the ID format is invalid. toErrorResponse() preserves the raw error but agents need actionable next steps.