Loading ToolBench
Server has 8 tools with clear naming patterns and complete input schemas. All tools start with action verbs (ping, list_, describe_, find_, query_, create_, update_, delete_). Descriptions are present and reasonably detailed (ranging from 50-250 chars). However, there are moderate gaps: output schemas are not formally documented in the code, error handling lacks recovery guidance, and parameter descriptions could be more prescriptive about constraints. The server demonstrates competent tool design but lacks the polish and consistency expected of production-grade tooling.
Create a new record in a Dataverse table.
Delete a record from a Dataverse table.
Get columns, types and descriptions for an XRM table. Call this before querying when you need to know column names for $select or $filter.
Search for a table by display name or partial logical name. Use this when the user gives a friendly name like 'hour entry' or 'hours' and you don't know the exact logical name. Returns all candidate matches from this specific environment — do not use workspace files or project notes to infer table names.
Lists Dataverse tables. Defaults to custom tables only, excluding Microsoft-prefixed solution tables (msdyn_, msfp_, adx_ etc). Use prefix='na_' to filter to a specific publisher. Use exclude_ms_prefixes=False to see all custom tables.
Output schemas not formally documented. Tools return data (dicts, lists) but the code does not specify what fields clients should expect. The _clean_record() function processes API responses but its output structure is not declared anywhere.
create_record, update_record, and delete_record have minimal descriptions (one sentence each, <60 chars). They lack context about when to use each, what the return value contains, and whether the operation is safe to retry. Especially critical for destructive operations.
No error handling guidance or recovery instructions in tool implementations. If authentication fails, API returns a 404, or input is malformed, the server will propagate raw exceptions without telling the LLM what to do next or what the constraint violation was.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | 2026-07-28+ | v2 |
Test connectivity to an XRM/Dataverse environment and verify authentication. Call this first to verify your setup and connection to the Dataverse environment.
Query records from an XRM/Dataverse table.
Update an existing record in a Dataverse table.
create_record and update_record accept an opaque 'data' object parameter with no schema constraints. The description does not specify which fields are required, what types they must be, or how nested structures should be formatted. This invites hallucinated field names and type errors.
query_records accepts a 'top' parameter with a hard cap of 5000 mentioned only in the description, not enforced in code. The description also says default is 100 but does not explain pagination, what happens if there are 10,000 matching records? No offset/page parameters or next_cursor support visible.
The 'org_url' parameter is required on every single tool, repeating the same org context across sequential calls. No session or global context mechanism is provided, forcing the agent to repeat the URL in each call and violating the 'chat-data-model' principle.
No mention of idempotency semantics. create_record and update_record do not document whether they support idempotent keys or conflict resolution. If an agent retries due to network timeout, will it create a duplicate record or safely update?
delete_record is irreversible and has no dry-run, confirmation, or soft-delete option. An agent that misidentifies a record could permanently delete it with no undo mechanism.