Dataverse MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes targeting specific Dataverse components (e.g., business units, tables, columns, roles, teams) with clear CRUD operations, but some overlap exists in management tools like 'generate_webapi_call' and 'generate_powerpages_webapi_call' which could cause confusion in selection. Overall, descriptions help differentiate, but the high count increases complexity.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, such as 'create_dataverse_table', 'get_dataverse_column', 'list_dataverse_solutions', and 'update_dataverse_role'. There are no deviations in style, making it predictable and easy to understand the action and target resource.
Tool Count2/5
With 71 tools, the count is excessive for a single server, making it overwhelming and difficult for agents to navigate. While Dataverse is a complex platform, this many tools suggests poor scoping, likely leading to confusion and inefficiency in tool selection and usage.
Completeness5/5
The tool set provides comprehensive coverage for Dataverse administration, including full CRUD operations for all core components (tables, columns, relationships, roles, teams, business units, etc.), lifecycle management (e.g., set/clear solution context), and auxiliary functions like schema export and diagram generation. No obvious gaps are present for the domain.
Average 3.7/5 across 71 of 71 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on August 15, 2025
- 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'authentication context' and 'portal-specific patterns,' which adds some context about security and environment, but it fails to describe critical behaviors such as whether this tool performs actual API calls (likely not, as it 'generates' examples), what the output format is (e.g., code snippets, documentation), or any rate limits or permissions required. For a tool with 15 parameters and no annotation coverage, this is a significant gap.
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 a single, efficient sentence that front-loads the core purpose ('Generate PowerPages-specific API calls...') and adds supplementary details ('Includes authentication context...'). There is no wasted text, and it's appropriately sized for the tool's complexity, though it could benefit from more structured guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's high complexity (15 parameters, no annotations, no output schema), the description is incomplete. It lacks information on output format (critical for a generation tool), behavioral details like whether it executes calls or just generates code, and differentiation from siblings. The 100% schema coverage helps with parameters, but overall context for effective agent use is insufficient.
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 100%, meaning all parameters are documented in the input schema itself. The description adds no specific parameter details beyond what the schema provides (e.g., it doesn't explain how 'logicalEntityName' interacts with 'operation' or clarify the 'includeAuthContext' usage). With high schema coverage, the baseline score is 3, as the description doesn't compensate with additional semantic insights.
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 the tool generates 'PowerPages-specific API calls, JavaScript examples, and React components for Dataverse operations through PowerPages portals,' which is specific about the verb (generate) and resources (API calls, examples, components). However, it doesn't explicitly differentiate from the sibling tool 'generate_webapi_call,' which appears to be a more general version, leaving some ambiguity about when to choose this PowerPages-specific variant.
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?
The description mentions 'Includes authentication context and portal-specific patterns,' which implies usage in PowerPages contexts, but it provides no explicit guidance on when to use this tool versus alternatives like 'generate_webapi_call' or other sibling tools. There are no when-not-to-use statements or prerequisites, leaving the agent to infer context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a read-only operation ('retrieves') but doesn't disclose error conditions (e.g., if the column doesn't exist), rate limits, authentication requirements, or the format/structure of the returned information. This leaves significant gaps for an agent to understand tool behavior.
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 a single, efficient sentence that front-loads the core action ('retrieves detailed information') and specifies the scope ('about an AutoNumber column'). It avoids redundancy but could be slightly more structured by explicitly separating purpose from output details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'detailed information' includes beyond high-level categories, how results are formatted, or potential errors. Given the complexity of retrieving configuration data, more context is needed to guide an agent effectively.
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 100%, with both parameters clearly documented in the schema itself. The description adds no additional parameter semantics beyond what the schema provides (e.g., it doesn't clarify what 'logical name' means or provide examples). Baseline 3 is appropriate since the schema does the heavy lifting.
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 the verb ('retrieves') and resource ('detailed information about an AutoNumber column'), specifying what properties are included (format, properties, configuration). It distinguishes from 'list_autonumber_columns' by focusing on a single column's details rather than listing multiple columns, though this distinction could be more explicit.
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?
The description provides no guidance on when to use this tool versus alternatives like 'list_autonumber_columns' or 'get_dataverse_column'. It doesn't mention prerequisites, such as needing to know the column's logical name beforehand, or contextual factors like permissions required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the effect ('granting them all the permissions defined in that role') but fails to cover critical aspects like required authentication, potential side effects (e.g., overwriting existing roles), rate limits, or error conditions. This is inadequate for a mutation tool with security implications.
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 in the first sentence, followed by usage context. Both sentences are relevant and non-redundant, though it could be slightly more concise by integrating the second sentence's intent more tightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a security-related mutation tool with no annotations and no output schema, the description is insufficient. It lacks details on permissions needed, response format, error handling, or how it interacts with sibling tools like 'remove_role_from_user'. More context is required for safe and effective use.
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 100%, so the input schema already documents both parameters (roleId and userId) adequately. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints, meeting the baseline for high schema coverage.
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 the action ('Assigns a security role to a specific user') and the resource involved, making the purpose unambiguous. However, it does not explicitly differentiate from sibling tools like 'assign_role_to_team' or 'remove_role_from_user', which would be needed for a score of 5.
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 implied usage context ('to provide users with the appropriate access levels for their job functions'), but lacks explicit guidance on when to use this tool versus alternatives like 'assign_role_to_team' or prerequisites such as required permissions. No when-not-to-use scenarios or clear alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates this is a mutation tool ('changes', 'moving'), implying it modifies data, but fails to disclose critical behavioral traits such as required permissions, whether changes are reversible, potential side effects (e.g., impact on reporting or access), or error conditions. This leaves significant gaps for safe and effective use.
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 appropriately sized with two sentences that are front-loaded: the first states the core action, and the second provides usage context. There's no wasted text, and it efficiently conveys the tool's purpose without redundancy, though it could be slightly more structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as a mutation operation with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects (e.g., permissions, reversibility), expected outcomes, or error handling, which are crucial for a tool that modifies organizational structure. This makes it inadequate for safe agent use without additional 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?
The input schema has 100% description coverage, clearly documenting both parameters ('businessUnitId' and 'parentBusinessUnitId') as unique identifiers. The description adds minimal value beyond the schema by implying the parameters are used for moving within a hierarchy, but doesn't provide additional semantics like format examples or constraints. This meets the baseline for high schema coverage.
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 the tool's purpose with specific verbs ('changes', 'moving') and resources ('business unit', 'organizational hierarchy'), distinguishing it from siblings like 'update_dataverse_businessunit' or 'create_dataverse_businessunit'. However, it doesn't explicitly differentiate from all siblings, such as 'get_businessunit_hierarchy', which is related but for reading rather than modifying.
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 implied usage context by stating 'Use this to reorganize business unit structure and reporting relationships', which suggests when to apply it. However, it lacks explicit guidance on when not to use it (e.g., vs. creating or deleting business units) or alternatives, and doesn't mention prerequisites like permissions or dependencies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is an update operation (implying mutation) and mentions partial updates ('Only provided fields will be updated'), but doesn't disclose critical behavioral traits like required permissions, whether changes are reversible, rate limits, error handling, or what the response contains. For a mutation tool with 49 parameters and no annotation coverage, this is a significant gap.
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 two sentences, front-loaded with the core purpose, and avoids redundancy. Every sentence adds value: the first defines scope, the second clarifies update behavior. It could be slightly more structured (e.g., bullet points for categories), but it's efficient and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation operation with 49 parameters, no annotations, no output schema), the description is inadequate. It lacks behavioral context (e.g., permissions, side effects), usage prerequisites, output format, and error handling. The schema covers parameters well, but the description doesn't compensate for missing annotation and output schema coverage.
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 100%, so the schema already documents all 49 parameters thoroughly. The description adds minimal value beyond the schema by grouping parameters into categories ('business unit information, contact details, addresses, and organizational settings') and noting partial update behavior, but doesn't provide additional syntax, format, or constraint details. Baseline 3 is appropriate when schema does the heavy lifting.
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 the verb ('Updates') and resource ('properties and configuration of an existing business unit'), and specifies the scope of updates ('business unit information, contact details, addresses, and organizational settings'). However, it doesn't explicitly differentiate from sibling tools like 'update_dataverse_column' or 'update_dataverse_team' beyond the resource 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 through 'Use this to modify...' and provides a partial constraint ('Only provided fields will be updated'), but lacks explicit guidance on when to use this versus alternatives (e.g., vs. 'create_dataverse_businessunit' or 'set_businessunit_parent'), prerequisites, or error conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers limited behavioral disclosure. It mentions the effect ('granting them access'), but doesn't specify whether this is a mutating operation (implied by 'Adds'), potential side effects (e.g., notifications, permission changes), error conditions (e.g., invalid IDs, duplicates), or response format. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding behavior.
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 appropriately sized with two sentences: the first states the purpose and outcome, the second provides usage context. It's front-loaded with the core action and avoids unnecessary details. However, the second sentence could be more direct, and there's minor redundancy ('team membership' and 'team-level access').
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's moderate complexity (mutation with 2 parameters), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose and usage but lacks details on behavioral aspects like permissions needed, error handling, or return values. For a mutation tool, this leaves room for improvement in 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?
Schema description coverage is 100%, with clear parameter descriptions in the input schema ('Array of user IDs to add as team members', 'ID of the team to add members to'). The description adds no additional parameter semantics beyond what the schema provides, such as ID formats or constraints. Baseline 3 is appropriate when the schema does the heavy lifting.
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 the action ('Adds users as members to a team') and the resource ('team'), specifying the outcome ('granting them access to team-owned records and team-based permissions'). It distinguishes from sibling 'remove_members_from_team' by focusing on addition, but doesn't explicitly differentiate from other team/user management tools like 'assign_role_to_team' or 'assign_role_to_user'.
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 implied usage context ('Use this to expand team membership and provide users with team-level access to resources'), suggesting when to use it. However, it lacks explicit guidance on when not to use it or alternatives (e.g., vs. 'assign_role_to_user' for individual permissions), and doesn't mention prerequisites like required permissions or existing team/user status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions the tool generates examples (implying read-only, non-destructive output), it doesn't clarify whether this requires authentication, has rate limits, or what the output format looks like (e.g., plain text, structured JSON). For a tool with 22 parameters and no annotation coverage, this is a significant gap in 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 a single, well-structured sentence that efficiently conveys the tool's purpose, supported operations, and output formats without any wasted words. It is appropriately sized and front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (22 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the output format, error handling, or authentication requirements, leaving gaps for an AI agent to correctly invoke and interpret results. The description should provide more context to compensate for the lack of structured metadata.
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 100%, so the schema already documents all 22 parameters thoroughly. The description adds no specific parameter details beyond what the schema provides, such as examples or constraints. Baseline 3 is appropriate when the schema does the heavy lifting, though the description could have added context for complex parameters like 'operation' enum values.
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 generates HTTP requests, curl commands, and JavaScript examples for Dataverse WebAPI operations, specifying it supports all CRUD operations, associations, actions, and functions with proper OData query parameters and headers. This is specific (verb+resource+output formats) and distinguishes it from sibling tools that perform actual Dataverse operations rather than generating code examples.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, typical scenarios, or compare it to sibling tools like 'generate_powerpages_webapi_call' or actual operation tools (e.g., 'create_dataverse_table'). Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions retrieval and shows relationships, but fails to disclose critical traits like whether this is a read-only operation, potential permissions needed, rate limits, or what the output format looks like (e.g., tree structure, JSON). This leaves significant gaps for an AI agent to understand the tool's 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?
The description is appropriately sized and front-loaded, with two sentences that efficiently convey the tool's purpose and usage without waste. Every sentence adds value, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of retrieving hierarchical data and the lack of annotations and output schema, the description is incomplete. It doesn't explain the return structure (e.g., nested objects, depth), potential limitations, or error handling, which are crucial for an AI agent to use this tool effectively 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?
The input schema has 100% description coverage, with the parameter 'businessUnitId' clearly documented as a unique identifier. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. Baseline 3 is appropriate when the schema does the heavy lifting.
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 the tool's purpose with specific verbs ('retrieves', 'showing') and resources ('organizational hierarchy', 'business unit relationships'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_businessunit_teams' or 'get_businessunit_users', which prevents a perfect score.
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 context by stating 'Use this to understand business unit relationships and organizational structure,' which suggests when to use it. However, it lacks explicit guidance on when not to use it or alternatives among sibling tools, such as distinguishing from 'list_dataverse_businessunits' or 'get_dataverse_businessunit'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions retrieving 'detailed information including all properties, addresses, and related information', which gives some context about return scope. However, it doesn't address important behavioral aspects like whether this is a read-only operation, authentication requirements, rate limits, error conditions, or what format the information is returned in.
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 efficiently structured in two sentences: the first states the core functionality, the second provides usage context. It's appropriately sized without wasted words, though it could be slightly more front-loaded by integrating the usage guidance more directly with the purpose statement.
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?
For a single-parameter retrieval tool with no output schema, the description provides adequate but incomplete context. It specifies what information is retrieved but doesn't describe the return format, structure, or any limitations. Given the lack of annotations and output schema, more detail about the response would be helpful for an agent to understand what to expect.
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 100% with the single parameter 'businessUnitId' well-documented in the schema. The description doesn't add any additional parameter semantics beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
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 the tool's purpose with the verb 'retrieves' and specifies the resource as 'detailed information about a specific business unit'. It distinguishes from siblings like 'list_dataverse_businessunits' by focusing on a single unit rather than listing, but doesn't explicitly contrast with 'get_businessunit_hierarchy' which also retrieves business unit information.
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 implied guidance with 'Use this to inspect business unit configuration and hierarchy relationships', suggesting when this tool is appropriate. However, it doesn't explicitly state when to use this vs. alternatives like 'get_businessunit_hierarchy' or 'list_dataverse_businessunits', nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the tool as a retrieval operation, which implies it's read-only and non-destructive, but doesn't explicitly state this or mention any constraints like authentication requirements, rate limits, or error conditions. The description adds some context about what information is retrieved but lacks comprehensive behavioral details.
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 and well-structured in two sentences: the first states the purpose, and the second provides usage guidance. It's front-loaded with the core functionality and avoids unnecessary details. However, it could be slightly more efficient by combining ideas, but overall it's clear and wastes no 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?
Given the tool's low complexity (single parameter, no output schema, no annotations), the description is moderately complete. It covers the purpose and usage but lacks behavioral transparency details that would be crucial without annotations. For a simple retrieval tool, it's adequate but could benefit from more explicit safety and constraint information to fully guide the agent.
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 100% description coverage, with the single parameter 'uniqueName' well-documented in the schema. The description doesn't add any additional parameter semantics beyond what's in the schema, such as format examples or validation rules. Given the high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
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 the tool's purpose with the verb 'retrieves' and specifies the resource as 'detailed information about a specific publisher'. It mentions specific properties like 'customization prefix, option value prefix, and configuration', which helps distinguish it from generic retrieval tools. However, it doesn't explicitly differentiate from sibling tools like 'list_dataverse_publishers' beyond implying this is for a single publisher versus a list.
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 implied usage guidance by stating 'Use this to inspect publisher properties and understand customization settings', which suggests when this tool is appropriate. However, it doesn't explicitly mention when not to use it or name alternatives like 'list_dataverse_publishers' for browsing multiple publishers, leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'retrieves' and 'inspect,' implying a read-only operation, but doesn't disclose behavioral traits such as authentication requirements, rate limits, error handling, or what happens if the table doesn't exist. For a tool with zero annotation coverage, this is a significant gap in transparency.
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 two sentences, front-loaded with the core purpose and followed by usage guidance. It's efficient with minimal waste, though it could be slightly more structured by separating purpose and guidelines more clearly. Every sentence adds value, earning a high score for conciseness.
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's low complexity (1 parameter, no output schema, no annotations), the description is adequate but incomplete. It covers purpose and basic usage but lacks behavioral details like error handling or return format. For a read operation with no output schema, more context on what 'detailed information' includes would improve 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?
Schema description coverage is 100%, with the single parameter 'logicalName' documented as 'Logical name of the table to retrieve.' The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. With high schema coverage, 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.
Purpose4/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: 'Retrieves detailed information about a specific Dataverse table including its metadata, properties, and configuration.' It specifies the verb 'retrieves' and resource 'Dataverse table' with scope 'detailed information.' However, it doesn't explicitly distinguish from siblings like 'list_dataverse_tables' or 'get_dataverse_column,' which would require a 5.
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 includes 'Use this to inspect table definitions and understand table structure,' which implies usage context for inspecting specific tables. However, it lacks explicit guidance on when to use this versus alternatives like 'list_dataverse_tables' for listing tables or 'get_dataverse_column' for column details, and no exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It correctly implies a read-only operation ('retrieves', 'shows'), but doesn't address critical behavioral aspects like authentication requirements, rate limits, error conditions, pagination, or response format. The description provides basic intent but lacks operational 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 efficiently structured in two sentences: the first states the core functionality, the second provides usage context. Every word serves a purpose with zero redundancy, and key information is front-loaded. It's appropriately sized for a single-parameter read tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficiently complete. While it states the purpose clearly, it doesn't describe the return format (what privileges look like), error handling, or operational constraints. Given the complexity of security/privilege data and absence of structured output documentation, more behavioral context is needed.
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 100% description coverage, with the roleId parameter clearly documented. The description doesn't add any parameter-specific information beyond what the schema already provides (e.g., format examples, validation rules, or relationship to other tools). This meets the baseline expectation when schema coverage is complete.
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 the tool's purpose with specific verbs ('retrieves', 'shows') and resource ('privileges assigned to a security role'). It distinguishes this as a read operation focused on privileges rather than role metadata, but doesn't explicitly differentiate from potential sibling tools like 'get_dataverse_role' which might retrieve role properties rather than privileges.
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 implied usage context ('audit role permissions', 'understand what access a role provides'), suggesting this is for permission analysis rather than role management. However, it doesn't explicitly state when to use this versus alternatives like 'get_dataverse_role' or 'list_dataverse_roles', nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions filtering options and some use cases, it doesn't describe important behavioral aspects like whether this is a read-only operation, potential rate limits, authentication requirements, pagination behavior, or what happens when no publishers match filters. The description adds some context but leaves significant gaps for a tool with mutation siblings.
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 appropriately sized with two sentences that efficiently cover purpose and usage. The first sentence states the core functionality, and the second provides use case examples. There's minimal redundancy, though the phrase 'with filtering options' could be slightly more specific given the schema already documents this.
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 no annotations and no output schema, the description provides adequate basic information but lacks completeness for a tool in a context with many mutation siblings. It doesn't clarify whether this is a safe read operation versus potentially having side effects, nor does it describe return format or error conditions. For a list operation with filtering, more behavioral context would be helpful.
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 100%, so the schema already documents both parameters completely. The description mentions 'filtering options' which aligns with the 'customOnly' parameter, and 'discover available publishers' relates to the list retrieval, but adds no specific syntax, format, or semantic details beyond what the schema provides. Baseline 3 is appropriate when schema does the heavy lifting.
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 the tool retrieves a list of publishers in the Dataverse environment with filtering options. It specifies the resource (publishers) and verb (retrieves/list), but doesn't explicitly differentiate from potential sibling tools like 'get_dataverse_publisher' which appears to fetch a single publisher rather than a list.
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 implied usage context with phrases like 'Use this to discover available publishers, find custom publishers for solution creation, or get an overview of publisher configurations.' However, it doesn't explicitly state when to use this tool versus alternatives like 'get_dataverse_publisher' or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'filtering options' and 'publisher information,' which adds some behavioral context, but fails to disclose critical traits: whether this is a read-only operation, potential rate limits, pagination behavior (implied by 'top' parameter but not explained), or error conditions. For a list tool with no annotations, this leaves significant gaps in understanding how it behaves.
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 appropriately sized (three sentences) and front-loaded with the core purpose. Each sentence adds value: the first states the action, the second gives usage scenarios, and the third notes included data. There's minimal waste, though it could be slightly more structured (e.g., bullet points for usage cases).
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's moderate complexity (list operation with 2 parameters), no annotations, and no output schema, the description is adequate but incomplete. It covers the 'what' and 'why' but misses behavioral details (e.g., safety, performance) and output format. For a tool in a Dataverse context with many siblings, more guidance on typical use cases or limitations 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?
Schema description coverage is 100%, so the schema already documents both parameters ('includeManaged' and 'top') fully. The description adds marginal value by implying filtering (via 'filtering options') and mentioning 'unmanaged solutions' (related to 'includeManaged'), but doesn't provide additional syntax, format, or examples beyond what the schema states. Baseline 3 is appropriate when schema does the heavy lifting.
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 the tool's purpose: 'Retrieves a list of solutions in the Dataverse environment with filtering options.' It specifies the verb ('retrieves'), resource ('solutions'), and scope ('Dataverse environment'), and distinguishes from siblings like 'get_dataverse_solution' (singular) by emphasizing listing. However, it doesn't explicitly contrast with other list_* tools (e.g., list_dataverse_tables), so it's not a perfect 5.
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 implied usage scenarios: 'Use this to discover available solutions, find unmanaged solutions for customization, or get an overview of solution packages.' This gives context but lacks explicit when-not-to-use guidance or named alternatives. For example, it doesn't clarify if 'get_dataverse_solution' should be used for detailed info on a specific solution, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It indicates this is a mutation tool ('Updates'), but doesn't describe what happens on success/failure, whether changes are reversible, authentication requirements, rate limits, or response format. For a tool with 13 parameters and no output schema, this leaves significant behavioral gaps.
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 perfectly concise with two sentences that each earn their place. The first sentence states the core purpose, and the second provides important clarification about what this tool does NOT do (change membership). No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex mutation tool with 13 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what happens after the update, error conditions, permission requirements, or how it differs from other update tools in the sibling list. The agent would need to guess about important behavioral aspects.
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 100%, so the schema already documents all 13 parameters thoroughly with descriptions, enums, and constraints. The description adds minimal value by mentioning examples like 'name, description, administrator' which are already in the schema, but doesn't provide additional context about parameter interactions or usage patterns beyond what's in the structured schema.
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 the verb ('Updates') and resource ('properties and configuration of an existing team'), with specific examples of settings that can be modified (name, description, administrator). It distinguishes from membership changes by explicitly stating 'without changing team membership', which helps differentiate from sibling tools like add_members_to_team and remove_members_from_team, though it doesn't explicitly name those alternatives.
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 some implied guidance by stating 'without changing team membership', suggesting this tool is for property updates rather than membership management. However, it doesn't explicitly state when to use this versus other update tools (like update_dataverse_businessunit or update_dataverse_role) or mention prerequisites like required permissions or team existence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states this is a creation tool, implying a write operation, but does not disclose behavioral traits such as required permissions, whether the operation is idempotent, error handling, or what the response includes (e.g., returns a business unit ID). This is a significant gap for a mutation tool with zero 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and followed by a brief context sentence. It is efficient with zero waste, though it could be slightly more structured (e.g., separating usage notes).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (49 parameters, mutation tool), lack of annotations, and no output schema, the description is incomplete. It does not address key aspects like required permissions, response format, error conditions, or dependencies (e.g., parent business unit existence), leaving significant gaps for an AI 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?
Schema description coverage is 100%, so the schema fully documents all 49 parameters. The description adds minimal value by mentioning 'comprehensive configuration options including contact information, addresses, and organizational hierarchy,' which loosely maps to some parameter categories but does not provide additional syntax or format details beyond what the schema provides. Baseline 3 is appropriate when the 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 the verb ('Creates') and resource ('new business unit in Dataverse'), and specifies the scope ('comprehensive configuration options including contact information, addresses, and organizational hierarchy'). It distinguishes from siblings like 'update_dataverse_businessunit' and 'delete_dataverse_businessunit' by focusing on creation.
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 by mentioning business units are 'used to organize users and control data access in Dataverse,' which provides some context. However, it lacks explicit guidance on when to use this tool versus alternatives like 'set_businessunit_parent' for hierarchy changes or prerequisites for creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions retrieving 'detailed information' but doesn't disclose behavioral traits such as whether this is a read-only operation (implied by 'Retrieves'), error handling for non-existent option sets, authentication needs, rate limits, or response format. This leaves significant gaps for a tool that likely interacts with a database system.
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 core purpose and followed by a usage hint. Every sentence earns its place by adding value without redundancy, making it efficient and well-structured for quick comprehension.
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's low complexity (1 parameter, no nested objects) and high schema coverage, the description is adequate but incomplete. It lacks output schema, so it doesn't explain return values like the structure of metadata or options, and with no annotations, it misses behavioral context. For a retrieval tool, this is minimally viable but leaves room for improvement in detailing response format.
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 100% description coverage, with the 'name' parameter documented as 'Name of the option set to retrieve.' The description adds minimal value beyond this, only implying the parameter is used to specify which option set. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't provide additional syntax or format details.
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 the verb ('Retrieves') and resource ('detailed information about a specific option set'), specifying what metadata is included. It distinguishes from siblings like 'list_dataverse_optionsets' by focusing on a single option set rather than listing multiple. However, it doesn't explicitly contrast with 'get_dataverse_optionset_options' (a sibling tool), which might retrieve just the options, not the full metadata.
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 by stating 'Use this to inspect option set definitions and understand available choices,' which suggests it's for detailed inspection rather than listing. However, it lacks explicit guidance on when to use this versus alternatives like 'list_dataverse_optionsets' for overviews or 'get_dataverse_optionset_options' for just options, and doesn't mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates this is a read operation ('retrieves'), but it doesn't cover critical aspects like authentication requirements, rate limits, error handling, or whether it's idempotent. For a tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
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 efficiently structured in two sentences: the first states the purpose and scope, and the second provides usage guidance. Every word earns its place, with no redundancy or fluff, making it easy to parse and understand quickly.
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's moderate complexity (single parameter, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and usage but lacks behavioral details (e.g., permissions, errors) and doesn't explain the return format, which is problematic since there's no output schema. This leaves the agent with gaps in fully understanding the tool's 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 100% description coverage, with 'uniqueName' clearly documented as 'Unique name of the solution to retrieve.' The description adds no additional parameter details beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 the tool's purpose with specific verbs ('retrieves detailed information') and resources ('specific solution'), and it lists the types of information returned (metadata, version, publisher details, configuration). However, it doesn't explicitly differentiate from sibling tools like 'list_dataverse_solutions' or 'get_solution_context', which reduces clarity in a crowded toolset.
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 implied usage guidance by stating 'Use this to inspect solution properties and understand solution structure,' which suggests it's for detailed examination rather than listing. However, it lacks explicit when-to-use vs. when-not-to-use instructions or named alternatives (e.g., compared to 'list_dataverse_solutions' for a high-level overview), leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a listing operation but doesn't describe return format, pagination behavior, permissions required, rate limits, or whether results are cached. The description adds minimal behavioral context beyond the basic 'list' action.
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 efficiently structured in two sentences: the first states the core functionality with scope options, the second provides usage context. Every word serves a purpose with zero redundancy or unnecessary elaboration.
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?
For a read-only listing tool with full parameter documentation but no annotations and no output schema, the description provides adequate but minimal context. It covers the what and why but lacks details about return format, permissions, or system behavior that would be helpful for an AI agent invoking this 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 100%, so the schema already fully documents all three parameters. The description mentions 'specific table or across all tables' which aligns with the entityLogicalName parameter, but adds no additional semantic context beyond what's in the schema. This meets the baseline for high schema coverage.
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 the tool's purpose: 'Lists all AutoNumber columns' with scope options ('in a specific table or across all tables'). It specifies the resource (AutoNumber columns) and verb (lists), but doesn't explicitly differentiate from sibling tools like 'get_autonumber_column' or 'convert_to_autonumber' beyond the 'list' vs 'get' distinction.
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 context ('Helps identify existing AutoNumber implementations') but doesn't provide explicit guidance on when to use this tool versus alternatives like 'get_autonumber_column' (for single column details) or 'list_dataverse_columns' (for all column types). No when-not-to-use or prerequisite information is included.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it lists operations like 'add/remove' and 'configure', it doesn't describe what these operations actually do behaviorally - whether they make permanent changes, require specific permissions, have side effects, or return specific output formats. For a tool with 8 parameters and multiple mutation operations, this is a significant gap.
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 efficiently structured in a single sentence that front-loads the main purpose. It lists key operations without unnecessary elaboration. However, it could be slightly more concise by avoiding the repetition of 'PowerPages' and 'configuration'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 8 parameters, multiple operation types (including mutations), and no output schema, the description is insufficient. It doesn't explain what the tool returns, how different operations interact, or what happens when configurations are modified. Without annotations to provide behavioral context, the description should do more to compensate.
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 100%, so the schema already documents all parameters thoroughly. The description mentions 'add/remove WebAPI access for tables' and 'configure table permissions' which loosely maps to some parameters but doesn't add meaningful semantic context beyond what's in the schema. Baseline 3 is appropriate when the 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 the tool's purpose with specific verbs ('manage', 'add/remove', 'configure', 'check') and resources ('PowerPages WebAPI configurations and table permissions'). It distinguishes itself from siblings by focusing on PowerPages-specific WebAPI configuration rather than general Dataverse 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 for PowerPages portal configuration but doesn't provide explicit guidance on when to use this tool versus alternatives. No sibling tools are mentioned, and there's no discussion of prerequisites or exclusions for specific operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action ('Adds privileges') without disclosing behavioral traits like required permissions, whether this is idempotent, what happens on duplicate privileges, or error conditions. It mentions access levels but doesn't explain their implications or system impact.
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 appropriately sized with two sentences that efficiently convey purpose and key concepts. The first sentence states the core action, and the second provides important context about privilege types and access levels without unnecessary elaboration.
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?
For a mutation tool with no annotations and no output schema, the description provides adequate basic information about what the tool does but lacks completeness regarding behavioral details, error handling, or response format. It covers the 'what' but not the 'how' or 'what happens after' sufficiently.
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 100%, so the baseline is 3. The description adds some context about privileges including operations (create/read/write/delete) and access levels (Basic/Local/Deep/Global), which provides meaning beyond the schema's technical parameter definitions, but doesn't fully explain how these map to the 'privilegeId' 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 verb ('Adds') and resource ('specific privileges...to a security role'), specifying the operation as granting permissions for create/read/write/delete operations on entities or system functions. It distinguishes from sibling tools like 'remove_privilege_from_role' and 'replace_role_privileges' by focusing on additive permission assignment.
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 context ('grant permissions for specific operations') but doesn't explicitly state when to use this tool versus alternatives like 'replace_role_privileges' or 'remove_privilege_from_role'. It mentions what the tool does but lacks explicit guidance on scenarios or prerequisites for use.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'filtering options' and 'supports filtering by business unit, team type, and system-managed status,' which adds some context beyond the schema. However, it does not cover important aspects like whether this is a read-only operation, potential rate limits, authentication needs, or pagination behavior, leaving gaps in transparency.
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 appropriately sized with three sentences that are front-loaded with the core purpose. Each sentence adds value: the first states the action, the second provides usage contexts, and the third details filtering support. There is no wasted text, though it could be slightly more structured for clarity.
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 complexity of a list tool with 6 parameters, no annotations, and no output schema, the description is moderately complete. It covers the purpose and filtering capabilities but lacks details on behavioral traits, output format, and explicit differentiation from siblings. This is adequate for a basic list operation but has clear gaps in providing full 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?
The input schema has 100% description coverage, providing detailed parameter documentation. The description adds minimal value by summarizing filtering options ('business unit, team type, and system-managed status'), but does not elaborate on parameter semantics beyond what the schema already states. This meets the baseline score of 3 for high schema coverage.
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 the tool's purpose: 'Retrieves a list of teams in the Dataverse environment with filtering options.' It specifies the verb ('retrieves'), resource ('teams'), and scope ('Dataverse environment'), but does not explicitly differentiate it from sibling tools like 'get_dataverse_team' or 'get_businessunit_teams', which prevents a score of 5.
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 implied usage guidance by stating 'Use this to discover available teams, find teams by business unit or type, or get an overview of team organization.' This suggests contexts for use, but it does not explicitly state when to choose this tool over alternatives like 'get_businessunit_teams' or when not to use it, lacking clear exclusions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is an update operation but doesn't disclose behavioral traits like required permissions, whether changes are reversible, error conditions, or rate limits. The mention of 'without changing the actual privileges' adds some context but is insufficient for a mutation tool.
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 efficiently structured in two sentences: the first states the purpose with examples, and the second clarifies the scope regarding privileges. It's front-loaded and wastes no words, though it could be slightly more concise by integrating the privilege clarification into the main sentence.
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?
For a mutation tool with no annotations and no output schema, the description is moderately complete. It covers the purpose and scope but lacks behavioral details like permissions, side effects, or response format. Given the complexity of updating security roles, more guidance on usage and constraints would be beneficial.
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 100%, so the schema already documents all 7 parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema, such as format details or usage examples. Baseline 3 is appropriate when 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 the verb ('Updates'), resource ('existing security role'), and scope ('properties and configuration') with specific examples like name, description, auto-assignment behavior, and inheritance settings. It distinguishes from siblings like 'create_dataverse_role' (creation) and 'delete_dataverse_role' (deletion) by focusing on modification.
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 modifying role settings without changing privileges, but doesn't explicitly state when to use this tool versus alternatives like 'add_privileges_to_role' or 'replace_role_privileges'. No exclusions or prerequisites are mentioned, leaving some ambiguity about context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool retrieves data (implying read-only) but does not disclose behavioral traits such as permissions required, rate limits, pagination, or error handling. The description adds minimal context beyond the basic operation.
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 (two sentences) and front-loaded with the core purpose. Every sentence adds value: the first specifies the action and data, the second provides usage context, with 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?
Given no annotations and no output schema, the description is incomplete for a tool that retrieves data. It covers the purpose and data fields but lacks details on return format, error cases, or behavioral constraints. However, it is adequate for a simple read operation with one 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 100% (one parameter 'name' with clear description), so the baseline is 3. The description does not add meaning beyond the schema, as it only mentions 'specific option set' without detailing parameter syntax or format.
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 ('Retrieves') and resource ('all options within a specific option set'), specifying the exact data returned (values, labels, descriptions, colors). It distinguishes from sibling tools like 'get_dataverse_optionset' (which likely retrieves metadata) by focusing on the options/choices within the set.
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 ('Use this to inspect...') but does not explicitly state when to use this tool versus alternatives like 'get_dataverse_optionset' or 'list_dataverse_optionsets'. It provides a general context (inspecting choices) without exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'filtering options' and 'supports filtering by custom/system tables and managed/unmanaged status,' which adds some context about capabilities. However, it doesn't describe critical behaviors like whether this is a read-only operation (implied by 'retrieves' but not explicit), potential rate limits, authentication requirements, pagination, or error conditions. For a list tool with zero annotation coverage, this leaves significant gaps.
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 efficiently structured in two sentences. The first sentence states the core purpose, and the second adds usage context and filtering details. Every sentence earns its place with no redundant information, making it appropriately sized and front-loaded for quick comprehension.
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's moderate complexity (list operation with filtering), no annotations, and no output schema, the description is partially complete. It covers the purpose and usage scenarios but lacks details on behavioral traits (e.g., read-only nature, response format, pagination) that would be crucial for an AI agent. With no output schema, the description should ideally hint at return values, but it doesn't, leaving gaps in contextual understanding.
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 100% description coverage, with all three parameters well-documented in the schema itself. The description adds marginal value by mentioning 'filtering by custom/system tables and managed/unmanaged status,' which loosely maps to the 'customOnly' and 'includeManaged' parameters but doesn't provide additional syntax or format details beyond what the schema already states. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't significantly enhance parameter understanding.
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 the tool's purpose: 'Retrieves a list of tables in the Dataverse environment with filtering options.' It specifies the verb ('retrieves'), resource ('tables in the Dataverse environment'), and scope ('with filtering options'). However, it doesn't explicitly differentiate from sibling tools like 'get_dataverse_table' (which likely retrieves a single table) or 'list_dataverse_columns' (which lists columns), so it misses full 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Use this to discover available tables, find custom tables, or get an overview of the data model.' This gives practical scenarios for when to use the tool. However, it doesn't explicitly state when not to use it or name alternatives (e.g., 'get_dataverse_table' for single table details), so it lacks full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but provides minimal behavioral information. It mentions the effect ('granting all team members the permissions') but doesn't disclose important traits like whether this is a write operation, what permissions are required, whether it's idempotent, or what happens on failure. For a security role assignment tool with zero annotation coverage, this is inadequate.
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 efficiently structured in two sentences: the first states the action and effect, the second provides usage context. Every sentence earns its place with no wasted words, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a security/permissions mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns, error conditions, side effects, or security implications. The description should provide more complete context given the tool's complexity and lack of structured metadata.
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 100%, so the schema already documents both parameters completely. The description doesn't add any parameter-specific information beyond what's in the schema (roleId and teamId). This meets the baseline expectation when schema coverage is high.
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 ('Assigns a security role to a team') and the outcome ('granting all team members the permissions defined in that role'). It distinguishes from sibling tools like 'assign_role_to_user' by specifying it applies to teams rather than individual users.
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 provide consistent access levels to groups of users working together on similar tasks'), which helps differentiate it from user-level assignment. However, it doesn't explicitly mention when NOT to use it or name specific alternatives like 'assign_role_to_user'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions the tool 'creates' a relationship and supports specific types, it lacks critical behavioral details such as required permissions, whether the operation is idempotent, error conditions, or what happens on failure. For a complex mutation tool with 21 parameters, this is a significant gap.
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 in the first sentence, followed by supporting details in two additional sentences. Every sentence earns its place by clarifying relationship types and usage context, with zero waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (21 parameters, mutation operation, no output schema, and no annotations), the description is incomplete. It lacks behavioral transparency, does not explain return values or error handling, and relies entirely on the schema for parameter details. For such a sophisticated tool, more contextual guidance is needed.
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 100%, so the schema already documents all 21 parameters thoroughly. The description adds minimal value beyond the schema by mentioning relationship types (One-to-Many/Many-to-Many) and high-level purposes, but does not provide additional syntax, format, or usage details for parameters. Baseline 3 is appropriate when the 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 the verb 'creates' and resource 'relationship between two Dataverse tables', specifying the supported relationship types (One-to-Many and Many-to-Many). It distinguishes from siblings like 'delete_dataverse_relationship' by focusing on creation and from other table/column tools by emphasizing data connections.
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 establish data connections between tables, enable navigation, and maintain referential integrity.' However, it does not explicitly mention when not to use it or name alternatives (e.g., vs. updating existing relationships), 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that this is a mutation tool ('Sets'), mentions environment-specific behavior and solution exclusion, but doesn't cover permission requirements, rate limits, or what happens to existing records. It adds some behavioral context but leaves significant gaps for a mutation operation.
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 appropriately sized with two sentences that each add value: the first states the core purpose, the second provides important behavioral context. It's front-loaded with the main action and avoids unnecessary repetition.
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?
For a mutation tool with no annotations and no output schema, the description provides basic purpose and some behavioral context but lacks details about permissions, error conditions, or response format. It's minimally adequate but has clear gaps given the tool's complexity and mutation nature.
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 100%, so the schema already fully documents all three parameters. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score of 3 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 clearly states the specific action ('Sets the seed value'), identifies the target resource ('AutoNumber column's sequential segment'), and distinguishes it from siblings like 'update_autonumber_format' or 'create_autonumber_column' by focusing on seed configuration rather than format creation or modification.
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 context through 'controls the starting number for future records' and notes environment-specific behavior, but doesn't explicitly state when to use this versus alternatives like 'update_autonumber_format' or mention prerequisites. It provides some guidance but lacks explicit when/when-not instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions that the tool creates a 'global option set' and describes its purpose, it lacks critical details such as required permissions, whether the operation is idempotent, error conditions, or what happens on success/failure. For a creation tool with zero annotation coverage, this is a significant gap.
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 efficiently structured in three sentences: the first states the core action, the second explains usage context, and the third highlights benefits. Each sentence adds value without redundancy, making it front-loaded and appropriately sized.
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's complexity (creation operation with 5 parameters) and lack of annotations and output schema, the description is adequate but has clear gaps. It explains the 'what' and 'why' but omits behavioral details like permissions, side effects, or response format. For a creation tool, this leaves the agent under-informed about critical operational aspects.
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 100%, so the schema already documents all 5 parameters thoroughly. The description adds no additional parameter-specific information beyond what the schema provides, such as examples or constraints not in the schema. The baseline score of 3 is appropriate when the 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 the specific action ('Creates a new global option set'), resource ('in Dataverse'), and purpose ('with predefined options'). It distinguishes this tool from siblings like 'update_dataverse_optionset' or 'get_dataverse_optionset' by emphasizing creation rather than modification or 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 provides clear context on when to use this tool ('to create reusable choice lists that can be used across multiple tables and columns'), explaining its benefits for data consistency and quality. However, it does not explicitly state when NOT to use it or mention alternatives like 'update_dataverse_optionset' for modifying existing option sets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions that publishers are 'required for creating solutions,' it doesn't disclose important behavioral traits like whether this is a write operation (implied but not stated), what permissions are needed, whether the creation is permanent or reversible, or what happens on failure. For a creation tool with zero annotation coverage, this leaves significant gaps.
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 perfectly concise with two sentences that each earn their place. The first sentence states the core purpose, and the second provides essential usage context. There's zero wasted language, and the information is front-loaded appropriately.
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 that this is a creation tool with no annotations and no output schema, the description should do more to compensate. While it explains the purpose and basic usage context, it doesn't address behavioral aspects like error conditions, response format, or system impacts. The 100% schema coverage helps, but for a write operation, the description lacks 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 schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description adds some context about why publishers matter ('provide customization prefixes for schema names'), which relates to the 'customizationPrefix' parameter, but doesn't provide additional parameter-specific semantics beyond what the schema descriptions already offer.
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 ('creates a new publisher'), resource ('in Dataverse'), and purpose ('required for creating solutions and provide customization prefixes for schema names'). It distinguishes this tool from sibling tools like 'get_dataverse_publisher' or 'list_dataverse_publishers' by focusing on creation rather than 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 provides clear context for when to use this tool ('to establish a publisher identity before creating solutions and custom components'), which helps guide the agent. However, it doesn't explicitly state when NOT to use it or mention specific alternatives like 'update_dataverse_publisher' (though that tool doesn't exist in the sibling list).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the tool creates a security role but does not disclose behavioral traits such as required permissions, whether the operation is idempotent, potential side effects, or error conditions. For a mutation tool with zero annotation coverage, this is a significant gap in 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 appropriately sized and front-loaded, with three concise sentences that each add value: the first states the action, the second explains the purpose of security roles, and the third provides usage context. There is no wasted text.
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?
For a mutation tool with no annotations and no output schema, the description is adequate but incomplete. It covers the purpose and usage context well, but lacks details on behavioral aspects like permissions, side effects, or response format. Given the complexity of creating security roles, more completeness would be beneficial.
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 100%, so the schema already documents all 7 parameters thoroughly. The description does not add any parameter-specific details beyond what the schema provides, such as examples or usage tips. Baseline 3 is appropriate when the 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 the specific action ('Creates a new security role') and resource ('in Dataverse'), with additional context about its function ('define permissions and access levels for users and teams'). It distinguishes from siblings like 'update_dataverse_role' (modification) and 'delete_dataverse_role' (removal) by focusing on creation.
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 establish custom permission sets for different user types or job functions'), but does not explicitly mention when not to use it or name specific alternatives (e.g., 'update_dataverse_role' for modifications). This is helpful but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions the tool creates teams and describes team types, it doesn't address critical behavioral aspects like required permissions, whether the operation is idempotent, what happens on failure, or what the response contains. For a creation tool with 13 parameters, this leaves significant gaps.
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 efficiently structured in two sentences: the first states the core purpose and team types, the second provides usage context. Every word earns its place with no redundancy or fluff. It's appropriately sized for the tool's complexity.
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's complexity (13 parameters, creation operation) and absence of both annotations and output schema, the description is adequate but incomplete. It covers the 'what' and 'why' well but lacks information about behavioral characteristics, error handling, and response format. For a creation tool with many parameters, more context would be beneficial.
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 100%, so the schema already documents all 13 parameters thoroughly. The description adds minimal parameter semantics beyond the schema - it mentions team types (owner vs. access) which relates to the 'teamType' parameter, but doesn't provide additional context about parameter interactions or usage patterns. This meets 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 clearly states the verb 'creates' and resource 'new team in Dataverse', specifies the purpose ('organizing users and managing permissions'), and distinguishes between team types (owner vs. access teams). It differentiates from siblings like 'update_dataverse_team' or 'delete_dataverse_team' by focusing on creation.
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 establish groups of users who work together and need similar access levels'), but doesn't explicitly mention when NOT to use it or name specific alternatives among the many sibling tools. The guidance is helpful but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool 'creates visual documentation' and saves a file, implying a write operation, but does not specify file format details (e.g., .mmd), potential side effects, permissions required, or error handling. For a tool with no annotations and file output, this leaves significant gaps in understanding its 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?
The description is front-loaded with the core purpose in the first sentence, followed by additional context. It consists of only two sentences with zero waste, efficiently conveying the tool's value without unnecessary elaboration.
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's complexity (generating diagrams from JSON files), no annotations, and no output schema, the description is minimally adequate. It covers the purpose and usage context but lacks details on output format, error conditions, or dependencies. For a tool with 5 parameters and file generation, more completeness would be beneficial.
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 100%, so the schema already documents all 5 parameters thoroughly. The description adds no additional parameter semantics beyond what the schema provides, such as explaining the relationship between schemaPath and the JSON structure. Baseline 3 is appropriate when the 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 the tool's purpose: 'Generates a Mermaid entity relationship diagram from an exported schema JSON file.' It specifies the verb ('generates'), resource ('Mermaid entity relationship diagram'), and source ('exported schema JSON file'). It distinguishes from siblings by focusing on diagram generation rather than data operations like create, update, or delete.
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: 'Perfect for documentation, presentations, and understanding data structure.' It implies usage for visual documentation purposes. However, it does not explicitly state when not to use it or name specific alternatives among siblings, such as export_solution_schema for raw schema export.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves data, implying a read-only operation, but does not address potential behavioral traits like error handling, rate limits, authentication requirements, or what happens if the business unit ID is invalid. For a tool with zero annotation coverage, this leaves significant gaps in understanding its operational 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?
The description is appropriately sized and front-loaded, with two concise sentences: the first states the core functionality, and the second provides usage context. Every sentence earns its place without redundancy or unnecessary detail, making it efficient and easy to parse.
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's moderate complexity (2 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the purpose and basic usage but lacks details on behavioral aspects like error conditions or return format, which are important for a retrieval tool. Without annotations or output schema, more context on what the tool returns 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?
Schema description coverage is 100%, so the schema already fully documents both parameters (businessUnitId and includeSubsidiaryTeams). The description adds minimal value beyond the schema by mentioning the option to include subsidiary teams, but does not provide additional semantic context, such as how subsidiary relationships are defined or the impact on performance. Baseline 3 is appropriate when the 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 the verb ('Retrieves') and resource ('all teams associated with a specific business unit'), making the purpose specific and actionable. It distinguishes this tool from sibling tools like 'get_businessunit_users' or 'get_dataverse_team' by focusing on business unit-team relationships, not users or general team 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?
The description provides clear context for when to use this tool ('to understand team organization and business unit relationships'), which helps guide usage. However, it does not explicitly mention when not to use it or name specific alternatives among the many sibling tools, such as 'get_dataverse_team' for individual team details or 'get_businessunit_hierarchy' for broader unit structures.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. While it indicates this is a read operation ('retrieves'), it doesn't disclose important behavioral traits like whether it requires specific permissions, potential rate limits, error conditions, or what format the detailed information returns. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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 with zero waste. The first sentence states the purpose and scope, the second provides usage guidance. Every word earns its place, and the information is front-loaded with the core functionality stated immediately.
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?
For a read operation with 100% schema coverage and no output schema, the description is adequate but has clear gaps. It explains what the tool does and when to use it, but lacks behavioral context (permissions, errors, format) that would be important for an agent to use it correctly. The absence of annotations and output schema means the description should do more to compensate.
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 100% with one parameter clearly documented. The description adds minimal value beyond the schema by implying the parameter identifies 'a specific relationship' but doesn't provide additional context about schemaName format, examples, or relationship identification. Baseline 3 is appropriate when the 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 the verb 'retrieves' and resource 'detailed information about a specific relationship between Dataverse tables', specifying what information is included (configuration, cascade settings, menu behavior). It distinguishes from sibling tools like 'list_dataverse_relationships' by focusing on a single relationship rather than listing multiple.
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: 'Use this to inspect relationship definitions and understand table connections.' This gives guidance on when to use the tool (for detailed inspection rather than listing). However, it doesn't explicitly mention when NOT to use it or name specific alternatives like 'list_dataverse_relationships' for broader overviews.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions filtering capabilities, it lacks details on permissions required, rate limits, pagination behavior, error handling, or the format of returned data. For a read operation with no annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 and front-loaded, with two sentences that efficiently convey purpose and usage without wasted words. Every sentence earns its place by adding specific value about the tool's function and context.
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 complexity of a list operation with filtering and no output schema, the description is partially complete. It covers the purpose and basic usage but lacks details on behavioral aspects like data format, pagination, or error handling, which are important for an agent to use the tool effectively in the absence of annotations and 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?
Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds marginal value by mentioning filtering by 'entity, relationship type, and managed/unmanaged status', which aligns with parameters like entityLogicalName, relationshipType, and includeManaged/customOnly, but does not provide additional syntax or usage details beyond what the schema already specifies.
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 ('Retrieves a list') and resource ('relationships in the Dataverse environment'), and distinguishes it from siblings by specifying its unique focus on relationships rather than other Dataverse components like tables, columns, or solutions. The mention of 'filtering options' adds specificity.
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 on when to use this tool ('to discover table connections, find custom relationships, or get an overview of the data model relationships'), but does not explicitly state when not to use it or name alternatives. It implies usage for relationship-focused tasks without direct comparison to other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool performs a removal/revocation action, implying mutation, but lacks details on permissions required, whether changes are reversible, side effects, or error conditions. For a security mutation tool, this is a significant gap in 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. First sentence states purpose and outcome, second provides usage context. Appropriately sized and 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?
Given no annotations and no output schema, the description is minimal but functional. It covers the basic purpose and usage, but for a security mutation tool, it should ideally include more about behavioral implications, permissions, or response format to be 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?
Schema description coverage is 100%, with clear parameter descriptions in the schema. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or relationship between privilegeId and roleId. Baseline 3 is appropriate when 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 the specific action ('Removes a specific privilege'), target resource ('from a security role'), and outcome ('revoking the associated permissions'). It distinguishes from siblings like 'add_privileges_to_role' and 'replace_role_privileges' by specifying removal rather than addition or replacement.
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 ('Use this to restrict access by removing specific operation permissions from a role'), but does not explicitly mention when not to use or name alternatives like 'replace_role_privileges' for bulk updates. It implies usage for fine-grained permission revocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it indicates this is a destructive permission-revoking operation, it lacks critical details like required permissions, whether the change is reversible, error conditions, or confirmation prompts. For a security mutation tool, this leaves significant gaps.
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 efficiently structured in two sentences: the first explains the action and effect, the second provides usage guidance. Every phrase adds value with zero wasted words, making it easy to parse.
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?
For a destructive security tool with no annotations and no output schema, the description provides adequate purpose and usage context but lacks behavioral details about permissions, reversibility, and error handling. It's minimally viable but has clear gaps given 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?
Schema description coverage is 100%, providing clear documentation for both roleId and teamId parameters. The description adds no additional parameter semantics beyond what the schema already states, so it meets the baseline expectation without adding 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 the specific action ('removes a security role assignment'), target resource ('from a team'), and effect ('revoking the permissions granted by that role for all team members'). It distinguishes from sibling tools like 'remove_role_from_user' by specifying team-level 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 explicit usage context ('when teams no longer need certain access levels or when restructuring team permissions'), which helps the agent understand when to invoke this tool. However, it doesn't mention alternatives like 'remove_privilege_from_role' or 'assign_role_to_team' for comparison.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It correctly identifies this as a creation operation and mentions the solution context requirement, but doesn't address important behavioral aspects like whether this operation is reversible, what permissions are needed, rate limits, or what happens if a column with the same name exists. The description provides basic context but lacks comprehensive behavioral details.
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 efficiently structured in three sentences: the core functionality, supported column types, usage purpose, and prerequisite. Each sentence adds value without redundancy. While very concise, it could potentially benefit from slightly more detail about behavioral aspects given the complexity of the tool.
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?
For a complex creation tool with 21 parameters and no annotations or output schema, the description provides adequate but minimal context. It covers the basic purpose and prerequisite but doesn't address important contextual aspects like error conditions, response format, or detailed behavioral expectations. The description is complete enough to understand what the tool does but leaves significant gaps in operational understanding.
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?
With 100% schema description coverage, the input schema already documents all 21 parameters thoroughly. The description mentions 'data type and configuration' which aligns with parameters like columnType and various configuration options, but doesn't add significant semantic value beyond what's already in the well-documented schema. The baseline of 3 is appropriate when the 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 the action ('Creates a new column'), specifies the resource ('in a Dataverse table'), and lists key configuration aspects ('data type and configuration'). It distinguishes from siblings like 'create_dataverse_table' (creates tables) and 'update_dataverse_column' (modifies existing columns).
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 it ('to add new fields to store specific data in your tables') and includes a prerequisite ('Requires a solution context to be set first'). However, it doesn't explicitly state when NOT to use it or name specific alternatives like 'update_dataverse_column' for modifying existing columns.
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?
With no annotations provided, the description carries full burden. It discloses that this is a mutation operation ('Converts') and specifies prerequisites (column type/format/data compatibility), which is valuable. However, it doesn't mention potential destructive effects on existing data, permission requirements, error conditions, or what happens to the column's properties beyond format addition.
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 perfectly concise with two sentences that each earn their place: the first states the core purpose, the second adds crucial prerequisites. It's front-loaded with the main action and wastes no 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?
For a mutation tool with no annotations and no output schema, the description provides adequate basic information about what the tool does and prerequisites. However, it lacks details about behavioral outcomes (what exactly gets modified, error handling, confirmation of success) that would be helpful given the tool's complexity and potential data impact.
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 100%, so the schema already documents all parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema descriptions, maintaining the baseline score of 3 for adequate but not enhanced parameter documentation.
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 ('Converts an existing text column to an AutoNumber column') and resource ('by adding an AutoNumberFormat'), distinguishing it from siblings like 'create_autonumber_column' (which creates new) or 'update_autonumber_format' (which modifies existing). It precisely defines the transformation operation.
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 it ('The column must be a String type with Text format and should be empty or contain compatible data'), which implicitly distinguishes it from creation tools. However, it doesn't explicitly mention when NOT to use it or name specific alternative tools like 'create_autonumber_column' for new columns.
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?
With no annotations provided, the description carries the full burden. It discloses that the tool creates a new column (implying a write operation) and mentions a prerequisite, but lacks details on permissions, side effects, error handling, or response format. The description adds some behavioral context but is incomplete for a mutation tool.
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 core purpose and followed by additional context. Every sentence earns its place: the first defines the tool, the second explains AutoNumber functionality, and the third states a critical prerequisite. 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?
For a mutation tool with 11 parameters, no annotations, and no output schema, the description is adequate but has gaps. It covers the purpose and a key prerequisite, but lacks details on behavioral traits like permissions, idempotency, or return values. Given the complexity, it should provide more guidance on usage and outcomes.
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 100%, so the schema fully documents all 11 parameters. The description adds minimal value by mentioning 'specified format' which relates to 'autoNumberFormat', but does not elaborate on parameter interactions or usage beyond what the schema provides. 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?
The description clearly states the action ('Creates'), the resource ('new AutoNumber column in a Dataverse table'), and the key feature ('with specified format'). It distinguishes from siblings like 'create_dataverse_column' by specifying the AutoNumber type and from 'convert_to_autonumber' by indicating creation rather than conversion.
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 a prerequisite ('Requires a solution context to be set first'), which provides clear when-to-use guidance. However, it does not mention when not to use this tool or name specific alternatives among siblings, such as 'create_dataverse_column' for non-AutoNumber columns.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It correctly identifies this as a creation/mutation operation ('Creates'), but doesn't mention permission requirements, whether the solution is immediately usable, potential rate limits, or what happens if a solution with the same unique name exists. It adds some context about solutions being 'containers for customizations' but lacks operational details.
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 efficiently structured in two sentences: the first states the core action and defines what solutions are, the second provides usage guidance. Every word earns its place with no redundancy or fluff, and key information is front-loaded.
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?
For a creation tool with no annotations and no output schema, the description provides adequate basic context about what solutions are and when to use this tool. However, it doesn't describe what the tool returns (e.g., solution ID, confirmation message) or address potential error conditions. Given the mutation nature and lack of structured output information, more behavioral details would be helpful.
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 100% description coverage, providing clear documentation for all 5 parameters. The description doesn't add any parameter-specific information beyond what's in the schema, but it does provide the overall context that solutions are for 'packaging, deploying, and managing custom components,' which helps understand why these parameters matter. Baseline 3 is appropriate given complete 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 specific action ('Creates a new unmanaged solution'), identifies the resource ('in Dataverse'), and distinguishes it from siblings by focusing on solution creation rather than other Dataverse operations like creating tables, columns, or publishers. It explains what solutions are used for, providing context beyond just the action.
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 ('Use this to create a solution before adding tables, columns, and other customizations'), establishing it as a prerequisite step in a customization workflow. However, it doesn't explicitly mention when NOT to use it or name specific alternatives among the many sibling tools, such as 'create_dataverse_publisher' which might be needed first.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It correctly identifies this as a creation operation and mentions the solution context prerequisite, but doesn't address important behavioral aspects like whether this operation is reversible, what permissions are required, potential rate limits, or what happens if creation fails. The description provides basic behavioral context but leaves significant gaps.
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 perfectly concise with just two sentences that each earn their place. The first sentence states the core purpose, and the second provides essential usage context and prerequisites. There's no wasted language or redundancy.
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 this is a creation tool with 13 parameters, no annotations, and no output schema, the description provides basic completeness but has significant gaps. It covers the 'what' and 'when' but lacks information about the return value, error conditions, permissions required, or system impacts. For a complex creation operation in Dataverse, more contextual information would be helpful.
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 description coverage is 100%, so the schema already documents all 13 parameters thoroughly. The description mentions 'specified configuration' but doesn't add any meaningful parameter semantics beyond what's in the schema. It doesn't explain relationships between parameters or provide usage examples for complex parameters like 'primaryNameAutoNumberFormat'.
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 ('Creates a new custom table') and resource ('in Dataverse'), distinguishing it from sibling tools like 'create_dataverse_column' or 'create_dataverse_solution'. It explicitly identifies what type of entity is being created and for what purpose ('to store business data').
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 ('when you need to create a new entity to store business data') and includes an important prerequisite ('Requires a solution context to be set first'). However, it doesn't explicitly mention when NOT to use it or name specific alternatives among the sibling tools for similar operations.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the option to include subsidiary users, which adds useful context, but does not cover other behavioral aspects like permissions required, rate limits, pagination, or what happens if the business unit doesn't exist. This leaves gaps for a read operation tool.
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 with two sentences that are front-loaded with the core purpose and usage context. Every sentence earns its place by providing essential information without redundancy or unnecessary details.
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's moderate complexity (2 parameters, no output schema, no annotations), the description is somewhat complete but lacks details on behavioral aspects like error handling or response format. It adequately covers the purpose and basic usage but could benefit from more context to fully guide an AI agent.
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 100% description coverage, so the schema already documents both parameters thoroughly. The description mentions the option to include subsidiary users, which aligns with the includeSubsidiaryUsers parameter, but does not add significant meaning beyond what the schema provides, resulting in 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's purpose with a specific verb ('Retrieves') and resource ('all users associated with a specific business unit'), and distinguishes it from sibling tools like get_team_members or get_dataverse_businessunit by focusing on user retrieval within a business unit context.
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 understand user assignments and organizational membership'), but does not explicitly mention when not to use it or name alternative tools for similar purposes, such as get_team_members for team-specific user retrieval.
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?
No annotations are provided, so the description carries the full burden. It describes the tool as a retrieval operation ('Retrieves detailed information'), which correctly implies it's a read-only operation. However, it doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or response format details.
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 efficiently structured in two sentences: the first states the purpose and scope, the second provides usage guidance. Every sentence adds value with zero wasted words, making it appropriately sized and front-loaded.
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's moderate complexity (retrieving detailed column information), no annotations, and no output schema, the description is adequate but incomplete. It explains what the tool does and when to use it, but lacks details on return values, error handling, or behavioral constraints that would be helpful for an agent.
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 100%, so the schema already documents both parameters ('entityLogicalName' and 'logicalName') with clear descriptions. The description adds no additional parameter semantics beyond what the schema provides, maintaining the 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 specific action ('Retrieves detailed information'), resource ('a specific column in a Dataverse table'), and scope ('including its data type, properties, and configuration settings'). It distinguishes from sibling tools like 'list_dataverse_columns' by focusing on a single column's details rather than listing multiple columns.
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 inspect column definitions and understand field structure'), but does not explicitly mention when not to use it or name alternatives. It implies usage for detailed inspection rather than listing, which helps differentiate from 'list_dataverse_columns'.
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?
No annotations are provided, so the description carries the full burden. It indicates this is a read operation ('retrieves'), which is helpful, but lacks details on permissions required, rate limits, error conditions, or output format. The description adds some behavioral context but is incomplete for a tool with no 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, front-loaded with the core purpose and followed by usage guidance. Every sentence adds value with no wasted words, making it efficient and well-structured.
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 no annotations and no output schema, the description provides adequate purpose and usage but lacks details on behavioral aspects (e.g., permissions, errors) and output format. It is complete enough for a basic read tool but could be more comprehensive to compensate for missing structured data.
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 100%, with the parameter 'roleId' documented as 'ID of the role to retrieve.' The description does not add any additional meaning beyond this, such as format examples or where to find the ID. Baseline 3 is appropriate when the 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 the verb 'retrieves' and the resource 'detailed information about a specific security role', specifying what properties are included (properties, business unit association, configuration settings). It distinguishes from siblings like 'list_dataverse_roles' (which lists roles) and 'get_role_privileges' (which focuses on privileges).
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 inspect role definitions and understand permission structures.' However, it does not explicitly state when not to use it or name alternatives (e.g., 'list_dataverse_roles' for listing roles without details), 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It correctly indicates this is a read operation ('retrieves'), but doesn't mention potential authentication requirements, rate limits, error conditions, or what happens if the team doesn't exist. The description adds some context about what information is returned, but leaves behavioral aspects incomplete.
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 efficiently structured in two sentences: the first states the core functionality and scope, the second provides usage guidance. Every sentence earns its place with no redundant information, making it appropriately sized and front-loaded.
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?
For a read operation with no annotations and no output schema, the description provides adequate but incomplete context. It specifies what information is returned, but doesn't describe the response format, potential pagination, or error handling. Given the tool's relative simplicity and complete parameter documentation, this represents a minimum viable level of 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 has 100% description coverage, with the 'teamId' parameter clearly documented. The description doesn't add any parameter-specific information beyond what the schema already provides, such as format examples or constraints. With complete schema coverage, 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 states the verb ('retrieves') and resource ('specific team'), specifies the scope of information returned ('properties, administrator, business unit association, and configuration settings'), and distinguishes from siblings like 'list_dataverse_teams' by focusing on a single team's details rather than listing multiple teams.
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 inspect team definitions and understand team structure'), which implicitly differentiates it from list operations. However, it doesn't explicitly mention when not to use it or name specific alternatives like 'list_dataverse_teams' for bulk retrieval.
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?
No annotations are provided, so the description carries full burden. It implies a read-only operation ('Retrieves') and hints at output content ('basic information and status'), but lacks details on permissions, rate limits, pagination, or error handling. The description adds some behavioral context but leaves gaps for a tool with no 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, front-loaded with the core purpose and followed by usage context. Every sentence adds value without redundancy, making it efficient and well-structured.
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 no annotations and no output schema, the description adequately covers the tool's purpose and usage but lacks details on behavioral traits like authentication needs or return format. It is complete enough for a simple read operation but could be more informative for agent 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 description coverage is 100%, with the single parameter 'teamId' well-documented in the schema. The description does not add any parameter-specific details beyond what the schema provides, such as format examples or constraints, so it meets 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 clearly states the verb ('Retrieves') and resource ('list of all users who are members of a specific team'), specifying the scope ('including their basic information and status'). It distinguishes from siblings like 'get_businessunit_users' by focusing on team membership rather than business unit affiliation.
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 usage ('to audit team membership and understand who has team-based access'), but does not explicitly state when NOT to use it or name specific alternatives among the many sibling tools, such as 'get_businessunit_users' for a different organizational scope.
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?
With no annotations provided, the description carries the full burden. It mentions filtering and sorting options which is helpful, but doesn't disclose important behavioral traits like pagination behavior (implied by 'top' parameter but not explained), rate limits, authentication requirements, or what happens when no results match filters. The description is adequate but lacks depth for a read operation.
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 perfectly concise with two sentences that each earn their place. The first sentence states the core functionality, and the second provides usage context. There's zero wasted language and it's front-loaded with the 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?
For a read-only list tool with 4 well-documented parameters but no output schema and no annotations, the description is minimally adequate. It covers the purpose and basic usage but lacks information about return format, pagination behavior, error conditions, or examples of filter/orderby syntax that would be helpful given the OData expressions mentioned in 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?
Schema description coverage is 100%, so the schema already fully documents all 4 parameters. The description mentions 'filtering and sorting options' which aligns with the schema parameters but doesn't add any meaningful semantic context beyond what the schema provides. The baseline of 3 is appropriate when the 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 the verb ('Retrieves') and resource ('list of business units in the Dataverse environment'), distinguishing it from siblings like 'get_dataverse_businessunit' (singular retrieval) and 'get_businessunit_hierarchy' (hierarchical view). It specifies the operation is a list retrieval with filtering and sorting capabilities.
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 discover available business units, understand organizational hierarchy, and find specific business units by criteria'), but doesn't explicitly state when not to use it or name specific alternatives like 'get_businessunit_hierarchy' for hierarchical views or 'get_dataverse_businessunit' for single unit retrieval.
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?
No annotations are provided, so the description carries the full burden. It mentions 'filtering options' and 'supports filtering by custom/system columns and managed/unmanaged status,' which adds some behavioral context. However, it does not disclose critical details like whether this is a read-only operation, potential rate limits, authentication requirements, or the format of the returned list, leaving gaps for a tool with no 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 front-loaded with the core purpose and efficiently uses three sentences to cover usage scenarios and filtering support. Every sentence adds value without redundancy, making it appropriately sized and well-structured.
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 no annotations and no output schema, the description provides adequate purpose and usage context but lacks details on behavioral traits (e.g., read-only nature, response format) and does not fully compensate for the missing structured data. It is complete enough for basic understanding but has clear gaps for a tool with 4 parameters and no 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?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds minimal value by mentioning 'filtering options' and referencing 'custom/system columns and managed/unmanaged status,' which loosely maps to parameters like 'customOnly' and 'includeManaged,' but does not provide additional syntax or format details beyond what the schema 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 the verb ('retrieves') and resource ('list of columns in a specific Dataverse table'), distinguishing it from siblings like 'get_dataverse_column' (singular) and 'list_dataverse_tables' (different resource). It specifies the purpose is to 'discover available fields, find custom columns, or get an overview of the table structure,' making it highly specific.
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 discover available fields, find custom columns, or get an overview of the table structure'), but does not explicitly mention when not to use it or name specific alternatives among the siblings (e.g., 'get_dataverse_column' for a single column). The guidance is helpful but lacks explicit 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?
With no annotations provided, the description carries the full burden. It mentions 'filtering options' and 'supports filtering by custom/system and managed/unmanaged status,' which adds some behavioral context beyond basic retrieval. However, it lacks details on permissions, rate limits, pagination behavior (implied by 'top' parameter but not explained), or what the output format looks like, leaving gaps for a tool with multiple parameters.
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 in the first sentence, followed by usage scenarios and filtering support. Every sentence adds value without redundancy, making it efficiently structured and appropriately sized for the tool's complexity.
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 no annotations and no output schema, the description provides adequate purpose and usage context but lacks details on behavioral aspects like output format, error handling, or authentication needs. For a list tool with filtering parameters, it's minimally complete but could benefit from more transparency about what the returned data looks like or any limitations.
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 100%, so the schema fully documents all four parameters. The description adds marginal value by mentioning filtering by 'custom/system and managed/unmanaged status,' which loosely maps to 'customOnly' and 'includeManaged' parameters but doesn't provide additional syntax or usage details beyond what's in the schema. This meets 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 clearly states the verb ('retrieves') and resource ('list of option sets in the Dataverse environment'), specifying the exact operation. It distinguishes from siblings like 'get_dataverse_optionset' (singular retrieval) and 'create_dataverse_optionset' (creation) by focusing on listing with filtering capabilities.
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 discover available choice lists, find custom option sets, or get an overview of reusable options'), giving practical scenarios. However, it doesn't explicitly state when not to use it or name specific alternatives among siblings, though the context implies it's for listing rather than detailed retrieval or management.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions filtering capabilities and the tool's purpose, but doesn't disclose important behavioral traits like whether this is a read-only operation, potential rate limits, authentication requirements, pagination behavior (beyond the 'top' parameter), or what the response format looks like.
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 perfectly concise with two sentences that each earn their place - the first states the core purpose, the second provides usage context and filtering capabilities. No wasted words, well-structured and front-loaded.
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?
For a read operation with 5 parameters and no output schema, the description is adequate but has gaps. It covers the purpose and filtering context well, but without annotations or output schema, it should ideally mention that this is a read-only operation and provide some indication of the response structure to be more 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?
Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description adds marginal value by mentioning filtering options generally ('filtering by business unit, custom/system roles, and managed/unmanaged status'), but doesn't provide additional semantic context beyond what's in the parameter 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 clearly states the tool's purpose with specific verb ('Retrieves') and resource ('list of security roles in the Dataverse environment'), and distinguishes it from siblings like 'get_dataverse_role' (singular) by emphasizing it lists multiple roles with filtering capabilities.
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 discover available roles, find custom roles, or get an overview of permission structures'), but doesn't explicitly state when NOT to use it or mention specific alternatives among the many sibling 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the destructive nature of the action ('revoking their access'), which is crucial for a mutation tool. However, it lacks details on permissions required, error conditions (e.g., if users are not in the team), or what happens to associated data, leaving some behavioral gaps.
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 in the first sentence, followed by usage guidance in the second. Both sentences are essential, with no redundant information, making it efficiently structured and appropriately sized for the tool's complexity.
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's complexity as a destructive mutation with no annotations and no output schema, the description is moderately complete. It covers the purpose and usage context well but lacks details on behavioral aspects like error handling, permissions, or return values, which would be beneficial for full contextual understanding.
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 100%, so the schema already documents both parameters ('memberIds' and 'teamId') adequately. The description does not add any additional semantic details about these parameters beyond what the schema provides, such as format examples or constraints, resulting in 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 specific action ('Removes users from team membership') and the resource ('team'), distinguishing it from siblings like 'remove_role_from_team' or 'delete_dataverse_team'. It explicitly mentions the effect of revoking access to team-owned records and permissions, which adds precision beyond the basic verb.
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 the tool ('when users no longer need team access or are changing roles'), but it does not explicitly mention when not to use it or name specific alternatives. For example, it doesn't contrast with 'remove_role_from_user' or other sibling tools that might affect user permissions differently.
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?
With no annotations provided, the description carries full burden. It correctly indicates this is a destructive operation ('removes', 'revoking') and provides usage context, but doesn't disclose important behavioral aspects like required permissions, whether the change is reversible, error conditions, or confirmation requirements for security-sensitive operations.
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 with zero waste - first states the action and effect, second provides usage guidance. Every word earns its place, and the most important information (what the tool does) comes first.
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?
For a security-sensitive mutation tool with no annotations and no output schema, the description provides adequate basic information about purpose and usage, but lacks important contextual details about permissions, reversibility, and expected outcomes that would be needed for safe 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 100%, so the schema already documents both parameters adequately. The description doesn't add any parameter-specific information beyond what's in the schema (both parameters are IDs), so it meets the baseline of 3 for high schema coverage without adding 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 the specific action ('Removes a security role assignment'), the resource ('from a specific user'), and the effect ('revoking the permissions granted by that role'). It distinguishes from siblings like 'remove_role_from_team' by specifying user-level operation.
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 ('when users change roles or no longer need certain access levels'), which helps the agent understand appropriate scenarios. However, it doesn't explicitly mention when NOT to use or name specific alternatives like 'remove_role_from_team' for team-level operations.
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?
With no annotations provided, the description carries the full burden. It discloses that the update only affects future values (a key behavioral trait) and implies mutation. However, it lacks details on permissions, error handling, or response format, leaving gaps for a mutation tool.
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 with zero waste: the first states the purpose and scope, and the second clarifies the impact on existing vs. future records. It is front-loaded and appropriately sized.
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?
For a mutation tool with no annotations and no output schema, the description is adequate but incomplete. It covers the core purpose and behavioral nuance (future-only effect), but lacks details on permissions, side effects, or error conditions that would be helpful for an agent.
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 100%, so the schema already documents all parameters thoroughly. The description does not add any parameter-specific information beyond what the schema provides, such as examples or constraints, meeting the baseline for high 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 ('Updates'), resource ('AutoNumberFormat of an existing AutoNumber column'), and scope ('changes how future values will be generated but does not affect existing records'). It distinguishes from sibling tools like 'create_autonumber_column' (creation vs. update) and 'set_autonumber_seed' (format vs. seed).
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 by specifying that it updates an existing column and only affects future values, implying it should be used for modifying format rather than creating new columns or altering existing records. However, it does not explicitly mention when not to use it or name specific alternatives among siblings.
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?
With no annotations provided, the description carries full burden. It discloses the important constraint that 'data type cannot be changed after creation' which is valuable behavioral context. However, it doesn't mention permission requirements, whether changes are reversible, error conditions, or what happens to existing data when settings change. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps.
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 perfectly concise with only two sentences. The first sentence states the purpose and scope, the second adds crucial behavioral constraint. Every word earns its place with zero redundancy or fluff.
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?
For a mutation tool with 9 parameters, no annotations, and no output schema, the description is adequate but incomplete. It covers the core purpose and one important constraint, but doesn't address permission requirements, error handling, or what the tool returns. Given the complexity and lack of structured metadata, it should provide more behavioral 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?
Schema description coverage is 100%, so the schema already documents all 9 parameters thoroughly. The description mentions 'display names, descriptions, required levels, or audit settings' which maps to some parameters, but doesn't add meaningful semantic context beyond what's in the schema. The baseline of 3 is appropriate when the 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 the specific action ('Updates the properties and configuration'), target resource ('an existing column in a Dataverse table'), and scope ('modify column settings like display names, descriptions, required levels, or audit settings'). It distinguishes from sibling tools like 'create_dataverse_column' by specifying it's for existing columns only.
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 modify column settings'), but doesn't explicitly state when not to use it or name specific alternatives. It mentions 'data type cannot be changed after creation' which implies this isn't for data type changes, but doesn't specify what tool to use instead for such cases.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by stating this is an update operation ('Updates an existing option set') and revealing an important behavioral consequence ('Changes affect all columns using this option set'). However, it doesn't mention permission requirements, whether changes are reversible, error conditions, or what the response looks like (especially important since there's no output schema).
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 perfectly structured with two sentences: the first states the core purpose, and the second provides usage guidance and important behavioral context. Every word earns its place, with no redundancy or unnecessary elaboration. It's front-loaded with the 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?
For a mutation tool with 6 parameters, 100% schema coverage, but no annotations and no output schema, the description does an adequate job. It clearly states the purpose, provides usage guidance, and reveals an important behavioral consequence. However, it doesn't address permission requirements, error handling, or response format, which would be valuable given the tool's complexity and mutation nature.
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 has 100% description coverage, so the baseline is 3. The description adds some value by mentioning that properties can be modified and options can be managed, which aligns with the parameter structure (displayName, description, addOptions, updateOptions, removeOptions). However, it doesn't provide additional semantic context beyond what's already in the schema 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 clearly states the verb ('Updates') and resource ('an existing option set'), specifies what properties are modified ('properties and managing its options'), and distinguishes this tool from its sibling 'create_dataverse_optionset' by focusing on updates rather than creation. It provides specific examples of actions like adding new choices, updating existing ones, removing obsolete options, and changing display name and description.
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 ('Use this to add new choices, update existing ones, remove obsolete options, or change the option set's display name and description'), which implicitly distinguishes it from creation and deletion tools. However, it doesn't explicitly mention when NOT to use it (e.g., for creating new option sets or deleting entire option sets) or name specific alternative tools for those scenarios.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about automatic publication ('Changes are published automatically'), which is not inferable from the schema alone. However, it lacks details on permissions, error handling, or mutation effects, leaving gaps for a tool with significant update capabilities.
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 efficiently structured in two sentences: the first states the purpose and scope, the second adds behavioral context. Every phrase earns its place with no redundant or vague language, making it easy to parse and understand quickly.
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?
For a mutation tool with 12 parameters and no annotations or output schema, the description is adequate but incomplete. It covers the core purpose and one behavioral trait (automatic publishing), but lacks details on permissions, side effects, or response format, which are important for safe and effective use.
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 100%, so the schema fully documents all 12 parameters. The description adds marginal value by grouping parameters into categories ('display names, descriptions, or feature enablement'), but does not provide additional syntax, constraints, or examples beyond what the schema already specifies.
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 ('Updates') and resource ('existing Dataverse table'), specifying what properties can be modified ('properties and configuration', 'table settings like display names, descriptions, or feature enablement'). It distinguishes from siblings like 'create_dataverse_table' by focusing on updates to existing tables rather than creation.
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 modify table settings'), but does not explicitly state when not to use it or name specific alternatives. It implies usage for existing tables but lacks explicit exclusions or comparisons with sibling tools like 'update_dataverse_column'.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively adds critical context: the action 'cannot be undone' (destructive behavior) and 'affects how records owned by this team are managed' (impact on related data). This goes beyond the basic 'convert' action, though it could benefit from details on permissions or error conditions.
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 action in the first sentence, followed by a critical warning. Both sentences earn their place by providing essential operational and risk information without redundancy or fluff, making it highly 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?
Given the tool's complexity (irreversible conversion affecting record management), no annotations, and no output schema, the description does a good job covering key behavioral aspects like destructiveness and impact. However, it lacks details on prerequisites (e.g., required permissions) or output expectations, leaving minor gaps for the agent.
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 100% description coverage, with the 'teamId' parameter clearly documented. The description does not add any additional meaning or syntax details beyond what the schema provides, such as format examples or validation rules. According to the rules, with high schema coverage, the baseline is 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 specific action ('converts'), the resource ('owner team'), and the outcome ('to access team'), with explicit mention of the functional change ('changing how the team can be used for record ownership and sharing'). It distinguishes itself from siblings like 'create_dataverse_team' or 'update_dataverse_team' by focusing on a specific type of team conversion rather than creation or general updates.
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 context through the WARNING about irreversibility and effects on record management, suggesting it should be used cautiously for teams involved in ownership. However, it does not explicitly state when to use this tool versus alternatives (e.g., when to convert vs. create a new team) or provide clear exclusions, leaving some ambiguity for the agent.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool exports a JSON schema and supports filtering, which implies a read-only operation without side effects, but does not detail potential limitations like file size, execution time, or error handling. It adds some context but lacks depth on behavioral traits.
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 in the first sentence, followed by usage examples and key features in a second sentence. Every sentence earns its place by adding value without redundancy, making it appropriately sized and 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?
Given the complexity of 10 parameters and no output schema, the description is fairly complete for a read operation, covering purpose and usage. However, it could improve by hinting at the output structure or potential issues, as the lack of output schema means the agent must infer return values. With no annotations, it does enough but has minor 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 description coverage is 100%, so the schema already documents all 10 parameters thoroughly. The description adds marginal value by mentioning filtering capabilities ('filtering by prefixes, system/custom components, and specific tables'), which aligns with parameters like 'customizationPrefixes' and 'systemTablesToInclude', but does not provide additional syntax or format details 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 verb ('Exports') and resource ('comprehensive JSON schema of Dataverse tables, columns, relationships, and option sets'), making the purpose specific. It distinguishes from siblings by focusing on schema export rather than creation, deletion, or management of individual components, which is evident when comparing to tools like 'create_dataverse_table' or 'get_dataverse_solution'.
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 the tool ('to document your data model, generate diagrams, or analyze solution structure'), which helps guide usage. However, it does not explicitly state when not to use it or name alternatives (e.g., vs. 'generate_mermaid_diagram' for diagrams), missing full differentiation.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates this is a read-only operation ('retrieves', 'check', 'verify') and specifies what information is returned ('solution context', 'customization prefix'). However, it doesn't mention potential limitations like rate limits, authentication requirements, or error conditions.
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 perfectly front-loaded with the core purpose in the first sentence and provides additional usage context in the second. Both sentences earn their place by adding distinct value, and there's no wasted language 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?
For a zero-parameter read operation with no annotations and no output schema, the description does a good job explaining what the tool does and when to use it. However, without an output schema, it could benefit from more detail about the return format or structure of the solution context 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 tool has 0 parameters with 100% schema description coverage, so the baseline would be 3. The description adds value by explaining the semantic purpose of the tool's output ('check which solution is currently set', 'verify the customization prefix'), which goes beyond what the empty 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's purpose with specific verbs ('retrieves', 'check', 'verify') and resources ('currently active solution context information', 'solution', 'customization prefix'). It distinguishes itself from siblings like 'set_solution_context' and 'clear_solution_context' by focusing on retrieval rather than modification.
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 check which solution is currently set for metadata operations and to verify the customization prefix'), but it doesn't explicitly state when not to use it or name specific alternatives. It implies usage for verification purposes without detailing 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?
With no annotations provided, the description carries full burden and does well by explicitly warning about the destructive nature ('removes all current privileges'), clarifying this is a complete replacement operation. However, it doesn't mention authentication requirements, rate limits, or what happens to existing privileges not in the new set.
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 zero waste: first states the core action, second provides critical warning about destructive behavior, third gives usage context. Every sentence earns its place and the warning is appropriately 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?
For a destructive mutation tool with no annotations and no output schema, the description does well by clearly explaining the replacement behavior and warning about data loss. However, it doesn't mention what the tool returns (success confirmation, error details) or potential side effects on users/teams with the role.
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 has 100% description coverage, so the baseline is 3. The description doesn't add any parameter-specific information beyond what's already in the schema descriptions for 'roleId' and 'privileges', though it reinforces that privileges are being 'replaced' rather than added.
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 ('completely replaces all existing privileges') and resource ('security role'), distinguishing it from siblings like 'add_privileges_to_role' and 'remove_privilege_from_role' which perform incremental modifications rather than full replacement.
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 ('for comprehensive role permission restructuring'), but doesn't explicitly state when not to use it or name specific alternatives like 'add_privileges_to_role' for incremental changes.
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?
With no annotations provided, the description carries the full burden. It discloses that this tool affects 'all subsequent metadata operations' and that components 'will be automatically added to this solution', which are important behavioral traits. However, it doesn't mention potential side effects, error conditions, or authentication requirements, leaving some gaps.
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 with two sentences that are front-loaded and zero waste. The first sentence explains the core functionality, and the second provides critical usage guidance, with every sentence earning 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?
Given the tool's complexity (setting a context for metadata operations) and the absence of annotations and output schema, the description is mostly complete. It explains the purpose, usage, and effect, but lacks details on error handling or what happens if the context is invalid, which could be helpful for an agent.
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 100%, so the schema already documents the single parameter 'solutionUniqueName' with a clear description. The description doesn't add any additional meaning or context about the parameter beyond what the schema provides, making the baseline score of 3 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 specific action ('Sets the active solution context') and resource ('for all subsequent metadata operations'), distinguishing it from sibling tools like 'clear_solution_context' and 'get_solution_context'. It explicitly explains the scope and effect of setting this context.
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: 'This is required before creating any custom components.' It also distinguishes it from alternatives by explaining its role in the workflow for metadata operations, though it doesn't name specific sibling alternatives beyond the clear 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?
With no annotations provided, the description carries the full burden of behavioral disclosure and excels at this. It explicitly states the irreversible nature ('cannot be undone'), warns about cascading effects ('may affect users and teams'), and emphasizes the dangerous nature of the operation - all critical behavioral information not captured in the input schema.
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 perfectly front-loaded with the core action first, followed by critical warnings. Every sentence earns its place: the first states the action, the second provides the key behavioral warnings, and the third gives usage guidance. 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?
For a destructive mutation tool with no annotations and no output schema, the description does an excellent job covering the critical behavioral aspects. It clearly communicates the irreversible nature and potential side effects. The only minor gap is not explicitly mentioning what happens on success/failure or return values, but given the warning-heavy nature, this 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?
The schema description coverage is 100% with the single parameter 'businessUnitId' well-documented in the schema. The description doesn't add any additional parameter semantics beyond what the schema already provides, 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 states the specific action ('permanently deletes') and target resource ('a business unit from Dataverse'), distinguishing it from sibling tools like 'get_dataverse_businessunit' or 'update_dataverse_businessunit'. It precisely communicates the destructive nature of 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides strong contextual guidance with 'Use with extreme caution' and mentions potential impacts on users and teams, which helps the agent understand when this tool is appropriate. However, it doesn't explicitly state when to use alternatives like 'update_dataverse_businessunit' or 'set_businessunit_parent' for non-destructive changes.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates critical behavioral traits: the action is permanent ('cannot be undone'), destructive ('will remove all data stored in this column'), and requires caution. This covers the safety profile that annotations would normally 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 appropriately sized with three sentences that each earn their place: the first states the action, the second provides critical warnings, and the third gives usage guidance. It's front-loaded with the core purpose and wastes no 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?
For a destructive tool with no annotations and no output schema, the description does an excellent job covering the essential behavioral context (irreversible, data loss). However, it doesn't mention potential prerequisites (e.g., permissions needed) or what happens upon success/failure, leaving minor gaps in 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 schema description coverage is 100%, so the schema already documents both parameters ('entityLogicalName' and 'logicalName') adequately. The description doesn't add any additional meaning about the parameters beyond what the schema provides, such as format examples or constraints, which aligns with the baseline score when 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 the specific action ('permanently deletes'), the resource ('a column from a Dataverse table'), and distinguishes it from siblings like 'delete_dataverse_table' or 'update_dataverse_column' by focusing on column deletion. It goes beyond just restating the name/title by specifying the scope and irreversible nature.
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 it ('only for columns that are no longer needed') and includes a strong warning about irreversible consequences. However, it doesn't explicitly mention when NOT to use it or name specific alternatives like 'update_dataverse_column' for modifications instead of deletion.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates critical traits: the action is permanent and irreversible ('cannot be undone'), has a failure condition ('will fail if the option set is being used'), and requires prerequisite checks ('Ensure no columns reference this option set'). However, it doesn't mention authentication needs, rate limits, or error handling specifics.
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 action and warning, followed by specific usage guidance. Every sentence earns its place by conveying essential information without redundancy. The structure is efficient and well-organized for a destructive operation.
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 destructive tool with no annotations and no output schema, the description does an excellent job covering the critical aspects: purpose, irreversible nature, failure conditions, and prerequisites. It could be slightly more complete by mentioning authentication or response format, but given the context, it provides sufficient guidance for safe usage.
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 100%, with the parameter 'name' documented as 'Name of the option set to delete'. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. The baseline score of 3 is appropriate since the schema already fully describes 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 action ('permanently deletes') and resource ('an option set from Dataverse'), making the purpose specific and unambiguous. It distinguishes from siblings like 'delete_dataverse_column' or 'delete_dataverse_table' by specifying the resource type as 'option set'.
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 ('Ensure no columns reference this option set before deletion') and when it will fail ('if the option set is being used by any columns'). It also implicitly contrasts with alternatives like 'update_dataverse_optionset' by emphasizing the irreversible nature of deletion.
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?
Since no annotations are provided, the description carries the full burden. It effectively discloses critical behavioral traits: the action is permanent ('cannot be undone'), destructive ('will remove the connection between tables'), and has side effects ('including any lookup fields for One-to-Many relationships'). This covers safety and impact beyond basic functionality.
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 with three sentences that are front-loaded with the core action and warning. Every sentence earns its place by conveying purpose, consequences, and caution without unnecessary details.
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 (destructive deletion), lack of annotations, and no output schema, the description does well by covering key behavioral aspects like permanence and side effects. However, it could be more complete by mentioning prerequisites (e.g., permissions needed) or what happens after deletion (e.g., error handling), though the warning suffices for most contexts.
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 100% description coverage, with the parameter 'schemaName' clearly documented. The description does not add any additional meaning or context about the parameter beyond what the schema provides, so it meets the baseline of 3 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 clearly states the specific action ('permanently deletes'), the resource ('a relationship between Dataverse tables'), and distinguishes it from sibling tools like 'create_dataverse_relationship' and 'get_dataverse_relationship'. It goes beyond just restating the name/title by specifying the scope of deletion.
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 with 'Use with extreme caution' and the warning about irreversibility, which helps guide when to use it. However, it does not explicitly mention when NOT to use it or name specific alternatives (e.g., 'update_dataverse_relationship' might be an alternative for modifying rather than deleting).
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?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: the action is permanent ('cannot be undone'), has a prerequisite (role must not be assigned), and includes a failure condition. This covers critical aspects like destructiveness and constraints that annotations would otherwise indicate.
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 action and warning, followed by a prerequisite. Every sentence adds value—none are redundant or verbose—making it efficiently structured and appropriately sized for the tool's complexity.
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 destructive tool with no annotations and no output schema, the description is largely complete, covering purpose, behavior, and usage constraints. However, it lacks details on error responses or post-deletion effects, which could enhance completeness given the high-stakes nature of deletion operations.
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 description coverage is 100%, with the parameter 'roleId' fully documented in the schema. The description does not add any additional meaning or context about the parameter beyond what the schema provides, such as format examples or sourcing details, so it meets 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 clearly states the specific action ('permanently deletes') and resource ('a security role from Dataverse'), distinguishing it from sibling tools like 'delete_dataverse_businessunit' or 'delete_dataverse_team' that target different resources. It precisely communicates the tool's function without ambiguity.
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 on when to use it (e.g., 'Ensure the role is not in use before deletion') and mentions a failure condition ('will fail if the role is assigned to any users or teams'), but it does not explicitly name alternative tools or specify when not to use it relative to siblings like 'remove_role_from_user' or 'update_dataverse_role'.
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?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It effectively describes critical behavioral traits: the action is permanent ('cannot be undone'), destructive ('will remove all data in the table'), and includes a cautionary note. This compensates well for the lack of annotations like destructiveHint.
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 and front-loaded, with the first sentence stating the core action and the following sentences providing essential warnings and usage context. Every sentence earns its place by adding critical information without 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 high complexity (destructive deletion) and lack of annotations or output schema, the description does a good job of covering key aspects like permanence and data loss. However, it could be more complete by mentioning prerequisites (e.g., permissions needed) or what happens post-deletion (e.g., confirmation message), slightly reducing the score.
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 description coverage is 100%, with the parameter 'logicalName' clearly documented in the schema. The description does not add any additional meaning or context about the parameter beyond what the schema provides, such as examples or constraints. Thus, it meets 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 clearly states the specific action ('permanently deletes'), the resource ('a custom table from Dataverse'), and distinguishes it from siblings like 'update_dataverse_table' or 'get_dataverse_table' by emphasizing irreversible removal. It goes beyond just restating the name/title by specifying the scope of deletion.
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 on when to use this tool ('only for tables that are no longer needed') and includes a strong warning about caution. However, it does not explicitly mention alternatives (e.g., archiving or deactivating tables if available) or compare it to sibling tools like 'delete_dataverse_column', leaving some room for improvement.
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?
With no annotations provided, the description carries the full burden and excels by disclosing critical behavioral traits: it is destructive ('permanently deletes', 'cannot be undone'), has specific failure conditions ('will fail if the team owns records or has assigned security roles'), and requires pre-checks ('ensure the team is not in use'). This goes beyond the basic input schema to inform the agent about risks and constraints.
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 and front-loaded: the first sentence states the core purpose, followed by warnings and prerequisites. Every sentence earns its place by adding critical information without redundancy, making it efficient and easy to parse.
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 (destructive deletion with conditions), no annotations, and no output schema, the description is largely complete: it covers purpose, behavioral risks, and usage context. However, it does not specify what happens on success (e.g., confirmation message) or error details beyond failure conditions, leaving some gaps in full contextual understanding.
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 100% description coverage (the 'teamId' parameter is well-documented in the schema), so the baseline is 3. The description does not add any additional parameter-specific information beyond what the schema provides, such as format examples or validation rules, but it doesn't need to since the schema is comprehensive.
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 ('permanently deletes') and resource ('a team from Dataverse'), distinguishing it from sibling tools like 'delete_dataverse_businessunit' or 'delete_dataverse_table' which target different resources. It avoids tautology by not just restating the name/title.
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 by warning about prerequisites ('will fail if the team owns records or has assigned security roles') and advising to 'ensure the team is not in use before deletion.' However, it does not explicitly mention when not to use it or name specific alternatives among siblings (e.g., 'update_dataverse_team' for modifications instead of deletion).
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?
With no annotations provided, the description carries full burden and effectively discloses key behavioral traits: it describes the effect ('metadata operations will not be associated with any specific solution') and the state change after clearing. It doesn't mention error conditions or permissions, but provides sufficient context for a zero-parameter tool.
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 with zero waste: the first states the action and immediate effect, the second provides usage guidance. Every word earns its place and the information is front-loaded appropriately.
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 zero-parameter tool with no annotations and no output schema, the description provides complete context about what the tool does, when to use it, and the resulting state. It could mention if there's any confirmation or error handling, but is largely sufficient.
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 tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, focusing instead on the tool's effect and 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 specific action ('Clears') and resource ('currently active solution context'), distinguishing it from siblings like 'set_solution_context' and 'get_solution_context'. It precisely defines what the tool does without being tautological.
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 the tool: 'when you want to work without a solution context or before switching to a different solution'. This provides clear context for usage versus alternatives like 'set_solution_context'.
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/mwhesse/dataverse-mcp/badges/card.svg)](https://glama.ai/mcp/servers/mwhesse/dataverse-mcp)

Score Badge

Copy to your README.md:

[![dataverse-mcp MCP server](https://glama.ai/mcp/servers/mwhesse/dataverse-mcp/badges/score.svg)](https://glama.ai/mcp/servers/mwhesse/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/mwhesse/dataverse-mcp'

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