Loading ToolBench
A collection of MCP-compatible skills (plugins) for Microsoft Dataverse that provide tools for data operations, metadata management, configuration, and administrative tasks
The Dataverse Skills server exposes 5 authentication and client-discovery tools, but the tool definitions lack critical production-ready details. Descriptions are present but generic and lack routing hints. Input schemas are visible but lack parameter descriptions, a HARD violation of the rubric. Output schemas are entirely undocumented. No error handling guidance. The codebase is a collection of auth scripts, not a production MCP server with proper tool registration, schema validation, or recovery guidance. This server reads like internal utilities wrapped minimally for agent exposure, not tools designed for LLM instruction.
Finds an allowedmcpclient record by applicationid in Dataverse
Returns a DataverseClient with plugin attribution for SDK operations
Returns headers dict for raw Web API calls with plugin attribution
Returns a raw access token string for direct Web API calls
Loads key=value pairs from .env into os.environ without overwriting existing variables
HARD VIOLATION: Input parameters lack descriptions. 4 of 5 tools have parameters with no description text (e.g., get_client's 'skill' param, get_plugin_headers's 'skill' and 'token', find_client's 'client'). The rubric mandates: 'Every parameter needs a description explaining what it controls.' LLMs cannot infer whether 'skill' means a skill name, ID, or role without explicit text.
Output schemas are completely undocumented. None of the 5 tools document what fields they return, what types those fields have, or how downstream tools should consume the output. The rubric mandates: 'Document the output schema. LLMs need to know what fields to expect so they can plan downstream tool calls.' This forces LLMs to guess or fail on chained calls.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 37 | 2026-07-28+ | v2 |
Descriptions lack routing hints ('Use when...'). All 5 tools have minimal descriptions that explain WHAT they do, but not WHEN to select them instead of related tools (e.g., when to call get_client vs get_token, or get_plugin_headers vs get_token). The rubric baseline shows A+ tools average 194 chars with clear routing guidance; these average ~70 chars and lack context.
No error handling guidance. If load_env fails to find .env, or find_client returns no matching record, or get_token hits a rate limit, the tools provide no actionable error messages. The rubric mandates: 'Error responses must tell the LLM what to do next.' This leaves agents unable to recover from failures.
Security-critical tools lack security guidance. get_token and get_plugin_headers handle credentials and tokens. Their descriptions do NOT warn that tokens must never be logged, stored insecurely, or passed to untrusted services. The rubric mandates: 'If the tool modifies state or handles secrets, the description must say so.' No scope declarations (e.g., 'requires read:dataverse' permission).
Parameter constraints are missing or vague. 'skill' parameter (get_client, get_plugin_headers) is documented as 'The skill identifier for plugin attribution (e.g., dv-data, dv-metadata)' but is NOT constrained as an enum. LLMs will hallucinate invalid skill names. 'scope' parameter (get_token) has no format spec. 'app_id' (find_client) lacks length/format constraints.