Dataverse MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v3.9.0
Disambiguation4/5
The tool set covers many distinct resources and each tool's description is extremely detailed, often cross-referencing sibling tools (e.g., dataverse_get_import_job vs dataverse_get_import_job_results). A few pairs like dataverse_get_environment_variables and dataverse_get_environment_variable_values could be confused, but the descriptions clarify the difference between definitions and values. Overall, tools are well-differentiated.
Naming Consistency4/5
All tools follow a dataverse_ prefix with snake_case and generally verb_noun ordering (list_*, get_*, validate_*, etc.). There are minor inconsistencies like using 'get' vs 'retrieve' (get_relationship vs retrieve_unpublished) and singular/plural variance (list_solutions vs get_solution_history), but the pattern is strong and predictable.
Tool Count1/5
With 97 tools, this is far beyond the typical well-scoped range. Even for a comprehensive Dataverse server, the number is extreme, and many tools are narrow inspector endpoints that could be consolidated. It exceeds the 50+ threshold that indicates extreme mismatch.
Completeness1/5
Despite the large number of tools, the server is almost entirely read-only: it contains no create/update/delete tools for records, tables, columns, relationships, choices, forms, views, web resources, or security roles. Several referenced write tools (dataverse_create_record, dataverse_update_table, etc.) are not actually present in the tool list, leaving agents unable to perform any mutation. This is a severe gap for an administration-focused server.
Average 4.4/5 across 97 of 97 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 56 commits in the last 12 weeks
- Last stable release on August 13, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds return details (name, type, business unit) but does not disclose additional behaviors like permissions or rate limits. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. Front-loaded with the core action. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately covers purpose and return values. Lacks mention of error handling, required permissions, or validation of GUID format. Output schema exists but not described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are comprehensive for all parameters (team_id, dataverse_url, select). The tool description does not add parameter meaning beyond that. Baseline score applies due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve' and resource 'single Dataverse team' with identifier 'GUID'. It distinguishes from sibling tools like dataverse_get_user by specifying 'team'. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., dataverse_list_teams) or when not to use it. The description only states the function, lacking context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal read-only, idempotent, and non-destructive behavior. The description adds context about packages being an alternative to assemblies and automatic extraction, which is useful but not critical. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first directly states the purpose, second adds relevant background. No wasted words, and the critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and comprehensive annotations, the description is nearly complete for a simple get-by-GUID operation. It could mention the return type or format, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for all three parameters (select, package_id, dataverse_url), so description coverage is already high. The tool description adds no additional parameter information; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieve' and resource 'single plug-in package record by its GUID'. It distinguishes from the sibling tool dataverse_list_plugin_packages which lists multiple records, and from other get tools by specifying the unique resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., listing packages or getting other entities). Prerequisites, such as the need for a known GUID, are not mentioned, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds hierarchical context but no additional behavioral traits like auth requirements, error cases, or pagination (not applicable). Value added is marginal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with clear structure: core action, definition, hierarchy. No redundancy, front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given moderate complexity, annotations present, and output schema exists, the description covers purpose and context but lacks parameter details (especially with 0% schema coverage). Adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions 'by its GUID' implying image_id, but does not explain select or dataverse_url parameters. Adds little beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves a single plug-in step image by GUID. Explains what step images are and places them in the hierarchy (assembly → type → step → image), distinguishing it from list and other get tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage via hierarchy context and 'by its GUID', but lacks explicit guidance on when to use this tool vs. alternatives like list_plugin_step_images. No when-not-to-use or prerequisites stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds that the tool returns specific fields, which is useful but does not disclose other behavioral traits like pagination behavior or error handling. With annotations covering the core safety, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core purpose and then providing optional usage detail. Every sentence adds value without redundancy, making it efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of annotations, a well-defined schema, and an output schema, the description covers the essential purpose and return fields. It briefly addresses filtering but does not mention other common aspects like pagination (though top parameter exists) or ordering. This slight gap prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The context indicates 0% schema description coverage, meaning the tool's description does not explain the parameters. The description only mentions the filter parameter with an example, omitting top, select, and dataverse_url. Despite the schema having individual parameter descriptions (which are not counted in coverage by this metric), the description fails to compensate adequately for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'List business units in the Dataverse environment', clearly identifying the action and resource. It also lists the return fields (businessunitid, name, parent business unit, disabled flag, modifiedon), adding specificity that distinguishes it from other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a usage hint: 'Use filter to narrow results (e.g., "isdisabled eq false")', which helps when to apply filtering. However, it does not mention when not to use this tool or suggest alternative tools (e.g., other list tools for different entities), offering only implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds context that images are pre/post snapshots, but no additional behavioral traits such as pagination limits (handled by schema) or authentication needs. With strong annotation coverage, description adds moderate value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary purpose. No redundant words. Efficiently communicates the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a list operation with an output schema, the description is minimal but sufficient. It does not explain return values (handled by output schema) or mention that it is a read operation (annotations cover it). Could be improved by noting that step_id is optional and what happens when omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (all parameters described). The tool description only reiterates step_id usage, which is already in the schema. Adds no new parameter meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists plug-in step images, explaining they are pre/post entity snapshots. The name and description effectively distinguish it from sibling tools like dataverse_get_plugin_step_image (singular retrieval) and dataverse_list_plugin_steps (lists steps, not images).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a guideline for using step_id to scope to one step, but does not explain when to use this tool versus alternatives like dataverse_get_plugin_step_image for a single image or dataverse_list_plugin_steps for steps. Lacks when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds context about the returned fields and filtering behavior, which is useful but not critical beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at four sentences, front-loading the purpose and key guidance. It avoids redundancy and is well-structured, though could be more compact without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and comprehensive annotations, the description covers the essential purpose and filtering guidance. However, it fails to explain the 'top' and 'select' parameters, leaving some gaps for a tool with multiple parameters and an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage (despite schema containing descriptions, per context), the description only partially compensates by explaining the filter parameter. It omits details on 'top', 'select', and 'dataverse_url', leaving the agent without enough context for proper usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists teams in Dataverse, specifies returned fields, and distinguishes from the sibling tool 'dataverse_get_team' for full details. The verb 'list' and resource 'teams' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using the filter parameter to narrow results and directs users to 'dataverse_get_team' for full details, providing clear guidance on when to use this tool versus an alternative. It lacks explicit 'when not to use', but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by listing the returned fields (e.g., name, operationtype, statecode), which is beyond the annotations but does not disclose potential rate limits or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, so the description is adequate but lacks usage guidelines and parameter context. It lists many return fields, which compensates partially for the missing output schema display.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% per context, and the description does not add any detail beyond the schema's parameter descriptions. It only mentions 'by its GUID' without elaborating on parameter usage or formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve' and the resource 'asyncoperation (system job) record by its GUID', distinguishing it from sibling tools like dataverse_list_async_operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a specific GUID, but does not explicitly state when to use this tool vs alternatives like dataverse_list_async_operations, nor does it mention prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds valuable behavioral context by noting that the 'content' column is very large and should be excluded unless needed, which helps the agent avoid performance issues.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second provides a critical warning. No unnecessary words, front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one required parameter and an output schema. The description covers purpose and a key behavior, but omits parameter explanations for assembly_id and dataverse_url, reducing completeness. Adequate for the basic operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain all parameters. It only addresses the 'select' parameter (via the content warning) but does not explain 'assembly_id' or 'dataverse_url', leaving them undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a single plug-in assembly record by GUID, using specific verb and resource. It distinguishes from list siblings by emphasizing 'single' and 'by GUID', leaving no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage advice by warning about the large 'content' column and recommending exclusion unless needed. However, it does not explicitly state when to use this tool versus alternatives like dataverse_list_plugin_assemblies, leaving the guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and non-destructive. The description adds useful behavioral context by specifying the return of workflow records with statecode, statuscode, and category, and the scoping option. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and contains no extraneous information. Every word adds value, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of rich annotations and an output schema, the description is reasonably complete. It states the return type (workflow records with fields) and scoping options. However, it does not mention pagination or the top parameter, which are relevant for listing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage (tool description does not detail most parameters), the description only covers solution_id and solution_unique_name for scoping. It omits required parameter dataverse_url and optional parameters top, filter, and select, leaving their semantics to the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists cloud flows in the Dataverse environment, with optional scoping to a solution. The verb 'List' and resource 'cloud flows' are specific, and the description distinguishes this tool from siblings like 'list_processes' by explicitly mentioning 'cloud flows'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on scoping with solution_id or solution_unique_name, but lacks explicit guidance on when to use this tool versus alternatives (e.g., list_processes, query_table). It does not include when-not-to-use or compare with other listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=False, indicating a safe read operation. The description adds context about plug-in types being .NET classes but no further behavioral traits (e.g., permissions, rate limits, error handling). Since annotations cover the safety profile, the description is adequate but not enhanced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, consisting of three short sentences. It front-loads the core action, adds context, and then provides sibling guidance. Every sentence serves a clear purpose without redundancy or verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool, the description covers the essential: what it retrieves, the key identifier, and a related sibling tool. Annotations provide safety and idempotency context. It does not mention return format or error handling, but the output schema likely covers that. Overall, it is sufficiently complete for its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about parameters. Despite the input schema having detailed descriptions for 'dataverse_url', 'plugin_type_id', and 'select', the tool description does not explain their meaning or usage. With schema description coverage at 0%, the description fails to compensate, leaving the agent to rely solely on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Retrieve a single plug-in type record by its GUID.' It specifies the resource (plug-in type record) and the key (GUID). It also distinguishes itself from the sibling 'dataverse_list_plugin_types' by explicitly directing users to that tool for browsing, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Use dataverse_list_plugin_types to browse types in a given assembly.' This advises when to choose the list tool over this get tool. Although it does not cover all possible alternatives or conditions, the guidance is clear and helpful for the primary use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds value by listing returned fields and the type enum, but no additional behavioral traits are disclosed beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences with key information front-loaded: action, filter, return fields, and type enum. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description adequately covers purpose, filtering, and return data. The type enum mapping is particularly helpful. No gaps for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides detailed descriptions for all parameters (top, filter, custom_api_id, dataverse_url). The description adds only marginal clarification (e.g., 'Filters by custom_api_id'), so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists request parameter records for a Custom API, with filtering by custom_api_id. However, it does not explicitly differentiate from closely related sibling tools like dataverse_list_custom_api_response_properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (e.g., filtering by custom_api_id) but does not provide explicit guidance on when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds behavioral details: exclusion of large XML column by default and ordering by createdon descending. This is valuable context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with main action, no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with output schema and annotations, the description covers key behaviors (filtering, exclusion, ordering) that are not fully captured in structured data. May lack explicit pagination details, but schema covers 'top' parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all parameters, but the description adds meaning by explaining that the 'data' column is excluded by default (relating to the 'select' parameter) and that 'solution_name' filters results. This enhances understanding of default behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists import job records with optional filtering by solution name. It does not explicitly differentiate from sibling list tools, but the verb 'list' and resource 'import job records' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like dataverse_get_import_job or other list tools. The filtering parameter is mentioned but not contextualized with usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint; the description adds valuable behavioral details: file size threshold (~3 MB), local I/O behavior, and clarification that no DATAVERSE_ALLOW_WRITE permission is needed for disk writes. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct (two paragraphs) and front-loaded with the core purpose. Every sentence adds value, no redundant or verbose statements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has many parameters and an output schema. The description covers the main behavioral aspect (inline vs disk) but does not explain the boolean flags for export settings. For a moderately complex tool, more parameter context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must compensate. It only explains the output_path parameter and its inline/disk behavior. Other important parameters (solution_name, managed, export flags) are not described, leaving the agent to rely on schema descriptions alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Export a Dataverse solution as a base64-encoded zip.' It specifies the action (ExportSolution unbound action) and differentiates from sibling tools that are primarily 'get' or 'list' operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use output_path for large solutions and notes the tool is read-only. However, it does not explicitly exclude alternative tools or mention when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds value by specifying that the response includes expanded CustomAPIRequestParameters and CustomAPIResponseProperties, and that @odata.context is stripped. This provides more detail than annotations alone, though it does not discuss authentication or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the main purpose stated upfront and additional details in bullet points. Every sentence is informative, and there is no redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two required parameters, single record retrieval) and the presence of an output schema, the description provides sufficient context. It explains the expanded fields and a notable transformation (@odata.context stripped). It does not cover potential errors or permissions, but these are standard for such a tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters (custom_api_id and dataverse_url). The description does not add new semantic information beyond mentioning 'by its GUID', which is already in the schema. With high schema coverage, baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies that it retrieves a single Custom API record by GUID and expands request parameters and response properties. It distinguishes from siblings like dataverse_list_custom_apis (which lists all) and dataverse_get_record (which gets any record by table name).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching a specific Custom API by GUID, but lacks explicit guidance on when to use this tool versus alternatives (e.g., dataverse_list_custom_apis) or when not to use it. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds behavioral context by describing the prerequisite chain (assembly → type → step → image), which is useful for understanding operational constraints. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with a front-loaded purpose. The first sentence states the core function, and the second provides essential context (hierarchy). No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a clear purpose, annotations cover safety, output schema exists, and the description adds the hierarchical context. However, it could mention expected behavior when the GUID is not found (e.g., returns null or error) or any special handling. Still, given low complexity, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides clear descriptions for each parameter (step_id, dataverse_url, select). The tool description does not add significant new meaning beyond the schema. Given that schema descriptions are comprehensive, the description adds minimal value for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve', specifies the resource 'single SDK message processing step record', and identifies the identifier 'GUID'. It distinguishes from sibling tools like dataverse_list_plugin_steps by targeting a single record. The hierarchy note further clarifies the tool's place.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides hierarchical context (assembly → type → step → image) implying that step requires prior assembly and type, but it does not explicitly state when to use this tool vs alternatives like dataverse_list_plugin_steps or other get_ tools. No when-not-to-use or alternative names are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is fully covered. The description adds that it returns the sdkmessagefilterid but does not disclose error conditions or rate limits, which is acceptable given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and every sentence earns its place. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with robust annotations and an output schema, the description adequately explains the two usage modes and the return value. It is sufficiently complete for an agent to determine when and how to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides detailed descriptions for all parameters (100% coverage), so the baseline is 3. The description paraphrases the schema (e.g., 'Provide filter_id alone, or message_id + primary_entity together') but does not add new semantic information beyond what is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it resolves an SDK message filter to return the sdkmessagefilterid, with explicit mention of its use in dataverse_create_plugin_step. It distinguishes itself from siblings like dataverse_list_sdk_message_filters by focusing on resolving a single filter ID via two modes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides specific usage context (for scoping plugin steps) and explains the two parameter modes (filter_id alone or message_id+primary_entity). While it doesn't explicitly mention when not to use it, the guidance is clear and actionable for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds useful context about returned fields (name, business unit, managed status) without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action and resource, no redundant words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Sufficient for a simple retrieval tool with good annotations and output schema. Could mention error handling or missing GUID, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for each parameter, so the tool description does not add additional meaning. Baseline of 3 is appropriate given schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Retrieve' and the resource 'a single Dataverse security role by its GUID', distinguishing it from sibling tools like dataverse_list_security_roles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The context of sibling names implies it's for single role retrieval, but no when-not or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds value by detailing returned information (result, timing, error messages, publisher info) and explaining the msdyn_suboperation field (3 vs 5). This provides behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two short paragraphs. The first sentence delivers the purpose, the second lists return contents, and the final paragraph explains a key field. No extraneous information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not fully shown), the description covers the essential return details and provides a useful explanation of the suboperation field. However, it omits guidance on when to use the select parameter or how this tool relates to the sibling list tool, which would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides comprehensive descriptions for all parameters (dataverse_url, solution_history_id, select). The tool description does not add significant new parameter semantics beyond stating that the ID is a GUID. With high schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieve a single solution history record by its GUID,' specifying the exact verb and resource. It distinguishes from the sibling 'list_solution_histories' tool by focusing on a single record retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives like list_solution_histories. It implies usage when a specific GUID is known, but lacks explicit guidance or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. Description adds value by specifying return fields and the need for GUID, with no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: first states purpose, second covers return details and a usage hint. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, inputs, and output fields sufficiently for a simple get tool, given that output schema exists. Could mention error handling or not found scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has detailed parameter descriptions (100% coverage), so baseline is 3. Description adds marginal value by linking user_id to whoami but doesn't explain select or dataverse_url beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb (retrieve), specific resource (Dataverse system user), and identifier method (GUID). Distinguishes from siblings by mentioning dataverse_whoami for caller's UserId.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides one explicit alternative (whoami) but does not comprehensively compare to other sibling get tools like dataverse_get_record or list variants.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, meaning the description doesn't need to cover safety. The description adds value by listing returned fields and parameter behavior, but doesn't reveal additional behavioral traits beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with clear structure: purpose, return fields, and parameter guidance. Front-loaded and efficient with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, the description doesn't need to detail return values but covers key fields and the main parameter. It mentions a sibling tool for next steps. Lacks mention of pagination or the `top` parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% according to context, so the description must compensate. It explains the `include_unpublished` parameter and lists return fields, but doesn't describe `dataverse_url` or `top` beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists model-driven apps (AppModule records) and lists the returned fields. It distinguishes from sibling `dataverse_get_app` for inspecting a single app.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use `include_unpublished` and references `dataverse_get_app` for deeper inspection. While it provides good context, it could be more explicit about when to choose this listing over other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds ordering behavior ('Results ordered by name ascending') and scoping options, but does not disclose whether results are paginated or if specific permissions are required. Given annotation coverage, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences, 33 words. It front-loads the purpose in the first sentence and adds details in the second. No redundant phrases or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (covering return values) and good annotations, the description covers purpose, scoping, and ordering. It omits mentioning pagination (though 'top' parameter exists) but is otherwise complete for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has high coverage with descriptions for each parameter (e.g., 'top', 'filter', 'plugin_type_id'). The tool description adds that results are ordered by name ascending, which is not in the schema. With schema coverage high, baseline is 3, and the addition provides marginal extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List SDK message processing steps registered in the environment.' It uses a specific verb ('List') and resource ('SDK message processing steps'), and distinguishes from siblings like dataverse_get_plugin_step (singular) and other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to use: 'Use plugin_type_id to scope to one plug-in type, or message_id to scope to one message.' It also mentions ordering. However, it does not explicitly state when not to use it or contrast with alternatives like get_plugin_step for a single step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that it returns human-readable type names, which is useful behavioral context, but does not elaborate on pagination, default top value, or any rate limits. With annotations carrying the burden, this is adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences. The first sentence states the primary action, and the second provides actionable filtering guidance. Every sentence earns its place with zero wasted words. Structure is optimal for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, clear annotations, and an output schema, the description covers the essential purpose and filtering. It mentions human-readable type names and provides key type codes. It could briefly mention the default top value or that results are paginated, but these are already in the schema. Overall, it is complete enough for smooth invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema descriptions already cover all parameters (top, solution_id, dataverse_url, component_type) with full detail. The description only restates some type codes for component_type and adds the concept of human-readable names. Since schema coverage is effectively high, the description adds marginal value, warranting a baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List components within a Dataverse solution', which is a specific verb+resource combination. It distinguishes from sibling tools like dataverse_list_solutions by focusing on components within a solution, and adds value by mentioning human-readable type names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context for using the tool ('List components within a Dataverse solution') and gives explicit filtering instructions for component_type with common codes. However, it does not mention when not to use this tool versus alternatives (e.g., using specific getters for individual components) or provide any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so description adds value by explaining how results are used (for $expand and associate_records) but does not disclose additional behavioral traits beyond what annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. Front-loaded with purpose, followed by actionable guidance on using results.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers purpose, scope, and usage hints. Output schema exists so return structure is documented elsewhere. Complete for a listing tool with proper annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema provides detailed descriptions for all parameters; description does not add further parameter meaning. Baseline 3 due to high schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists relationship definitions (OneToMany, ManyToOne, ManyToMany) for a table or whole environment. It distinguishes from sibling dataverse_get_relationship by directing users to that tool for full details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (list relationships) and mentions navigation property names are needed for $expand and associate_records. Provides an alternative (use returned SchemaName with get_relationship). Does not explicitly state when not to use, but context of sibling tools makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds minimal behavioral context beyond confirming it's a read operation. No contradictions, but description doesn't expand on safety or side effects beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with the main action and resource. Each sentence adds distinct information (purpose, returned fields, filtering guidance, alternative tool). No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the tool's straightforward nature (list with filter/pagination), the description covers key aspects: what it returns, how to filter, and when to use an alternative. Leaves no major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides detailed descriptions for all parameters. The description adds value by giving concrete filter examples (e.g., 'isdisabled eq false') and clarifying default return columns, which enhances usability beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'List system users' and identifies the resource type, distinguishing it from the sibling tool 'dataverse_get_user' for full details. It lists returned fields, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on using the filter parameter to narrow results and explicitly recommends using 'dataverse_get_user' for full details on a specific user. No explicit when-not-to-use, but sufficient context for agent decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds behavioral details: it resolves type codes, gathers multiple data in one call, and optionally includes privileges and record-level checks. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences) and well-structured: first sentence states purpose, second lists components, third mentions type resolution, fourth provides usage. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, what it returns, and how to use parameters. It does not mention prerequisites or limitations (e.g., required permissions), but the output schema covers return details. Adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already contains thorough descriptions for each parameter (e.g., mutual exclusivity of user_id and user_domain_name). The tool description adds context about the composite nature but does not significantly enhance parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a composite access report for a Dataverse system user, listing specific components (identity, roles, team memberships, optionally privileges and record-level access). It distinguishes from sibling tools by positioning itself as a comprehensive single-call audit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit instructions on parameter usage (user_id or user_domain_name, optional target_entity_set_name+target_record_id) and includes_privileges. However, it does not explicitly state when to use this composite tool versus individual sibling tools (e.g., get_user, retrieve_user_privileges).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint. Description adds value by clarifying global vs. local scope, precedence behavior, and that it returns all options. No contradictions found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. Each sentence serves a distinct purpose: stating functionality and providing usage guidance with alternative. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values need no explanation. Description covers core functionality, parameter usage, and distinguishes from siblings. Missing mention of consistency_strong and dataverse_url, but these are in schema. Complete enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. Description mentions 'by name or MetadataId' and precedence rule, covering two of four parameters. Does not address dataverse_url or consistency_strong, though schema descriptions fill part of the gap. Partial compensation earns baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get one GLOBAL choice (option set) — all option values, codes, and labels — by name or MetadataId.' It uses specific verb and resource, and distinguishes from sibling dataverse_list_choice_column_options by contrasting GLOBAL vs LOCAL.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use alternative tool: 'For the options of a specific column's LOCAL choice use dataverse_list_choice_column_options instead.' Provides precedence rule for name over metadata_id. Lacks broader context like prerequisites but offers clear decision guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the returned fields and the significance of an empty connectionid, adding value beyond annotations that already indicate read-only and idempotent behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose and output, second provides a critical usage note. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description appropriately covers the key behavioral aspect (empty connectionid) and the identification methods. Could mention prerequisites like permissions, but not essential for a read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions retrieval by GUID or logical name, which aligns with parameters. However, the schema already provides descriptions for each parameter, so the description adds minimal extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a single connection reference by GUID or logical name, specifying the return fields. It distinguishes from sibling 'list_connection_references' by focusing on a single record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context on when to use update tool if connectionid is empty, guiding the agent. However, it does not explicitly state when not to use this tool (e.g., for multiple records).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive. The description adds context by listing returned fields and explaining filter parameters, but doesn't disclose pagination or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise: one line for purpose, one for returned fields, one for filters, and one for sibling guidance. No wasted words and front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return value documentation is not required. The description covers purpose, available fields, and filters adequately for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (each parameter has descriptions). The description adds value by listing common operation_type integers and clarifying state_code/status_code values, but many details are already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List asyncoperation (system job) records' and lists returned fields. It distinguishes from sibling 'dataverse_get_async_operation' by noting that tool provides full details on a specific job.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use this tool vs. the get tool: 'Use dataverse_get_async_operation for full details on a specific job.' This provides clear alternative guidance, though it doesn't explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds crucial behavioral context beyond annotations: ordering of results and the hierarchical relationship between assemblies, types, steps, and images. The annotations already declare read-only, idempotent, and non-destructive behavior, so the description's additions are valuable but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three sentences that immediately convey the purpose, ordering, and key filtering capability. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema (not shown) and detailed parameter schema, the description covers the main behavioral aspects (ordering, filtering hierarchy). It could mention that it lists all assemblies in the environment unless filtered, but overall it is sufficiently complete for a listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (all parameters have descriptive comments in the schema). The tool description does not add new parameter information beyond what's already in the schema, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The title and description clearly state the tool lists plug-in assemblies, with optional filtering. The description explicitly distinguishes from sibling tools like 'get_plugin_assembly' by implying retrieval of multiple items and providing a hierarchy hint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on ordering ('newest-modified first') and filtering options ('package_id to scope to one plug-in package'). It also outlines the prerequisite chain, helping the agent understand the data model. However, it does not explicitly mention when not to use this tool or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds ordering ('newest-modified first') and clarifies what packages are (NuGet-based, alternative to assemblies), providing useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two front-loaded sentences with no filler: the main action is stated first, followed by ordering and alternative role. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose, ordering, and the role of packages vs assemblies. It does not detail pagination or filtering, but the schema and output schema compensate. For a read-only list tool, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter details beyond the input schema, which itself includes descriptions for all parameters. Per the rule, with high schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('NuGet-based plug-in packages'), and the scope ('in the environment'). It also distinguishes from raw assemblies, and the sibling 'dataverse_get_plugin_package' contrasts as a single-item retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that packages are an alternative to raw assemblies, providing context on when to use. It does not explicitly state when not to use or list alternatives, but the hint is sufficient for an informed agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds the ordering (by typename ascending) and the prerequisite chain, which are behavioral traits not covered by annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the main purpose, no redundant information. Every sentence adds value: purpose, scoping, ordering, and prerequisite context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values are covered. The description includes the prerequisite chain, which helps agents understand context. It could mention filtering options like typename_contains or is_workflow_activity, but these are in the schema, so it is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema descriptions are comprehensive (e.g., 'GUID of a pluginassembly; return only types in that assembly'). The description adds only the ordering detail (ascending by typename), which is a minor addition. Baseline 3 is appropriate since schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists plug-in types (.NET classes) registered in the environment, using a specific verb 'List' and resource 'plug-in types'. It distinguishes from sibling tools like dataverse_get_plugin_type (single) and dataverse_list_plugin_assemblies (different entity).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions using assembly_id to scope results, providing context for when to filter. It also places the tool in a prerequisite chain (assembly → type → step → image). However, it does not explicitly state when not to use this tool or list alternatives, so it loses one point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, idempotent, non-destructive. Description adds specific returned fields and filter behavior, enhancing beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise lines, front-loading purpose and key details with no superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present and thorough annotations, the description covers essential usage without gaps; minor missing details like pagination are not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides descriptions for all parameters (100% coverage), so description adds no additional parameter insight beyond mentioning default select columns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('List security roles') and the resource ('Dataverse environment'), and distinguishes from sibling dataverse_get_security_role for full details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions using filter to narrow results and directs to dataverse_get_security_role for specific roles, providing clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, etc. The description adds the filtering behavior and output fields but does not mention pagination or that results might be limited by the top parameter. Some useful context beyond annotations, but not extensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that efficiently cover purpose, usage, and alternative. No redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and comprehensive annotations, the description covers the key points: purpose, filtering, and alternative tool. It could mention pagination or the required dataverse_url, but these are in the schema. Sufficient for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions the filter parameter, but the input schema already provides thorough descriptions for all parameters (top, filter, select, dataverse_url). The description adds minimal additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List solutions') and the resource ('in the Dataverse environment'), and specifies the output fields (name, version, managed status). It distinguishes itself from siblings like dataverse_get_solution by indicating it's a broad listing tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using the filter parameter with an example, and directs to dataverse_get_solution for full details. This provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, idempotent, and non-destructive behavior. Description reinforces by stating it returns metadata and does not modify data. Adds context about return fields beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each serving a clear purpose: purpose, return fields, filter guidance, and cross-reference. No redundancy, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers return metadata and filtering adequately. For a list tool with output schema, it is sufficiently complete. Could mention default top value or pagination, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds minimal value over input schema descriptions. It lists filter options concisely, but the schema already provides equivalent detail. No additional parameter context beyond existing schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists saved views (savedqueries) and returns specific metadata fields. It differentiates from sibling tools like dataverse_get_view, which retrieves layout details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains filtering by table_logical_name and query_type with value mappings. Suggests using dataverse_get_view for layout, providing context on when to use an alternative. Lacks explicit exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds that the tool returns RolePrivilege objects with PrivilegeName and Depth, and that privileges come via roles. This provides additional behavioral context beyond the annotations, but does not cover potential side effects or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the core purpose, followed by output details and a usage hint. Every sentence adds value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (implied), the description adequately covers what the tool does, what it returns, and how to obtain the required user ID. It lacks discussion of permission requirements or pagination, but these are minor given the tool's simplicity and the presence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description does not mention any parameters; however, the input schema provides clear descriptions for both user_id and dataverse_url. Since schema coverage is high (100% for the two parameters), the description adds no extra parameter semantics, earning a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves all security privileges assigned to a user via their roles. It specifies the resource and action distinctly from sibling tools like dataverse_get_user or dataverse_audit_user_access. The mention of returning RolePrivilege objects reinforces its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool provides a usage tip to use dataverse_whoami to get the caller's UserId, which guides when to use this tool. However, it does not explicitly exclude alternatives or state prerequisites, leaving some gaps for an AI agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds return value structure (valid=true/false with control list or error list) and notes automatic validation by write tools, complementing annotations (readOnlyHint, idempotentHint) without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences front-load purpose and modes, with no wasted words. Each sentence adds value, and structure is logical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers two modes, return values, and automatic validation. With an output schema present, the description is sufficiently complete for this focused validation task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description does not directly describe parameters, but the input schema provides detailed descriptions for all three parameters (form_id, formxml, dataverse_url). Tool description adds implicit context for formxml via modes, meeting baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates FormXml against XSD-derived rules, specifying two modes and distinguishing itself from siblings like dataverse_validate_view through the FormXml focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes two modes (dry-run with formxml, fetch live form without) and mentions automatic validation by write tools, providing clear context for when to use this tool, though no explicit exclusions or alternatives are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, establishing safety. The description adds behavioral details beyond annotations: it fetches live XML, checks structure according to 16 rules, and skips layout rules when layoutxml is null. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: first states primary action and rule count, second details the rule breakdown, third provides usage context about automatic execution. No redundancy, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown), the description is complete enough for a validation tool with 1 required param and no nested objects. It covers behavior, rule structure, and usage context. Could mention output format briefly, but output schema fills that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema includes descriptions for both parameters (view_id as GUID, dataverse_url as URL). The description does not add new parameter semantics beyond the schema. With schema descriptions present, baseline is 3; the description adds minimal contextual value (e.g., 'fetches the live XML' linking to view_id).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it validates a Dataverse view's FetchXml and LayoutXml against 16 structural rules, specifying the rule groups (1-8, 9-15, 16). It distinguishes from sibling tools like dataverse_get_view (retrieval) and other validation tools (dataverse_validate_app, dataverse_validate_formxml) by its specific validation scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use this tool: as a standalone pre-check before write operations, noting that write tools automatically run this before every PATCH. It implies when not to use (when doing a PATCH, automatic) but does not explicitly list alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. Description adds that it returns metadata and components grouped by type, providing behavioral context beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each serving a distinct purpose: stating purpose, directing to prerequisite tool, and advising usage timing. Front-loaded with key information, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description sufficiently covers purpose, input provenance, and usage timing. No missing critical information for a read-only retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema includes descriptions for both parameters, but context reports 0% coverage. Description adds value by guiding use of dataverse_list_apps for finding app_ids, but does not elaborate on dataverse_url or app_id format beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Get', the resource 'model-driven app', and what it returns (properties and component list grouped by type). References specific API (RetrieveAppComponents) and distinguishes from sibling dataverse_list_apps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly directs to use dataverse_list_apps to find app IDs and advises calling this tool before any write operation. Does not explicitly state when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the annotations, including the fallback to defaultvalue when value is null, the order of name lookup (schema name first, then display name), and the scoping mechanism via componenttype 380. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, starting with the main purpose, then detailing output structure and parameter usage. It is concise for the amount of information conveyed, with no unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and the tool has few required parameters, the description provides enough detail about output format, parameter interactions, and edge cases (null value) to use the tool effectively. Minor gaps around pagination are covered by the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema itself already describes each parameter, and the tool description reinforces key rules about mutual exclusivity and lookup order. However, it does not add new information for parameters like top or dataverse_url, and the low schema coverage (0%) means more responsibility on the description, which it partially meets.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists environment variable definitions with their current values, and distinguishes itself from similar tools (e.g., dataverse_get_environment_variable_values) by detailing the merged output structure. It uses specific verbs and resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use the name parameter versus solution scoping, and explicitly states that name cannot be combined with solution parameters. It does not directly compare with sibling tools, but the context is sufficient for correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context beyond annotations by specifying 'Returns full details including version, publisher, and managed status'. No contradiction with readOnlyHint or other annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three succinct sentences: purpose, return details, parameter constraint. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, description suffices by stating key return fields and parameter requirements. No critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes each parameter (coverage 100% in actual schema, though context says 0% likely incorrect). The description adds the constraint 'not both', which clarifies usage beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Retrieve a single Dataverse solution by its unique name or GUID', specifying verb and resource. Distinguishes from sibling tools like dataverse_list_solutions and dataverse_export_solution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides the essential constraint 'Provide solution_unique_name or solution_id — not both' but lacks explicit guidance on when to use this tool over siblings that list or export solutions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description complements annotations (readOnlyHint, idempotentHint) by detailing output structure: parsing FetchXml/LayoutXml, backup fields, and special handling for Quick Find views. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five concise sentences, each adding unique information: purpose, parsing details, backup fields, Quick Find behavior, and sibling tool reference. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers purpose, usage, output specifics, and prerequisite. For a read-only tool with output schema, no critical gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions already clearly define view_id and dataverse_url parameters. Description does not add additional semantic meaning or constraints beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves a single Dataverse view's layout as structured JSON, with specific verb 'Get' and resource 'view'. It differentiates from sibling dataverse_list_views by explicitly advising to use that tool for discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using dataverse_list_views to discover view IDs, providing a clear prerequisite. Describes output features (columns, sort, filters, quick_find_fields) but lacks explicit when-not-to-use guidance for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint=false. The description adds valuable behavioral context: records are populated within 30-60 minutes, all fields are read-only, and specifies the exact metrics returned. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at four sentences, with the main purpose in the first sentence followed by supporting details. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is an output schema to define return values, the description covers the key aspects: what metrics are returned, latency, filtering options, and use case. It is complete for a filtered listing tool with good annotation support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the purpose of plugin_type_id and include_plugin_type_details, adding meaning beyond the schema. However, it doesn't mention the 'top' parameter or 'dataverse_url'. Schema descriptions exist for all parameters, but the tool description only covers two of the five parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists runtime performance statistics for Dataverse plug-in types, specifying exactly what metrics are returned (execution counts, failure rates, crash metrics, contribution percentages). It distinguishes itself from sibling tools like dataverse_list_plugin_types by focusing on performance statistics rather than just listing types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: to identify slow, high-failure, or crash-prone plug-ins before investigating further. It mentions filtering options and a follow-up action (Power Platform Admin Center). However, it doesn't explicitly say when not to use it or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to restate safety. The description adds context that this tool is used for discovery, but does not disclose additional behavioral traits such as pagination, authorization needs, or performance implications. The bar is lower due to annotations, but the description offers no extra transparency beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences. The first sentence states the core purpose, and the second provides usage context with examples. No redundant or irrelevant information is included, and the key details are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so the description does not need to explain return values. The description adequately covers when to use the tool and how its output feeds into another tool. Given its simplicity and the presence of annotations, the description is complete and sufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides detailed descriptions for all parameters (top, filter, select, dataverse_url, name_contains). Despite the context signal of 0% schema description coverage, the actual schema has clear descriptions. The tool description does not add parameter-level meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool as listing SDK messages, which are the catalog of operations plug-in steps can intercept. It distinguishes the tool from its sibling dataverse_get_sdk_message by stating it is used to discover valid message names before resolving a message_id, preventing overlap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: to discover valid message names (e.g., 'Create', 'Update', 'Assign') before calling dataverse_get_sdk_message. It provides a clear workflow and implies when not to use it (i.e., not for resolving specific message IDs).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint; description adds context about OData capabilities (filtering, ordering, expansion) and payload advice. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is two short paragraphs, front-loaded with purpose and usage. No redundant sentences, though could be slightly more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description covers main capabilities, sibling differentiation, and usage advice. Adequate completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema provides detailed descriptions for all parameters (coverage 100%); description adds general advice on 'select' but does not enhance semantics beyond what schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries records from a Dataverse table with OData filtering, ordering, and expansion. It distinguishes from siblings by explicitly naming alternatives for single records, counts, aggregation, and CRUD operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool vs alternatives (e.g., 'For a single record by GUID use dataverse_get_record') and advises on best practice ('Always specify select to limit returned columns').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive. Description adds that validation errors prevent publishing, which is important behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose, second provides additional context and usage. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, output schema present), the description fully covers what an agent needs: purpose, implications, and workflow integration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides descriptions for both parameters (app_id and dataverse_url). Tool description adds no extra parameter details, so baseline 3 is appropriate given schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it validates a model-driven app and returns errors/warnings, using ValidateApp to check for missing components. Distinct from sibling tools like dataverse_validate_formxml.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises running before dataverse_publish_app to catch errors early, providing a clear workflow context. Does not explicitly mention when not to use, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context beyond annotations (readOnlyHint, idempotentHint) by specifying the returned fields (UserId, BusinessUnitId, OrganizationId) and the purpose (authentication confirmation). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the purpose and include usage guidance. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple identity check tool with one parameter and an output schema, the description provides all necessary information: what it does, when to use it, and what it returns. Complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter (dataverse_url) is already well-described in the input schema. The tool description adds no additional meaning, but schema coverage is adequate, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Return the authenticated caller's identity' using a specific verb and resource, and distinguishes itself from siblings like dataverse_get_user by focusing on the current session's identity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends calling 'at session start to confirm authentication' and for privilege checks, providing clear context. Does not mention when not to use or alternatives, but the usage is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the behavioral context that this is a pre-validation step returning a boolean 'eligible' for the requested check_type. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loading the primary purpose in the first sentence, then providing usage timing, return type, and sibling differentiation in subsequent sentences. No filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the strong annotations and existing output schema, the description is complete for its intended pre-validation use. It explains when to use it, what it returns, and which alternative to use when the table is unknown, covering all necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% from the tool description; it only points to 'check_type field for valid values' and does not describe dataverse_url or table_logical_name. Although the schema itself contains detailed descriptions, the description fails to compensate for the low coverage, adding minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool pre-validates whether a table supports a specific relationship role with a clear verb and resource. It distinguishes itself from sibling dataverse_get_valid_relationship_entities by contrasting 'is THIS ONE table OK?' (boolean check) versus 'WHICH tables are OK?' (enumeration).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to call only immediately before dataverse_create_one_to_many_relationship or dataverse_create_many_to_many_relationship, and not for general queries or data reads. It also names dataverse_get_valid_relationship_entities as the alternative for when the specific table is unknown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent. Description adds paging behavior (cookies, one page + metadata) and differences from OData. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with the main purpose, no redundant or extra words. Efficiently conveys key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of output schema and annotations, the description covers all essential context: paging, sibling tool differentiation, and entity name discovery. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description does not mention any parameters despite 0% schema description coverage. However, the input schema provides descriptions for each parameter. The description misses an opportunity to add meaning beyond the schema, but schema covers it. Score 2 due to missing parameter help.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool executes a FetchXML query and returns records. It clearly distinguishes from dataverse_query_table for simple OData and provides guidance to discover entity_set_name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance: suggests using dataverse_query_table for simple queries and dataverse_get_entity_sets for entity name discovery. Also clarifies FetchXML supports complex joins and aggregation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only and idempotent. The description adds important behavioral details: the return shape is always a list with records/count/has_more, even for single records, and describes behavior when no records exist. It also explains name resolution priority, providing transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line purpose, a bullet-like list of targeting paths, and a short note on return shape. Every sentence adds value, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of a comprehensive input schema and output schema, the description adequately covers usage scenarios, return shape, and edge cases (empty list). It could be improved by mentioning that the tool only retrieves values for a single definition at a time, but overall it is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all parameters, including mutual exclusivity. The description adds value by explaining the order of name resolution (schema name first, then display name) and consolidating the targeting paths. With high schema coverage, the baseline is 3, and the additional context justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as retrieving environment variable value records, and distinguishes it from the sibling tool dataverse_get_environment_variables which retrieves definitions. It specifies three targeting paths, making the action and resource unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states that exactly one targeting path must be provided, outlines each path's use case, and notes the consistent return shape. However, it does not explicitly state when not to use this tool or compare it to alternatives beyond the sibling name, which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds value by detailing the return values (off, exception, all) beyond the annotations but does not cover all behavioral aspects (e.g., rate limiting).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient, with three concise sentences that front-load the purpose, then provide return details and sibling references. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of this read operation, the description is complete: it explains the purpose, return values, and relationship to sibling tools. The output schema likely covers return structure, so no additional explanation needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite schema description coverage being 0% per context, the description does not add any semantics for the single parameter dataverse_url beyond what the schema already provides (which is a basic URL format). The description fails to compensate for the documented 0% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the current plug-in trace log setting for the organization, using specific verbs and resource. It distinguishes from sibling tools by naming dataverse_set_plugin_trace_log_setting and dataverse_list_plugin_trace_logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool (to get the setting) and mentions specific alternatives for changing or reading logs, providing excellent guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate it is read-only, idempotent, and non-destructive. The description adds that it returns 'full metadata' including cascade configuration and navigation properties, and frames it as a precursor to updates, conveying additional behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: the first states the purpose with key details, the second provides crucial usage guidance. Every word is necessary; no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, good annotations, and existing output schema, the description covers the core purpose and usage workflow. It could optionally mention the 'consistency_strong' parameter, but the schema handles that. Overall, it is sufficiently complete for a read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description does not explicitly describe any parameters (0% coverage per context). However, the input schema provides detailed descriptions for each parameter, so agents can infer semantics from the schema. At baseline 3, the description adds no extra value but does not hinder understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves full metadata for a single relationship by schema name, specifying cascade configuration and navigation properties. It distinguishes itself from sibling tools like 'dataverse_list_relationships' by focusing on a single relationship and providing detailed definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states that schema names are case-sensitive and advises using the exact SchemaName from 'dataverse_list_relationships'. It also instructs to use this tool before updating with 'dataverse_update_relationship', providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it lists only global choices, does not return option values/labels, and notes that $filter is unsupported. This complements annotations (readOnlyHint, idempotentHint) without contradiction, giving the agent a clear understanding of what the tool does and does not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences) with the main purpose front-loaded. Every sentence adds value: defining the resource, stating what is not included, and noting technical constraints. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers purpose, missing data (options), and limitations, it fails to address the parameters. Given the existence of an output schema (not shown), return format is covered. However, the absence of parameter guidance, especially with 0% schema coverage, leaves the agent underinformed about required and optional inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema_description_coverage at 0%, the description must compensate by explaining parameter usage. However, it provides no information about parameters like 'top', 'select', 'dataverse_url', or 'consistency_strong'. The agent must rely solely on the input schema, which lacks descriptions per the context. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'GLOBAL choice (option set) definitions', and specifies the scope ('in the Dataverse environment'). It explicitly distinguishes from 'dataverse_get_choice' for full option sets, making purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: when to use (list global choices), what not to expect (no option values/labels, with alternative), and technical limitations ($filter unsupported, top client-side). This clearly differentiates from sibling tools like 'dataverse_get_choice' and 'dataverse_list_choice_column_options'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe read operation. The description adds value by detailing the returned fields and providing enumeration mappings for bindingtype and allowedcustomprocessingsteptype, which are not in the schema. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with five sentences that efficiently cover purpose, returned fields, filter usage with examples, enum mapping, and a sibling tool reference. No redundant or unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description sufficiently covers purpose, filter usage, and sibling tool. The schema handles parameter details and the output schema presumably covers return values. Minor omission: no mention of pagination via the top parameter, but it's documented in the schema. Overall, adequate for a list tool with good annotations and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all three parameters, so the baseline is 3. The description goes beyond by giving concrete filter examples and explaining the numeric values for bindingtype and allowedcustomprocessingsteptype, which are not explained in the schema. Thus it adds meaningful semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'List Custom API records' which clearly specifies the verb and resource. It lists the specific fields returned, distinguishing it from sibling tools like dataverse_get_custom_api, which is explicitly mentioned for fetching detailed data for a single API. This makes the purpose highly specific and distinguishable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use the filter parameter with examples, and explicitly directs users to dataverse_get_custom_api for expanded details of a specific API. While it does not state when not to use this tool, the context is clear enough for the agent to make decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, idempotentHint, etc. Description aligns and adds context: returns specific metadata fields and filtering behavior. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three focused sentences: purpose, output description, filtering instructions. No extraneous content, efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main functionality, filtering options, and output fields. Output schema exists, so return details are handled. Missing pagination parameter 'top' is a minor gap. Annotations reduce need for behavioral detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%. Description explains form_type and table_logical_name filtering and common values, but omits 'top' (pagination) and 'dataverse_url' requirements completely. Provides partial but not full parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'List' and resource 'forms'. Description specifies the action, what metadata is returned, and distinguishes from sibling 'dataverse_get_form' which inspects a form's layout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains filtering by table_logical_name and form_type with common values. References sibling for deeper inspection. Lacks explicit 'when not to use' but provides solid usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false), the description adds critical behavioral traits: HTTP 200 does not imply validity, severity mapping is observed not documented, unknown severities are treated as errors, raw_response is returned unchanged, and the local XML parser rejects DTDs/entities. This exceeds what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but front-loaded with a crisp one-sentence purpose, followed by logically grouped paragraphs covering behavior, output shape, and edge cases. Every paragraph serves a distinct function, though some details (e.g., severity mapping) could be condensed without losing meaning. Overall it is well-structured and information-dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description generously explains the response shape: count, error_count, warning_count, has_errors, errors, raw_response, and the normalized=false fallback. It also covers edge cases like HTTP 414 and non-200 validation errors. For a tool with this complexity and safety-critical validation semantics, the description is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema includes exhaustive descriptions for both fetch_xml and dataverse_url, including encoding constraints and shortening advice. The tool description adds a small contextual note about the root <entity name="..."> identifying the table, but this is also present in the schema. Since schema description coverage effectively handles parameter semantics, the tool description provides marginal added value, matching the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Check a FetchXML query for problems and performance warnings WITHOUT running it', clearly identifying the verb (check), resource (FetchXML query), and distinguishing it from executing the query. It explicitly names the sibling dataverse_execute_fetchxml as the companion tool, making the tool's unique role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: 'Run it before executing an expensive or machine-generated query' and names dataverse_execute_fetchxml as the alternative when execution is desired. However, it does not mention when not to use it (e.g., for View XML) or list alternative validators like dataverse_validate_view, so it lacks explicit exclusions but still provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds valuable behavioral context: works on up to 50,000 records, lookup fields cannot be used in groupby, and correct use of 'countdistinct'. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with purpose, each sentence adds value. No unnecessary words. Efficiently communicates key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown) and thorough annotations, the description covers usage context, constraints (50k limit), and examples. No missing critical information for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema describes all parameters with coverage 0% (per context), but each parameter has a description in schema. Description adds examples for the apply parameter but does not elaborate on other params. Baseline 3 is appropriate as schema already provides meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool groups and aggregates Dataverse records using OData $apply. It explicitly distinguishes from siblings: dataverse_count_records for single total count and dataverse_query_table for raw rows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear when-to-use (per-group questions like count by status, sum by region) and when-not-to-use (single total count or raw rows), with explicit sibling tool alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with annotations (readOnlyHint, idempotentHint, etc.) and adds behavioral context by explaining the three dependency directions and the need for component_type and component_id. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (7 lines) and well-structured with bullet points, making it easy to scan. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to detail return values. It covers all necessary aspects: purpose, parameters, direction options, and example codes. The tool is adequately documented for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the input schema by explaining the meaning of component_type integer codes and providing a link to documentation. The schema's property descriptions are already present, but the description clarifies usage via examples and context for the direction parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: analyzing dependencies for a Dataverse solution component. It distinguishes from siblings by focusing on dependency analysis rather than listing or retrieving records, and elaborates on three specific dependency directions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each direction parameter, providing clear context for selecting the appropriate analysis type. However, it does not explicitly state when not to use this tool or mention alternative tools that might be more appropriate for specific scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, not destructive. Description adds the 5,000 cap and confirms only integer returned, providing additional behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, no redundant information. Efficiently conveys when to use and key constraint (cap).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations and output schema present, the description is sufficient: it explains the output (integer total) and the cap. No missing details for a simple count tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions provide parameter details (e.g., filter expression, URL, entity set name). The tool description does not add parameter semantics, but the schema covers them, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool counts records in a table and returns only the integer total. It distinguishes from dataverse_query_table (returns rows) and dataverse_aggregate_table (per-group counts).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool over siblings: use instead of dataverse_query_table when you need a number, not rows; use dataverse_aggregate_table for per-group counts. Also mentions the 5,000 cap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, indicating a safe read operation. The description adds value by explicitly stating the auditing requirement and the polymorphic return types, which are important behavioral details not covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (5 sentences), well-structured, and front-loaded with the main purpose. It lists common subtypes in a clear, scannable format without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotations and the presence of an output schema, the description covers all necessary context: purpose, return types (polymorphic subtypes), prerequisites (auditing enabled), and parameter origin. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for both parameters (audit_id and dataverse_url). The description further clarifies that audit_id comes from listing or change history tools, adding helpful context beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieve full details from a single audit record' and explains the function call, subtypes, and scope. It distinguishes from sibling tools like dataverse_list_audit and dataverse_retrieve_record_change_history by focusing on full detail retrieval for a single audit record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes the prerequisite of auditing being enabled and the required audit_id format. It implicitly indicates when to use (when full details of a specific audit record are needed), but does not explicitly list when not to use or compare to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds value by explaining the return value's role as a complete definition for updates and hinting at type-specific properties. It does not contradict annotations and provides behavioral context beyond structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at 70 words, structured in three focused paragraphs. It immediately states the purpose, then details return properties and usage context. Every sentence is informative with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of a robust input schema, annotations, and output schema, the description covers all necessary context: purpose, return content, update workflow linkage, and alternative tool for picklists. No gaps remain for an agent to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema itself provides comprehensive descriptions for all parameters, including format hints like 'Use lowercase.' The tool description adds no additional parameter semantics beyond what the schema already covers, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves full metadata for a single column, including type-specific properties. It differentiates from sibling tools like dataverse_list_columns and dataverse_update_column by specifying its role as a prerequisite for updates and by directing picklist queries to a separate tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'Use before updating a column — pass the returned object as full_definition to dataverse_update_column.' Also advises using dataverse_list_choice_column_options for picklist option values, clearly indicating when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive. Description adds that it's faster/smaller than alternatives, which is useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise: four sentences with no waste. Main purpose front-loaded, followed by usage guidance and a tip. Perfectly sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a discovery tool with output schema. Covers purpose, usage context, filter mechanism, and performance benefit. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides full parameter descriptions (100% coverage by inspection). Description only mentions filter usage, adding minimal value over schema. Baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb ('list') and resource ('EntitySet names from the Dataverse service document'). Provides example mappings and distinguishes from siblings by focusing on discovery before querying.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (before querying records) and why it's better than fetching $metadata. Mentions filtering capability, giving direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds value by explaining that the tool parses raw FormXml into a structured tree and returns raw XML backup, helping agents understand the output. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with purpose, followed by transformation detail and usage guidance. No extraneous content; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and clear annotations, the description covers all essential aspects: what the tool does, how it transforms data, and how to discover form IDs. No gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema already provides clear descriptions for both parameters (form_id with GUID example, dataverse_url with example). The tool description does not add further parameter details, but the schema coverage is high, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves a single Dataverse form's layout parsed as structured JSON, distinguishing it from sibling tools like dataverse_list_forms which discover form IDs. The verb 'Get' and resource 'form layout' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells agents when to use this tool (to get parsed form layout instead of raw XML) and directs them to use dataverse_list_forms to discover form IDs, providing clear guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description does not contradict and is consistent. It adds no new behavioral info, but for a simple read tool the annotations suffice. No issues.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences that front-load the purpose and then provide crucial workflow guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple record fetch tool with an output schema and rich annotations, the description covers the necessary workflow (when to use this vs query_table) and is complete. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema includes descriptions for each parameter, so schema coverage is high. The description does not add any extra meaning beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieve a single Dataverse record by its GUID.' It uses a specific verb and resource, and distinguishes from sibling dataverse_query_table for multiple records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use dataverse_query_table first to find record IDs if you do not have one.' This provides clear when-to-use guidance and exactly when to use the sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating safe read-only behavior. The description adds valuable context about the exact mapping (name to ID) and its role in plugin step creation, going beyond what annotations provide. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a concise requirement line. It immediately states the core function and use case, with no fluff. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (a lookup with two optional parameters) and the presence of an output schema (mentioned), the description covers the essential purpose, input constraints, and usage context. It is complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema provides descriptions for each parameter (100% coverage by default), the description adds a crucial constraint: 'Provide message_name OR message_id — exactly one required.' This clarifies the mutual exclusivity, which is not enforced by the schema (both are optional individually). Thus it adds meaningful guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'resolve', the resource 'SDK message', and the specific output 'sdkmessageid'. It also mentions the downstream use case (required by dataverse_create_plugin_step), distinguishing it from sibling tools like dataverse_list_sdk_messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this to get the message_id required by dataverse_create_plugin_step' and specifies 'Provide message_name OR message_id — exactly one required.' This gives clear context for when to use. It could benefit from stating when not to use, but it is already effective.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it specifies the returned attributes and explains the consistency_strong parameter's caching behavior and performance implications. This aligns with readOnlyHint, idempotentHint, and destructiveHint annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with four sentences, front-loaded with purpose. Every sentence adds value, including return values and prerequisite guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (implied by context), the description adequately covers the tool's purpose, return values, and parameter behavior. It is complete for a read-only metadata retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes all three parameters (table_name, dataverse_url, consistency_strong) with individual descriptions. The tool description does not add parameter-level meaning beyond the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves schema details for a single Dataverse table by logical name, specifying the return values (entity set name, primary key, primary name attribute). This distinguishes it from sibling tools like dataverse_list_tables which list available tables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs users to use dataverse_list_tables to discover table logical names, providing a clear prerequisite. However, it lacks explicit guidance on when not to use this tool or direct comparison with other get_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is read-only, open-world, idempotent, and non-destructive. The description adds valuable behavioral detail beyond annotations: it lists the specific fields returned (SchemaName, LogicalName, KeyAttributes, EntityKeyIndexStatus) and clarifies that EntityKeyIndexStatus tracks async index build progress. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: 4 sentences total. The first sentence states the core purpose, the second gives usage context, the third enumerates return fields, and the fourth provides a cross-reference to a sibling tool. Every sentence adds unique value, with no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (few parameters, read-only nature, and presence of output schema), the description covers all necessary aspects: what it does, what it returns, a practical usage hint, and a connection to a related tool. It does not need to explain return values as the output schema presumably does. The description feels complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all three parameters (dataverse_url, table_logical_name, top). The description does not add any additional semantic information about these parameters. Since schema coverage is high (descriptions exist in schema), the baseline is 3, and the description adds no extra value here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: 'List alternate keys (EntityKeyMetadata) defined on a Dataverse table.' The verb 'list' and the target 'alternate keys' are precise. Among siblings like dataverse_list_views or dataverse_list_tables, this uniquely identifies a distinct resource type, so the tool is well differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the purpose of alternate keys ('let integration tools upsert records by business values instead of GUIDs'), giving context for when to use the tool. It also advises to use the LogicalName output with dataverse_delete_alternate_key for removal. However, it does not explicitly state when not to use or compare to other list tools, though the uniqueness of the resource makes that less critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds that the tool requires auditing enabled and may return empty or error if disabled. It also explains the meaning of operation and action codes. This adds behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line summary, a bullet-like list of columns, usage guidance, and a prerequisite note. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and rich annotations, the description covers the tool's purpose, parameters, usage context, and a related alternative. It is fully adequate for an AI agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already contains detailed descriptions for each parameter (e.g., filter examples, default values). The description provides an overview of common columns but does not add significant meaning beyond what the schema provides. Since schema coverage is effectively complete, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries the audit table with OData filters and returns audit records. It lists common columns and distinguishes from the sibling tool dataverse_get_audit_details, which fetches detailed before/after values. The purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly tells when to use this tool and when to use the alternative dataverse_get_audit_details. It also warns that auditing must be enabled, and describes the consequence if disabled. This provides clear context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true, covering safety. The description adds behavioral details: it handles both Picklist and MultiSelectPicklist automatically and emphasizes local vs global scope. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with the core purpose, and contains no redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (local vs global, dual column types, OData filter integration), the description is complete. It covers use case, alternatives, and automatic handling, and an output schema exists so return value explanation is unnecessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema itself provides descriptions for all parameters, so baseline is 3. The tool description adds minimal extra parameter meaning beyond the schema (e.g., mentioning that integer values are required for filters, but this is not directly a parameter clarification).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the specific resource 'option values and labels for a Picklist or MultiSelectPicklist column's LOCAL option set,' distinguishing it from the sibling tool dataverse_get_choice for global choices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool ('before filtering records with choice columns'), explains the need for integer values in OData filters, and directs users to dataverse_get_choice for global options, providing clear alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint as false. The description adds value by listing the returned fields and explaining the type enum values (0-12). It does not contradict annotations and provides specific behavioral details about the output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences. It front-loads the purpose, then explains filtering, and finally lists returned fields and enum mappings. Every sentence adds essential information without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotations (readOnlyHint, etc.) and the presence of an output schema, the description adequately covers purpose, filtering criteria, return fields, and type enum. It does not need to explain pagination as the schema covers the 'top' parameter. The description fills gaps not covered by structured fields, making it complete for this simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already includes descriptions for all parameters (dataverse_url, custom_api_id, top, filter) with details like bounds and default values. The description adds value by explaining the enum values for the 'type' field in the response, which is not in the schema. Since schema coverage is high (100% for parameters), the description enhances understanding without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the specific resource 'response property records for a Custom API.' It distinguishes from sibling tools like dataverse_list_custom_apis or dataverse_list_custom_api_request_parameters by specifying it returns properties belonging to a Custom API.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that the tool filters by custom_api_id and allows an optional OData filter. It implicitly indicates usage when needing to list response properties of a specific Custom API. However, it does not explicitly state when not to use this tool or mention alternatives, but the context is clear given sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds context: uses Power Platform admin API, returns instance_url which is the dataverse_url for other tools. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only four sentences, front-loaded with the main purpose, and every sentence adds value. No redundant or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (listing with two optional booleans and no output schema), the description is complete: it explains what it does, when to use it, what it returns (instance_url), and how it feeds into other tools. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters (expand_addons and expand_capacity). The main description does not add parameter-level details, but given the schema's high coverage (100% for param descriptions), a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List Power Platform environments available to the authenticated user', using a specific verb (list) and resource (environments), and distinguishes from sibling tools that operate on Dataverse entities by mentioning the admin API and that no dataverse_url is required.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use this to discover environments before calling environment-specific Dataverse tools', and provides a key differentiator (no dataverse_url required). This gives clear guidance for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint false. Description adds that records are ordered newest-first and returns trace/exception information. No contradictions, and the additional ordering detail is valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with clear paragraphs: purpose, return info, useful filters list, and prerequisite notes. Slightly verbose with bullet-like formatting, but front-loaded and efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity of 8 parameters, presence of output schema, and sufficient annotations, the description covers filters, ordering, and prerequisites. It could mention pagination (top parameter behavior), but output schema likely covers return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the tool description provides detailed explanations for key parameters (e.g., partial match for type_name, examples for hours_ago and message_name, exclusion filter for exceptions_only). This adds significant meaning beyond the schema's parameter names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states 'List plug-in trace log records with optional filters', clearly identifying the verb and resource. It distinguishes from sibling tools like dataverse_get_plugin_trace_log_setting and dataverse_set_plugin_trace_log_setting by focusing on listing logs with filters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides explicit usage guidance: prerequisite to enable logging via dataverse_set_plugin_trace_log_setting, and how to check setting with dataverse_get_plugin_trace_log_setting. It also lists useful filters, helping the agent decide when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, indicating safe read-only behavior. The description adds no additional behavioral context (e.g., pagination limits, return structure) beyond the purpose, so it does not exceed what annotations already convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loading the purpose, then providing usage guidance and sibling references. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Combined with annotations (safety profile) and output schema (return values covered), the description is sufficient for this listing tool. It explains the primary use cases and scoping, and references an alternative tool for more specific operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds useful context for message_id and primary_entity parameters beyond the schema descriptions ('scope to one message', 'see all messages supported by one table'). Schema descriptions for other parameters (top, filter, select) are already clear, and the description does not add significantly to those. Overall, it enhances understanding without being redundant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists SDK message filters showing which entities support each message. It differentiates from sibling tools like dataverse_get_sdk_message_filter (for resolving a specific filter) and dataverse_list_sdk_messages (for listing messages) by specifying the output and usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises when to use this tool: 'Use message_id to scope to one message, or primary_entity to see all messages supported by one table.' It also directs to a sibling tool (dataverse_get_sdk_message_filter) for resolving a specific filter_id, providing clear when-to-use vs. alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral details: resolution logic (solution_id resolved to unique name first), filtering via msdyn_name, and suboperation field semantics. This goes beyond annotations to explain data interpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, front-loading the purpose, then detailing filters, then field semantics. Every sentence is informative. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown), the description covers filtering options, parameter constraints, and field interpretation (msdyn_suboperation). It fully explains the tool's behavior and is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema has good descriptions, the description adds value by explaining the mutual exclusivity of solution_id and solution_unique_name, the resolution process, and that omitting both lists all. It also references the default projection for the select parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists solution history records from msdyn_solutionhistories, tracking import, upgrade, and export operations. This specific verb+resource distinguishes it from sibling tools like dataverse_get_solution_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use (to track solution operations), the mutual exclusivity of filters (solution_id and solution_unique_name), and the meaning of msdyn_suboperation. It lacks explicit when-not-to-use or alternatives, but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds filter usage context and default select properties, but does not disclose additional behavioral traits like caching, pagination, or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences: first states the purpose, second gives filter usage, third references sibling tools. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and annotations, the description is sufficient. It explains what is returned, how to filter, and where to find more detailed information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value by explaining the filter parameter with examples and mentioning the default select properties. However, it does not cover top, dataverse_url, or consistency_strong beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists tables with their logical and display names. It distinguishes itself from sibling tools by referencing dataverse_get_table_metadata and dataverse_get_entity_sets for more specific needs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides when-to-use guidance with filter examples and directs to specific sibling tools for full schema details or OData collection names, helping the agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint, so the description correctly aligns with a safe read operation. It adds value by detailing the output (bitmask and named rights) and the use case for confirming access, which together provide full behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (under 50 words), well-structured into two paragraphs, and front-loads the core purpose. Every sentence adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the purpose, usage guidance, and output format (bitmask and named rights). With an output schema present, it does not need to detail return values further. Annotations fully cover behavioral traits, making the description complete for a read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes all four parameters with their own descriptions, so the tool description does not add parameter semantics. The baseline of 3 is appropriate given high schema coverage; the description does not compensate beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns access rights for a system user to a specific record, with a specific verb 'Return' and resource 'access rights'. The title 'Retrieve Principal Access' reinforces the purpose. It distinguishes from sibling tools like dataverse_retrieve_user_privileges by focusing on a single record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this tool before delegating an operation to confirm user permissions, providing clear context. However, it does not mention when not to use it or compare with sibling tools like dataverse_audit_user_access or dataverse_retrieve_user_privileges.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this read-only and non-destructive, so the bar is lower, but the description goes far beyond: it discloses the lack of server-side paging, default trimming with total_count/has_more/depth_summary, the exact response shape, how Depth values arrive, and the raw_response fallback. No contradiction with the annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with clear headings and bullets, and it front-loads the purpose. Every behavioral section earns its place, though some of the trimming rationale repeats the input schema's top description verbatim, making it slightly less concise than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description is remarkably complete: it covers purpose, alternatives, response shape, field semantics, trimming behavior, error handling, and fallback behavior. An agent has enough context to invoke the tool correctly and interpret its results, even without the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides detailed descriptions for role_id, top, and dataverse_url, including defaults, max, and the trimming rationale. The description reinforces and contextualizes these parameters but does not add substantial parameter-level meaning beyond what the schema already says, so it stays at the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a concrete question and states it lists a role's privileges—clearly naming the verb and resource. It explicitly distinguishes itself from dataverse_get_security_role (which returns the role record) and other sibling tools, so an agent can tell exactly what this tool produces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use guidance and names alternatives: use dataverse_list_security_roles to find a role id, and use dataverse_retrieve_user_privileges or dataverse_audit_user_access for a user's effective privileges. It also clarifies edge-case behavior (404 for nonexistent role, empty list meaning a real role with no privileges), which is exceptionally helpful for correct tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the annotations, disclosing that three functions run concurrently, can return mutually disjoint sets, fail independently with partial_errors, and that container property names may differ. It also explains derived diffs and raw response handling, providing a rich behavioral picture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured and front-loaded with the core purpose. Each paragraph covers a distinct aspect (usage, three functions, failure behavior, formatting). Some redundancy and heavy capitalization exist, but the complexity of the tool justifies the detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is exceptionally complete for the tool's complexity, covering the three data sources, their semantics, partial failures, derived diffs, container property names, and output normalization. The presence of an output schema further reduces the need for describing return types, and this description leaves little uncovered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description does not mention dataverse_url, but the schema provides a clear description of the required parameter. Since the single parameter is straightforward and self-explanatory, the description adds no additional parameter semantics. Schema description coverage is reported as 0%, but the schema itself adequately documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists an environment's language codes (LCIDs) and distinguishes between usable and merely installed ones. It names the specific verb 'List' and the resource 'languages', effectively differentiating it from other list tools among the siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs when to call this tool ('before writing any localized label') and warns against assuming 1033 is provisioned. It provides clear context on which set (provisioned) is load-bearing and that installed packs are not automatically usable, giving practical guidance without naming alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, non-destructive. Description adds behavioral details: mentions exclusion of large 'data' column by default, conditional retrieval via include_data, and specific error code 0x8004F037. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise (7 lines) and well-structured: first sentence states purpose, second lists return fields, third explains include_data, fourth links to sibling tools, fifth details error diagnostics. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's purpose (single record retrieval) and the presence of an output schema, the description covers all necessary aspects: return fields, optional data inclusion, error code clues, and preconditions. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides detailed descriptions for all three parameters (dataverse_url, import_job_id, include_data). The tool description adds no new semantic information beyond what the schema contains. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Retrieve a single importjob record by its GUID to check import progress.' Distinguishes from sibling tools like dataverse_list_import_jobs (list) and dataverse_import_solution (start) by explicitly referencing them as prerequisites.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises when to use this tool (check import progress) and directs the user to dataverse_import_solution or dataverse_stage_and_upgrade_solution to obtain the import_job_id. Also describes include_data usage for failure diagnosis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds useful context about the consistency_strong parameter and its impact on caching, but no additional behavioral traits beyond what annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: 5 lines covering purpose, filtering, and alternatives. Front-loaded with primary action, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema and comprehensive parameter descriptions, the description covers all essential aspects: purpose, filtering via attribute_type, caching behavior, and sibling tool alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions already detail each parameter. Description adds value by explaining usage of 'attribute_type' (common values) and 'consistency_strong' (when to use), but does not repeat schema info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List column (attribute) definitions for a Dataverse table.' It explicitly distinguishes from sibling tools like dataverse_get_column (single column) and dataverse_list_choice_column_options (picklist options), preventing misuse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: use 'attribute_type' to filter, when to use consistency_strong (after metadata changes), and references alternatives for detailed column data or choice options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description goes beyond by explaining that empty connectionid means runtime failure, and it details the returned fields and their meaning. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured: purpose sentence first, then list of returned fields, followed by practical filtering advice. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple parameters, filtering, and output), the description covers essential usage scenarios and field meanings. The presence of an output schema further reduces the need to document return structure in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaningful guidance for using filter, statecode, and connector_id parameters, and interprets the output's connection_id field. It does not detail the 'top' or 'dataverse_url' parameters, but those are straightforward or have defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists connection references and specifies the exact fields returned (connectionreferenceid, logical name, etc.). It distinguishes itself from sibling tools like dataverse_get_connection_reference by indicating it returns multiple records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete guidance on when to use each filter parameter (connector_id, statecode) and explains the significance of the connection_id field for runtime failures. Does not explicitly mention when not to use the tool or alternative tools, but the use cases are clearly outlined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint, destructiveHint) are consistent. Description adds significant context: default type=1 to avoid duplicates, exclusion of category 5, and additional OData filter support. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bullet-style explanation of categories and filters. Content is justified but could be trimmed slightly without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all key aspects: default exclusions, parameter usage, filter examples, and output projection. Output schema exists, so return values are documented. Adequate for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high with descriptions. The description adds value by explaining default behaviors (type defaults to 1, category excludes 5) and providing filter examples, going beyond schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists classic processes (workflows, business rules, actions, BPFs) from the workflow entity, with specific verb and resource. It distinguishes from siblings like dataverse_get_cloud_flows by explicitly excluding cloud flows unless requested.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides when-to-use guidance (list classic processes) and when-not (cloud flows excluded by default). Includes details on category and type filters but lacks explicit mention of alternative tools for specific scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true. The description adds value by detailing the returned fields (webresourceid, name, etc.) and explaining that content is excluded and why, which goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured with enumerated output fields and clear filtering options. Every sentence adds value without redundancy, making it easy for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (list with filters) and the existence of an output schema, the description covers all necessary aspects: purpose, filters, exclusions, and post-use actions. It is complete and self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has descriptions for each parameter, but the tool description adds further context: it lists the mapping for web_resource_type values (1=HTML, etc.) and provides an example for name_contains ('new_/'). This enhances understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'List webresource records in the Dataverse environment' and clearly distinguishes from sibling tool dataverse_get_web_resource by noting content exclusion and directing to that tool for content retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (for listing without content) and when to use an alternative (dataverse_get_web_resource for included content). It also advises calling dataverse_publish_customizations after modifications, which adds workflow context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as readonly/idempotent, but the description goes far beyond that: it reveals the nested response shape, the unknown-setting-name HTTP 200 behavior (setting_found: false), the STRING vs boolean caveat, DataType unmapped integer code, and raw_response always included. This is exemplary behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured into focused paragraphs. Every section adds necessary nuance (precedence, app overrides, nested value, unknown-name behavior, fallback). It could shave some redundancy with the schema's app_unique_name description, but the extra context about request-level differences earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description covers all critical edge cases: missing settings, value types, data source, raw response, and the semantics of the two request forms. It also tells the user how to discover valid setting names. It is complete enough to invoke correctly and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite the schema having per-parameter descriptions, the context signal says schema description coverage is 0%, so the tool description must compensate. It richly explains setting_name (from settingdefinitions, not display label) and app_unique_name (omit vs empty leads to different calls). However, it doesn't mention dataverse_url at all, leaving that param's semantics entirely to the schema, so a perfect score isn't warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Read one setting's FINAL COMPUTED value for this environment.' It clearly distinguishes this from raw configuration reads and from organization-row readers like dataverse_get_plugin_trace_log_setting, making the tool's niche unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: diffing configuration between environments by computed values. It also provides clear exclusions: not a general organization row reader, and names alternatives (dataverse_get_plugin_trace_log_setting, dataverse_query_table). The app_unique_name omission vs. empty distinction is also a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description adds substantial behavioral detail beyond those flags: live-verified response shape (RolePrivileges vs TeamPrivileges), no server-side paging with trimming behavior, total_count/has_more semantics, Depth value mapping, error handling for nonexistent team ids, and the meaning of an empty list with normalized: true. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with bolded section headers (RESPONSE SHAPE, AN EMPTY LIST IS A REAL ANSWER, THE LIST CAN BE BIG, etc.) and front-loads the core purpose. Every section covers a distinct, operationally important aspect. It could be tightened by reducing repeated 'VERIFIED LIVE' phrasing, but overall each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description is extremely complete: it explains the response collection naming quirk, entry key set, Depth representation, trimming with total_count/has_more, error vs empty-list distinction, and relationships to sibling tools. Even though an output schema exists, the description adds crucial live-verified details that the schema cannot convey, making it fully adequate for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for team_id, top, and dataverse_url, so the description does not need to repeat them. It adds significant extra meaning for top (why it defaults to 50, max 1000, total_count/has_more, depth_summary computed over all entries) and for team_id (finding via dataverse_list_teams, the key predicate). It does not explicitly discuss dataverse_url, but that parameter is self-explanatory and well-covered by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource+scope: 'Answer what can this TEAM actually DO? — list a team's privileges.' It clearly distinguishes from siblings by naming dataverse_get_role_privileges, dataverse_retrieve_user_privileges, and dataverse_get_team, positioning itself as 'the missing third' and the companion that returns permissions rather than the team record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance appears throughout: use dataverse_list_teams to find a team id by name, dataverse_get_team for the team record, dataverse_audit_user_access for one person's effective access, and dataverse_get_role_privileges when comparing to a role's privileges. It also clarifies that an empty list is a normal answer, not a failure, and warns not to interpret team members' access from this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this readOnly, openWorld, idempotent and non-destructive; the description adds substantial context beyond those flags: a hand-rolled access-right map with unmapped values reported raw, @odata.count capping at 5,000 bypassed by aggregation, join-table scoping versus name-matching, and explicit error behavior for unknown table names. It also states the response's normalization discipline (empty list is real, missing container is not), so no guesswork is left to the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but it is organized into capitalized topic paragraphs and every paragraph introduces a behavioral nuance the agent must know (access-right decoding, depth collapsing, count aggregation, join-table scoping, error semantics). It is front-loaded with the core purpose and only then dives into edge cases; still, it is verbose enough that some agents might need to parse several paragraphs for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so return-value details need not be spelled out; the description instead covers failure modes, count accuracy, route differences, and normalization semantics. Combined with rich parameter docs in the input schema, the description leaves virtually no ambiguity about when and how to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents each parameter with detailed descriptions (case-insensitivity, join-table scoping, 'None' as a real value), so the baseline is high. The tool description reinforces and extends this by explaining the integer mapping for access_right, that name_startswith is case-insensitive on both routes, and what total_count/count/has_more mean for top, adding meaning beyond the structured schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a crisp active statement: 'List the privileges DEFINED in the environment — the catalogue of what CAN be granted.' It explicitly contrasts with dataverse_get_role_privileges, dataverse_get_team_privileges, and dataverse_retrieve_user_privileges, stating those answer 'who HOLDS what' whereas this answers 'what privileges exist, what access right does each carry, and at which depths can it be granted.' This is a specific verb+resource with clear sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description names the sibling tools that answer 'who HOLDS what' and tells the agent to use this tool as the reference catalogue: 'Use it to look up the privilege behind a name those tools return... or to enumerate everything that exists for one table.' It also gives concrete guidance about when to apply table_logical_name and warns against name-based filtering, making the usage context explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnly/idempotent, and the description adds extensive non-obvious behavior: independent failure of the two calls, partial_errors semantics, response shape discovery, client-side trimming with total_count/has_more, and the 404 misdiagnosis risk. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but structured with a bold lead, ASCII callouts, and clearly separated paragraphs; virtually every sentence adds needed operational context. Slightly verbose but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, alternatives, parameter pitfalls, error behavior, response shapes, paging semantics, and interpretational limits. For a tool that merges two functions with subtle failure modes, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents each parameter in detail, so baseline is 3. The description goes beyond by emphasizing the plural-vs-singular asymmetry and the practical consequence of a wrong entity set name, adding operational value for the most error-prone parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with the precise question answered and explicitly names the two merged functions (RetrieveSharedPrincipalsAndAccess, RetrieveSharedLinks), then contrasts with sibling tools that require knowing a principal upfront. This is a specific verb+resource with clear scope and sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool versus dataverse_retrieve_principal_access and dataverse_retrieve_access_origin, and warns when NOT to conclude privacy from an empty result. Also tells callers to use dataverse_get_entity_sets to confirm plural entity set names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses important behavioral traits: the need for specific environment variables for write/delete operations, atomic execution with change_set_id, a maximum of 1,000 operations per request, and the return format including per-operation results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph that front-loads the purpose, then provides usage guidelines, requirements, and return format. Every sentence adds value without redundancy, making it concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of batch operations, the description covers all critical aspects: purpose, when to use, environment variable requirements, atomicity, max operations, and return format. It is complete enough for an agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already includes detailed descriptions for each parameter (e.g., 'operations' lists minItems, max 1000; 'continue_on_error' explains behavior). The description adds value by explaining the concept of change_set_id for atomicity and the return format, which is not in the schema. Given that the schema itself is well-documented, the description provides complementary high-level context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Execute bulk or atomic multi-operation reads and writes via the OData $batch endpoint.' It distinguishes from sibling tools by explicitly naming alternatives for single-record writes and metadata changes, and highlights the atomicity feature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (bulk operations, atomic writes) and when not to (single-record writes, metadata changes), referencing specific sibling tools. It also specifies requirements like DATAVERSE_ALLOW_WRITE and DATAVERSE_ALLOW_DELETE environment variables, and explains atomic grouping via change_set_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only state readOnly/idempotent/destructive hints; the description adds crucial behaviors: the response is a single FormattedResults string, it is actually a SpreadsheetML workbook, trimming behavior with results_length and truncated, structural summary is not a verdict, and id distinction between ImportJobId and ImportJobKey. This far exceeds annotation baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is far longer than typical, but it uses bold headings and short paragraphs to organize. However, it repeats the 'read the text' warning several times and contains ALL-CAPS phrases that could be trimmed without losing meaning, so it's not maximally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity—unformatted vs formatted results, spreadsheet XML, truncation, summary semantics, and ID confusion—the description covers every failure mode an agent could encounter. It even explains what happens when the payload cannot be identified (raw_response fallback). The output schema exists, so return values need not be restated, and the description focuses on selection and invocation nuances.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema coverage reportedly 0%, the description compensates fully. It explains max_chars' default, maximum, and the fact that the full document may be truncated; it clarifies import_job_id is the GUID, not the ImportJobKey string; and it mentions dataverse_url requirement indirectly through the schema. The description adds operational meaning to every parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the user-facing question 'Answer "WHY did this solution import fail?"' then names the exact API function and contrasts with dataverse_get_import_job. This clearly specifies the verb (get formatted results), the resource (import job results), and differentiates it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the companion tool dataverse_get_import_job and tells the agent when to use which ('returns the importjob RECORD ... raw data column'). Also provides how to obtain the id via dataverse_list_import_jobs or dataverse_import_solution / dataverse_stage_and_upgrade_solution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior, so the description focuses on added context: each function is called independently, failures are collected in partial_errors, and only total failure yields an error response. It also discloses response shaping (@odata envelope removal) and performance-relevant solution summarization.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is a concise, front-loaded summary, and each following paragraph addresses a distinct, valuable concern: when to call, how to classify environments, solution handling, and partial-failure behavior. The length is justified by the tool's complexity, and no sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers preconditions, environment-identity interpretation, output shaping, and partial-error semantics, which is complete for a tool that merges three Web API calls. An output schema is present, so the description does not need to enumerate every return field, but it still provides enough context to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema itself documents dataverse_url, access_type, and include_solutions with clear descriptions. The tool description adds meaningful semantics for include_solutions—response-size impact, default behavior, and a preferred alternative tool. Access_type is not revisited in prose, but the schema already explains it thoroughly, so the gap is minor.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Fingerprint a Dataverse environment: server version, organization identity, endpoints,' which names a specific verb, resource, and scope while distinguishing it from sibling lookup tools. It also differentiates the tool by naming the three merged Web API functions and the practical outputs it provides.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'Call this before any risky operation to confirm which environment you are pointed at.' It also gives an explicit alternative for solutions browsing ('prefer dataverse_list_solutions') and warns against a common misclassification ('never test only for Sandbox').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description discloses highly relevant behavioral quirks: no server-side paging, client-side trimming, byte-identical lists when table_logical_name is supplied, fallback parsing logic, and the meaning of empty lists. It also discloses measured live sizes and error behavior (HTTP 400 for unknown names). These are exactly the kind of details that save an agent from misinterpreting results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and sibling distinction, and every paragraph adds essential caveats. However, it is quite long and repeats certain points (e.g., 'byte-identical' appears multiple times, 'measured live' is used repeatedly). Some trimming could be done without losing value, but overall the structure is logical and the detail is mostly earned.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and annotations cover safety, the description still goes beyond to explain response shape, fallback mechanism, raw_response behavior, and empty-list semantics. It covers the full context an agent needs to correctly invoke this tool and interpret results, including warnings about huge payloads and the exact behavior of the optional table_logical_name parameter. This is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema already has descriptions for each parameter, the tool description adds critical semantic nuance beyond the schema. For role, it clarifies that every role answers the environment-wide question and gives exact meanings for 'referenced', 'referencing', and 'many_to_many'. For table_logical_name, it emphasizes that the parameter 'DOES NOT NARROW THE ANSWER' and that omission is different from sending an empty string. It also explains top's trimming behavior with concrete numbers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List WHICH tables may take part in a relationship — the enumeration, before you pick a target.' It immediately distinguishes itself from the sibling tool dataverse_check_relationship_eligibility by contrasting 'which tables are eligible?' with 'is THIS ONE table OK?'. This is a clear, actions-focused purpose statement that leaves no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Call it before dataverse_create_one_to_many_relationship or dataverse_create_many_to_many_relationship' and directs users to the alternative tool for single-table checks: 'To ask about one specific table, use dataverse_check_relationship_eligibility'. It also explains that table_logical_name should only be passed to prove existence, and that the tool is meant for the 'do not yet know what to point a lookup at' scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety context is already clear. The description adds substantial behavioral context beyond that: the exact response shape (flat payload, single property named after the function), fallback behavior when future formats change, omission rather than null when no verdict is found, echoing raw_response, and HTTP 400 error behavior for mismatched GUIDs. The warning against reading missing is_customizable as false and the customizability nuance (managed properties can block specific edits even when the verdict is true) are valuable operational caveats the annotations could not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every paragraph earns its place: opening recommendation, function call specifics, response format, false/true semantics, the non-obvious system component behavior, and error identification. The first sentence is a clear front-loaded purpose statement. Paragraphs are short with bolded key phrases (BEFORE, DO NOT ASSUME, is_customizable) that aid scanning. The only minor redundancy is the sentence about component_type codes being echoed back as component_type_name, but it directly supports the 'mismatched code easy to spot' point, so no waste. This is efficient density, not padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only pre-flight check with an output schema present, the description is complete. It covers what the tool does, when to use it, how to interpret both true and false verdicts, the exact payload shape, error behavior, and even addresses a common wrong assumption (system components). The presence of an output schema means return-value documentation isn't the description's job, and the description deliberately does not over-explain the output. The combination of annotations, rich schema param descriptions, and this behavioral narrative leaves no practical questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema parameters already have strong descriptions (component_id explains NOT a solution id and includes concrete examples; component_type lists common values and links to Microsoft docs). The description adds crucial guidance beyond the schema: the component_type codes are the same set dataverse_analyze_dependencies uses, the resolved name is echoed back to catch mismatches, and the error semantics when component_id doesn't match a component. Given schema coverage is 0% in the structured sense but the description and schema complement each other well, and the description adds meaningful interpretive context, this earns a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Check whether a solution component can be customized BEFORE trying to edit it.' It clearly distinguishes this pre-flight check tool from sibling update/delete tools and from read-only introspection tools like dataverse_analyze_dependencies (which shares the component_type code set). The resource (solution component) and the scope (customizability pre-check) are explicit and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Run this first when editing anything you did not create yourself' and lists the exact write tools that benefit (dataverse_update_table, dataverse_update_column, etc.). It also gives behavioral guidance about interpreting results: a false answer means managed solution lock, while true is not a guarantee because managed properties can still block edits. It even warns not to assume system components answer false and provides example verified results. This is textbook when-to-use-this-vs-alternatives guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the annotations by disclosing critical runtime behavior: 'HTTP 200 DOES NOT MEAN "HAS ACCESS" — READ THE STRING', 'Three materially different outcomes... distinguishable ONLY by the English prose inside the string', and specific error cases like unknown logical_name returning a 400, org-owned rows returning identical answers, and nonexistent principal_id not being validated. It also explains the normalization/raw_response behavior, adding value beyond readOnlyHint and idempotentHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Although long, the description is well-structured with clear sections for inputs, response shape, and live-confirmed behavior. Every sentence adds necessary nuance or a critical warning. It is front-loaded with the core purpose and immediately distinguishes from the related mask-only tool. There is no fluff or redundant repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the risk of misinterpreting HTTP 200, the description is remarkably complete. It documents the response shape, the meaning of normalized flags, and multiple edge cases (nonexistent records, org-owned rows, invalid principal IDs). It also cautions that observed wordings are not a platform contract, which is crucial for an agent to avoid brittle reasoning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema by clarifying logical_name is 'the SINGULAR lowercase logical name... deliberately not the entity set name' and principal_id 'must be a systemuser or a team — no other principal type is accepted.' It covers object_id, logical_name, and principal_id with context. However, it omits dataverse_url from the Inputs section, though the schema already provides a clear description for that parameter. The description meaningfully compensates for the schema's terse descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly frames the tool as answering 'WHY does this principal have access to this record?' and states it 'explains where a principal's rights over one specific row come from — object ownership, or the Principal Object Access (POA) table.' It differentiates from the sibling dataverse_retrieve_principal_access, which returns only the access mask. This is a specific verb+resource+scope with clear sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides direct comparisons: 'This is the companion to dataverse_retrieve_principal_access, which returns only the access MASK... When you are debugging "why can this user see this record?"... use this.' It also gives alternatives for broader questions: 'Use dataverse_audit_user_access for the wider picture... and dataverse_get_role_privileges for what one role permits.' It even states principal-type constraints and which list tools to use for valid IDs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description exceeds annotation disclosures with rich behavioral detail: HTTP 200 can mask disabled auditing or nonexistent records, 404 error codes distinguish naming errors from missing rows, entries are polymorphic, configuration rows may appear, response shape is validated, and paging is trimmed client-side. These are critical operational nuances not conveyed by the annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is quite long, but it is well-organized with bolded section headers (e.g., 'HTTP 200 IS NOT PROOF', 'NOT EVERY ENTRY IS A RESULT', 'ENTRIES ARE POLYMORPHIC') that aid navigation. The front-loaded purpose sentence and each subsequent paragraph add substantive value; the length is justified by the tool's complexity, though a bit more editing could make it leaner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers error handling, edge cases, polymorphic subtypes, configuration rows, response shape validation, and paging semantics comprehensively. Given the tool's complexity and the presence of an output schema, the description goes far beyond what is required, leaving little room for ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite the schema including descriptions, the tool description adds essential meaning for each parameter: entity_set_name must be the plural OData collection name and should be discovered via dataverse_get_entity_sets, record_id is a GUID, top controls client-side trimming, and dataverse_url is the required org URL. This compensates effectively for the 0% schema description coverage signal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Retrieve the full audit change history for a specific record,' a specific verb+resource statement that clearly identifies the tool's function. It also differentiates from the sibling dataverse_get_attribute_change_history by emphasizing record-scoped vs column-scoped history, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly directs the agent to use dataverse_get_attribute_change_history for single-column questions, providing a clear alternative. It also advises using dataverse_get_entity_sets when a 404 indicates a naming issue, and warns against interpreting empty responses as evidence of absence, giving concrete when-to and when-not-to guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with annotations declaring readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, the description goes far beyond them. It discloses that a nonexistent record ID returns HTTP 200 with zero changes, that a wrong singular entity set returns a specific 404, that empty results trigger audit-configuration probes, and that the response shape is checked rather than assumed. These are rich behavioral details not present in annotations and critical for correct use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every section earns its place: each bolded segment addresses a distinct, verified behavior or pitfall. It is front-loaded with the purpose, then structured by topic (singular/plural, error codes, empty results, entry polymorphism, response shape, paging). The formatting with bullets and code snippets improves scannability without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with a nested input schema and an output schema, the description covers all critical aspects: the exact URL form, how to identify configuration events vs real changes, polymorphic entries, paging behavior, and the handling of ambiguous empty results. It even notes the differences from the sibling function. This leaves little to guess even for a caller unfamiliar with Dataverse audit APIs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is reported as 0%, so the description must carry the weight, and it does. It devotes a full section to the singular/plural split, explaining that entity_set_name is the plural, sent to the function, while table_logical_name is the singular, never sent and used only for probes. It also explains record_id semantics (must be well-formed GUID, all-zero GUID behavior) and column_logical_name, all adding meaning beyond the raw schema field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise statement: 'Retrieve the audit trail for ONE COLUMN of ONE RECORD — who changed this field.' It then distinguishes itself from the sibling dataverse_retrieve_record_change_history by calling itself the 'column-scoped sibling,' making the scope and resource unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this one when the question is about a single field' and contrasts it with the record-scoped alternative. It also points to dataverse_get_entity_sets as a helper to confirm the plural entity set name, and gives detailed instructions on how to interpret 404 vs 200 responses, which is when-to-use guidance beyond the basics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, openWorldHint, etc.), the description reveals critical behavioral nuances: counts are stale by up to 24 hours, all_counts_zero=true means 'unknown' not 'empty', unrecognized names fail the entire call with HTTP 400, and raw_response fallback for unexpected shapes. This is far beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then logically organized into paragraphs covering approximation caveats, all-zero edge case, failure behavior, and response fallback. Each sentence contributes specific, non-redundant information, making the length appropriate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity, existing output schema, and annotations, the description leaves no meaningful gaps: it covers freshness, false-zero indication, error semantics, name validation, and response normalization. It is fully self-sufficient for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite the context signal of 0% schema description coverage, the description thoroughly explains the entity_names parameter: singular and lowercase logical names, not plural OData set names; the 1-50 array limit and URL length reasoning; name grammar requirements; and that any unrecognized name aborts the call. It also notes splitting for long names, fully compensating for any schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource-scope statement: 'Get approximate row counts for many Dataverse tables in one round trip.' It clearly distinguishes itself from sibling dataverse_count_records by emphasizing the bulk, approximate nature and the map return format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Use this tool for cheap bulk sizing... and dataverse_count_records whenever an exact, live, or filtered count matters.' It also recommends dataverse_list_tables for confirming entity names before invoking this tool, giving both positive and alternative usage contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses the published-versus-draft behavior, which is a critical non-obvious trait. It also notes the 5 MB content cap, adding safety and expectation management. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized for the tool's complexity: a clear first sentence, a compact list of returned fields, and a short parameter note. The IMPORTANT caveat is set off in a new paragraph, front-loading the most critical behavioral note. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers return fields, parameter guidance, the published/draft distinction, and the content size cap. The output schema handles return typing, so the description's focus on semantics and caveats makes it complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to include_content beyond the schema: it explains the base64 encoding, potential size for images/script bundles, and the 5 MB cap. The other parameters (URL and GUID) are self-explanatory in the schema, and the description's guidance on when to set include_content covers the one non-trivial parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Retrieve a single webresource record by its GUID.' It clearly identifies the resource type and the key identifier, distinguishing it from list operations and the unpublished retrieval tool. The list of returned fields further scopes the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly contrasts with dataverse_update_web_resource and dataverse_retrieve_unpublished: states that edits are not visible in published retrieval until publish_customizations is called, and points to dataverse_retrieve_unpublished for draft reads. Also advises on the include_content parameter with a size caution, giving clear when-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint, idempotentHint), the description discloses critical behaviors: the returned column set is NOT the requested set, NULL-valued columns are omitted, unexpected extra columns like _organizationid_value appear, and invalid column names produce an HTTP 400. It also notes that a record with no changes returns a draft identical to published. This is richly transparent and aligns with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every paragraph earns its place, with a clear first-line definition, bold IMPORTANT warnings, and explicit do/don't guidance. It front-loads the core purpose and then layers specialized details, making it easy for an agent to scan. No redundant fluff or repetition of annotation values.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the full decision context: when to use, expected return shape (one record), select projection caveats, error signaling, and the identity case (no changes). It also names supporting list tools to find record IDs. Given the output schema exists and annotations are present, this description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The context reports 0% top-level schema coverage because the only top-level property ('params') lacks a description, but the nested schema (RetrieveUnpublishedInput) provides detailed descriptions for all four real parameters. The tool description adds even more critical nuance about select behavior: default projection excludes large XML/binary columns, NULL columns vanish, and unrequested columns may appear. It also clarifies entity_set_name irregulars and the sitemap limitation, going beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Read the UNPUBLISHED (draft) definition of one customization record.' It distinguishes itself from sibling read tools by explicitly stating that normal GETs and dataverse_get_form/view/web_resource return the PUBLISHED row, while this tool reads the draft. This is a precise purpose statement with clear sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is explicitly tied to the write-then-read workflow: 'Call this tool to read back what you just wrote' after describing how write tools save to draft. It also states when NOT to use it: sitemap is not supported, ordinary data tables have no unpublished layer, and reading the published row can 'silently clobber your own unpublished changes.' This is model guidance on when and when-not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![dataverse-mcp MCP server](https://glama.ai/mcp/servers/ryanmichaeljames/dataverse-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ryanmichaeljames/dataverse-mcp)

Score Badge

Copy to your README.md:

[![dataverse-mcp MCP server](https://glama.ai/mcp/servers/ryanmichaeljames/dataverse-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ryanmichaeljames/dataverse-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ryanmichaeljames/dataverse-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server