Skip to main content
Glama
mwhesse

Dataverse MCP Server

by mwhesse
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

Dataverse MCP Server

A Model Context Protocol (MCP) server for Microsoft Dataverse that enables schema operations including creating and updating tables, columns, relationships, and option sets using the Dataverse Web API.

🚀 Key Features

✅ Manage Tables & Columns - Create, update, delete, and list custom tables with all column types (String, Integer, Boolean, DateTime, Picklist, Lookup, AutoNumber, etc.)

✅ Manage Relationships - Create One-to-Many and Many-to-Many relationships between entities with proper cascade behaviors

✅ Manage Option Sets - Create and manage global option sets with custom options, colors, and values

✅ Solution-Based Architecture - Enterprise-grade solution management with persistent context and automatic customization prefixes

✅ Security & Access Control - Complete security role management, team operations, and business unit hierarchy management

✅ WebAPI Call Generator - Generate ready-to-use HTTP requests, cURL commands, and JavaScript code for any Dataverse operation

✅ PowerPages WebAPI Generator - Generate PowerPages-specific WebAPI calls using the /_api/[logicalEntityName] format with React examples

✅ PowerPages Configuration Management - Manage table permissions and WebAPI site settings for PowerPages Code Sites with YAML file automation

✅ Schema Export & Visualization - Export complete solution schemas to JSON with advanced filtering, then generate professional Mermaid ERD diagrams with relationship visualization

✅ Mermaid Diagram Generation - Convert exported schemas into professional Entity Relationship Diagrams with enhanced column markers, lookup target display, and unlimited table support

✅ AutoNumber Column Management - Create and manage AutoNumber columns with customizable format patterns for automatic serial numbers, reference codes, and unique identifiers

✅ Professional Integration - OAuth2 authentication, comprehensive error handling, and enterprise-ready deployment

✅ Production Ready - Comprehensive testing completed with 7 critical bugs found and fixed, 100% tool coverage achieved

Related MCP server: Dataverse MCP Server

Table of Contents

Features

This MCP server provides comprehensive tools for Dataverse schema management:

Table Operations

  • create_dataverse_table ✅ Fully Tested - Create Dataverse Table: Creates a new custom table in Dataverse with the specified configuration. Use this when you need to create a new entity to store business data. Requires a solution context to be set first.

  • get_dataverse_table ✅ Fully Tested - Get Dataverse Table: Retrieves detailed information about a specific Dataverse table including its metadata, properties, and configuration. Use this to inspect table definitions and understand table structure.

  • update_dataverse_table ✅ Fully Tested - Update Dataverse Table: Updates the properties and configuration of an existing Dataverse table. Use this to modify table settings like display names, descriptions, or feature enablement (activities, notes, auditing, etc.). Changes are published automatically.

  • delete_dataverse_table ✅ Fully Tested - Delete Dataverse Table: Permanently deletes a custom table from Dataverse. WARNING: This action cannot be undone and will remove all data in the table. Use with extreme caution and only for tables that are no longer needed.

  • list_dataverse_tables ✅ Fully Tested - List Dataverse Tables: Retrieves a list of tables in the Dataverse environment with filtering options. Use this to discover available tables, find custom tables, or get an overview of the data model. Supports filtering by custom/system tables and managed/unmanaged status.

Column Operations

  • create_dataverse_column ✅ Fully Tested - Create Dataverse Column: Creates a new column (field) in a Dataverse table with the specified data type and configuration. Supports various column types including text, numbers, dates, lookups, and choice lists. Use this to add new fields to store specific data in your tables. Requires a solution context to be set first.

  • get_dataverse_column ✅ Fully Tested - Get Dataverse Column: Retrieves detailed information about a specific column in a Dataverse table, including its data type, properties, and configuration settings. Use this to inspect column definitions and understand field structure.

  • update_dataverse_column ✅ Fully Tested - Update Dataverse Column: Updates the properties and configuration of an existing column in a Dataverse table. Use this to modify column settings like display names, descriptions, required levels, or audit settings. Note that data type cannot be changed after creation.

  • delete_dataverse_column ✅ Fully Tested - Delete Dataverse Column: Permanently deletes a column from a Dataverse table. WARNING: This action cannot be undone and will remove all data stored in this column. Use with extreme caution and only for columns that are no longer needed.

  • list_dataverse_columns ✅ Fully Tested - List Dataverse Columns: Retrieves a list of columns in a specific Dataverse table with filtering options. Use this to discover available fields in a table, find custom columns, or get an overview of the table structure. Supports filtering by custom/system columns and managed/unmanaged status.

AutoNumber Column Operations

  • create_autonumber_column ✅ Fully Tested - Create AutoNumber Column: Creates a new AutoNumber column in a Dataverse table with specified format. AutoNumber columns automatically generate alphanumeric strings using sequential numbers, random strings, and datetime placeholders. Requires a solution context to be set first.

  • update_autonumber_format ✅ Fully Tested - Update AutoNumber Format: Updates the AutoNumberFormat of an existing AutoNumber column. This changes how future values will be generated but does not affect existing records.

  • set_autonumber_seed ✅ Fully Tested - Set AutoNumber Seed: Sets the seed value for an AutoNumber column's sequential segment using the SetAutoNumberSeed action. This controls the starting number for future records. Note: Seed values are environment-specific and not included in solutions.

  • get_autonumber_column ✅ Fully Tested - Get AutoNumber Column: Retrieves detailed information about an AutoNumber column including its current format, properties, and configuration.

  • list_autonumber_columns ✅ Fully Tested - List AutoNumber Columns: Lists all AutoNumber columns in a specific table or across all tables in the environment. Helps identify existing AutoNumber implementations.

  • convert_to_autonumber ✅ Fully Tested - Convert to AutoNumber: Converts an existing text column to an AutoNumber column by adding an AutoNumberFormat. The column must be a String type with Text format and should be empty or contain compatible data.

Relationship Operations

  • create_dataverse_relationship ✅ Fully Tested - Create Dataverse Relationship: Creates a relationship between two Dataverse tables. Supports One-to-Many relationships (parent-child with lookup field) and Many-to-Many relationships (junction table). Use this to establish data connections between tables, enable navigation, and maintain referential integrity.

  • get_dataverse_relationship ✅ Fully Tested - Get Dataverse Relationship: Retrieves detailed information about a specific relationship between Dataverse tables, including its configuration, cascade settings, and menu behavior. Use this to inspect relationship definitions and understand table connections.

  • delete_dataverse_relationship ✅ Fully Tested - Delete Dataverse Relationship: Permanently deletes a relationship between Dataverse tables. WARNING: This action cannot be undone and will remove the connection between tables, including any lookup fields for One-to-Many relationships. Use with extreme caution.

  • list_dataverse_relationships ✅ Fully Tested - List Dataverse Relationships: Retrieves a list of relationships in the Dataverse environment with filtering options. Use this to discover table connections, find custom relationships, or get an overview of the data model relationships. Supports filtering by entity, relationship type, and managed/unmanaged status.

Option Set Operations

  • create_dataverse_optionset ✅ Fully Tested - Create Dataverse Option Set: Creates a new global option set (choice list) in Dataverse with predefined options. Use this to create reusable choice lists that can be used across multiple tables and columns. Option sets provide consistent data entry options and improve data quality.

  • get_dataverse_optionset ✅ Fully Tested - Get Dataverse Option Set: Retrieves detailed information about a specific option set including its metadata, options, and configuration. Use this to inspect option set definitions and understand available choices.

  • update_dataverse_optionset ✅ Fully Tested - Update Dataverse Option Set: Updates an existing option set by modifying its properties and managing its options. Use this to add new choices, update existing ones, remove obsolete options, or change the option set's display name and description. Changes affect all columns using this option set.

  • delete_dataverse_optionset ✅ Fully Tested - Delete Dataverse Option Set: Permanently deletes an option set from Dataverse. WARNING: This action cannot be undone and will fail if the option set is being used by any columns. Ensure no columns reference this option set before deletion.

  • list_dataverse_optionsets ✅ Fully Tested - List Dataverse Option Sets: Retrieves a list of option sets in the Dataverse environment with filtering options. Use this to discover available choice lists, find custom option sets, or get an overview of reusable options. Supports filtering by custom/system and managed/unmanaged status.

  • get_dataverse_optionset_options ✅ Fully Tested - Get Dataverse Option Set Options: Retrieves all options (choices) within a specific option set, including their values, labels, descriptions, and colors. Use this to inspect the available choices in an option set and understand their configuration.

Solution & Publisher Operations

  • create_dataverse_publisher ✅ Fully Tested - Create Dataverse Publisher: Creates a new publisher in Dataverse. Publishers are required for creating solutions and provide customization prefixes for schema names. Use this to establish a publisher identity before creating solutions and custom components.

  • get_dataverse_publisher ✅ Fully Tested - Get Dataverse Publisher: Retrieves detailed information about a specific publisher including its customization prefix, option value prefix, and configuration. Use this to inspect publisher properties and understand customization settings.

  • list_dataverse_publishers ✅ Fully Tested - List Dataverse Publishers: Retrieves a list of publishers in the Dataverse environment with filtering options. Use this to discover available publishers, find custom publishers for solution creation, or get an overview of publisher configurations including customization prefixes.

  • create_dataverse_solution ✅ Fully Tested - Create Dataverse Solution: Creates a new unmanaged solution in Dataverse. Solutions are containers for customizations and allow you to package, deploy, and manage custom components. Use this to create a solution before adding tables, columns, and other customizations.

  • get_dataverse_solution ✅ Fully Tested - Get Dataverse Solution: Retrieves detailed information about a specific solution including its metadata, version, publisher details, and configuration. Use this to inspect solution properties and understand solution structure.

  • list_dataverse_solutions ✅ Fully Tested - List Dataverse Solutions: Retrieves a list of solutions in the Dataverse environment with filtering options. Use this to discover available solutions, find unmanaged solutions for customization, or get an overview of solution packages. Includes publisher information for each solution.

  • set_solution_context ✅ Fully Tested - Set Solution Context: Sets the active solution context for all subsequent metadata operations. When a solution context is set, all created tables, columns, relationships, and other components will be automatically added to this solution. This is required before creating any custom components.

  • get_solution_context ✅ Fully Tested - Get Solution Context: Retrieves the currently active solution context information. Use this to check which solution is currently set for metadata operations and to verify the customization prefix being used for new components.

  • clear_solution_context ✅ Fully Tested - Clear Solution Context: Clears the currently active solution context. After clearing, metadata operations will not be associated with any specific solution. Use this when you want to work without a solution context or before switching to a different solution.

Security Role Operations

  • create_dataverse_role ✅ Fully Tested - Create Dataverse Security Role: Creates a new security role in Dataverse to define permissions and access levels for users and teams. Security roles control what users can see and do within the system. Use this to establish custom permission sets for different user types or job functions.

  • get_dataverse_role ✅ Fully Tested - Get Dataverse Security Role: Retrieves detailed information about a specific security role including its properties, business unit association, and configuration settings. Use this to inspect role definitions and understand permission structures.

  • update_dataverse_role ✅ Fully Tested - Update Dataverse Security Role: Updates the properties and configuration of an existing security role. Use this to modify role settings like name, description, auto-assignment behavior, or inheritance settings without changing the actual privileges.

  • delete_dataverse_role ✅ Fully Tested - Delete Dataverse Security Role: Permanently deletes a security role from Dataverse. WARNING: This action cannot be undone and will fail if the role is assigned to any users or teams. Ensure the role is not in use before deletion.

  • list_dataverse_roles ✅ Fully Tested - List Dataverse Security Roles: Retrieves a list of security roles in the Dataverse environment with filtering options. Use this to discover available roles, find custom roles, or get an overview of permission structures. Supports filtering by business unit, custom/system roles, and managed/unmanaged status.

  • add_privileges_to_role ✅ Fully Tested - Add Privileges to Security Role: Adds specific privileges with defined access levels to a security role. Use this to grant permissions for specific operations (create, read, write, delete, etc.) on entities or system functions. Each privilege can have different access levels (Basic, Local, Deep, Global).

  • remove_privilege_from_role ✅ Fully Tested - Remove Privilege from Security Role: Removes a specific privilege from a security role, revoking the associated permissions. Use this to restrict access by removing specific operation permissions from a role.

  • replace_role_privileges ✅ Fully Tested - Replace Security Role Privileges: Completely replaces all existing privileges in a security role with a new set of privileges. WARNING: This removes all current privileges and replaces them with the specified ones. Use this for comprehensive role permission restructuring.

  • get_role_privileges ✅ Fully Tested - Get Security Role Privileges: Retrieves all privileges currently assigned to a security role, showing what permissions the role grants. Use this to audit role permissions and understand what access a role provides to users and teams.

  • assign_role_to_user ✅ Fully Tested - Assign Security Role to User: Assigns a security role to a specific user, granting them all the permissions defined in that role. Use this to provide users with the appropriate access levels for their job functions and responsibilities.

  • remove_role_from_user ✅ Fully Tested - Remove Security Role from User: Removes a security role assignment from a specific user, revoking the permissions granted by that role. Use this when users change roles or no longer need certain access levels.

  • assign_role_to_team ✅ Fully Tested - Assign Security Role to Team: Assigns a security role to a team, granting all team members the permissions defined in that role. Use this to provide consistent access levels to groups of users working together on similar tasks.

  • remove_role_from_team ✅ Fully Tested - Remove Security Role from Team: Removes a security role assignment from a team, revoking the permissions granted by that role for all team members. Use this when teams no longer need certain access levels or when restructuring team permissions.

Team Operations

  • create_dataverse_team ✅ Fully Tested - Create Dataverse Team: Creates a new team in Dataverse for organizing users and managing permissions. Teams can be owner teams (for record ownership) or access teams (for sharing records). Use this to establish groups of users who work together and need similar access levels.

  • get_dataverse_team ✅ Fully Tested - Get Dataverse Team: Retrieves detailed information about a specific team including its properties, administrator, business unit association, and configuration settings. Use this to inspect team definitions and understand team structure.

  • update_dataverse_team ✅ Fully Tested - Update Dataverse Team: Updates the properties and configuration of an existing team. Use this to modify team settings like name, description, administrator, or other team properties without changing team membership.

  • delete_dataverse_team ✅ Fully Tested - Delete Dataverse Team: Permanently deletes a team from Dataverse. WARNING: This action cannot be undone and will fail if the team owns records or has assigned security roles. Ensure the team is not in use before deletion.

  • list_dataverse_teams ✅ Fully Tested - List Dataverse Teams: Retrieves a list of teams in the Dataverse environment with filtering options. Use this to discover available teams, find teams by business unit or type, or get an overview of team organization. Supports filtering by business unit, team type, and system-managed status.

  • add_members_to_team ✅ Fully Tested - Add Members to Team: Adds users as members to a team, granting them access to team-owned records and team-based permissions. Use this to expand team membership and provide users with team-level access to resources.

  • remove_members_from_team ✅ Fully Tested - Remove Members from Team: Removes users from team membership, revoking their access to team-owned records and team-based permissions. Use this when users no longer need team access or are changing roles.

  • get_team_members ✅ Fully Tested - Get Team Members: Retrieves a list of all users who are members of a specific team, including their basic information and status. Use this to audit team membership and understand who has team-based access.

  • convert_owner_team_to_access_team ✅ Fully Tested - Convert Owner Team to Access Team: Converts an owner team to an access team, changing how the team can be used for record ownership and sharing. WARNING: This action cannot be undone and affects how records owned by this team are managed.

Business Unit Operations

  • create_dataverse_businessunit ✅ Fully Tested - Create Dataverse Business Unit: Creates a new business unit in Dataverse with comprehensive configuration options including contact information, addresses, and organizational hierarchy. Business units are used to organize users and control data access in Dataverse.

  • get_dataverse_businessunit ✅ Fully Tested - Get Dataverse Business Unit: Retrieves detailed information about a specific business unit including all properties, addresses, and related information. Use this to inspect business unit configuration and hierarchy relationships.

  • update_dataverse_businessunit ✅ Fully Tested - Update Dataverse Business Unit: Updates the properties and configuration of an existing business unit. Use this to modify business unit information, contact details, addresses, and organizational settings. Only provided fields will be updated.

  • delete_dataverse_businessunit ✅ Fully Tested - Delete Dataverse Business Unit: Permanently deletes a business unit from Dataverse. WARNING: This action cannot be undone and may affect users and teams associated with the business unit. Use with extreme caution.

  • list_dataverse_businessunits ✅ Fully Tested - List Dataverse Business Units: Retrieves a list of business units in the Dataverse environment with filtering and sorting options. Use this to discover available business units, understand organizational hierarchy, and find specific business units by criteria.

  • get_businessunit_hierarchy ✅ Fully Tested - Get Business Unit Hierarchy: Retrieves the complete organizational hierarchy for a specific business unit, showing parent-child relationships and the full organizational structure. Use this to understand business unit relationships and organizational structure.

  • set_businessunit_parent ✅ Fully Tested - Set Business Unit Parent: Changes the parent business unit for a given business unit, effectively moving it within the organizational hierarchy. Use this to reorganize business unit structure and reporting relationships.

  • get_businessunit_users ✅ Fully Tested - Get Business Unit Users: Retrieves all users associated with a specific business unit, with option to include users from subsidiary business units. Use this to understand user assignments and organizational membership.

  • get_businessunit_teams ✅ Fully Tested - Get Business Unit Teams: Retrieves all teams associated with a specific business unit, with option to include teams from subsidiary business units. Use this to understand team organization and business unit relationships.

Schema Export Operations

  • export_solution_schema ✅ Fully Tested - Export Solution Schema: Exports a comprehensive JSON schema of Dataverse tables, columns, relationships, and option sets. Use this to document your data model, generate diagrams, or analyze solution structure. Supports filtering by prefixes, system/custom components, and specific tables.

  • generate_mermaid_diagram ✅ Fully Tested - Generate Mermaid Diagram: Generates a Mermaid entity relationship diagram from an exported schema JSON file. Creates visual documentation of your data model with tables, columns, and relationships. Perfect for documentation, presentations, and understanding data structure.

WebAPI Call Generator

  • generate_webapi_call ✅ Fully Tested - Generate Dataverse WebAPI Call: Generate HTTP requests, curl commands, and JavaScript examples for Dataverse WebAPI operations. Supports all CRUD operations, associations, actions, and functions with proper OData query parameters and headers.

PowerPages WebAPI Generator

  • generate_powerpages_webapi_call ✅ Fully Tested - Generate PowerPages WebAPI Call: Generate PowerPages-specific API calls, JavaScript examples, and React components for Dataverse operations through PowerPages portals. Features schema-aware metadata retrieval, @odata.bind relationship management, automatic field inference, and PowerPages-specific authentication patterns.

PowerPages Configuration Management

  • manage_powerpages_webapi_config ✅ Fully Tested - Manage PowerPages WebAPI Configuration: Manage PowerPages WebAPI configurations and table permissions. Add/remove WebAPI access for tables, configure table permissions, and check configuration status for PowerPages portals.

Solution-Based Architecture

The MCP server implements enterprise-grade solution management following Microsoft Dataverse best practices.

Key Benefits

  • Professional Schema Naming: Uses publisher-based customization prefixes

  • Solution Association: All schema changes are automatically associated with the active solution

  • ALM Support: Enables proper solution packaging and deployment across environments

  • Persistent Context: Solution context survives server restarts via .dataverse-mcp file

  • Enterprise Governance: Supports multiple publishers and solutions with proper isolation

Solution Workflow

  1. Create Publisher: Define your organization's customization prefix

  2. Create Solution: Link solution to publisher for schema organization

  3. Set Context: Activate solution for subsequent operations

  4. Create Schema: All tables, columns, and option sets use the publisher's prefix automatically

  5. Deploy: Export solution for deployment to other environments

Example: XYZ Organization Setup

// 1. Create publisher with "xyz" prefix
await use_mcp_tool("dataverse", "create_dataverse_publisher", {
  friendlyName: "XYZ Test Publisher",
  uniqueName: "xyzpublisher",
  customizationPrefix: "xyz",
  customizationOptionValuePrefix: 20000,
  description: "Publisher for XYZ organization"
});

// 2. Create solution linked to publisher
await use_mcp_tool("dataverse", "create_dataverse_solution", {
  friendlyName: "XYZ Test Solution",
  uniqueName: "xyzsolution",
  publisherUniqueName: "xyzpublisher",
  description: "Main solution for XYZ customizations"
});

// 3. Set solution context (persisted across server restarts)
await use_mcp_tool("dataverse", "set_solution_context", {
  solutionUniqueName: "xyzsolution"
});

// 4. Create schema objects - they automatically use "xyz" prefix
await use_mcp_tool("dataverse", "create_dataverse_table", {
  logicalName: "xyz_project",        // Uses xyz prefix automatically
  displayName: "XYZ Project",
  displayCollectionName: "XYZ Projects"
});

await use_mcp_tool("dataverse", "create_dataverse_column", {
  entityLogicalName: "xyz_project",
  logicalName: "xyz_description",    // Uses xyz prefix automatically
  displayName: "Description",
  columnType: "Memo"
});

Persistent Solution Context

The server automatically persists solution context to a .dataverse-mcp file in the project root:

{
  "solutionUniqueName": "xyzsolution",
  "solutionDisplayName": "XYZ Test Solution",
  "publisherUniqueName": "xyzpublisher",
  "publisherDisplayName": "XYZ Test Publisher",
  "customizationPrefix": "xyz",
  "lastUpdated": "2025-07-26T08:27:56.966Z"
}

Benefits of Persistence:

  • No Context Loss: Solution context survives server restarts

  • Instant Productivity: Developers can immediately continue work

  • Consistent Prefixes: No need to remember and re-set solution context

  • Team Isolation: Each developer can have their own solution context (file is git-ignored)

Supported Column Types

The MCP server supports all major Dataverse column types with comprehensive configuration options. The following table shows implementation status and comprehensive testing verification:

Column Type

Status

Tested

Description

Key Parameters

String

✅ Implemented

✅ Fully Verified

Text fields with format options

maxLength, format (Email, Text, TextArea, Url, Phone)

Integer

✅ Implemented

✅ Fully Verified

Whole numbers with constraints

minValue, maxValue (defaultValue not supported)

Decimal

✅ Implemented

✅ Fully Verified

Decimal numbers with precision

precision, minValue, maxValue, defaultValue

Money

✅ Implemented

✅ Fully Verified

Currency values

precision, minValue, maxValue

Boolean

✅ Implemented

✅ Fully Verified

True/false with custom labels

trueOptionLabel, falseOptionLabel, defaultValue

DateTime

✅ Implemented

✅ Fully Verified

Date and time fields

dateTimeFormat (DateOnly, DateAndTime)

Picklist

✅ Implemented

✅ Fully Verified

Choice fields (local & global)

options (for local), optionSetName (for global)

Lookup

✅ Implemented

✅ Fully Verified

References to other tables

targetEntity

Memo

✅ Implemented

✅ Fully Verified

Long text fields

maxLength

Double

✅ Implemented

✅ Fully Verified

Floating-point numbers

precision, minValue, maxValue

BigInt

✅ Implemented

✅ Fully Verified

Large integer values

None

Column Type Details

String Columns ✅ Fully Tested

  • Formats: Email, Text, TextArea, Url, Phone

  • Max Length: Configurable (default: 100)

  • Default Values: Supported

  • Example: Employee name, email address, phone number

Integer Columns ✅ Fully Tested

  • Constraints: Min/max value validation

  • Default Values: Not supported (Dataverse limitation)

  • Example: Age, quantity, score with range 0-100

Boolean Columns ✅ Fully Tested

  • Custom Labels: Configurable true/false option labels

  • Default Values: Supported

  • Example: "Active/Inactive", "Yes/No", "Enabled/Disabled"

DateTime Columns ✅ Fully Tested

  • DateOnly: Date without time component (e.g., hire date, birthday)

  • DateAndTime: Full timestamp with timezone handling (e.g., last login, created date)

  • Behavior: Uses UserLocal timezone behavior

Picklist Columns ✅ Fully Tested

  • Local Option Sets: Create inline options with the column

  • Global Option Sets: Reference existing global option sets by name

  • Color Support: Options can have associated colors

  • Example: Status (Active, Inactive), Priority (High, Medium, Low)

Lookup Columns ✅ Fully Tested

  • Target Entity: Specify which table to reference

  • Relationships: Automatically creates underlying relationship

  • Example: Customer lookup, Account reference

Tested Column Scenarios

The following specific scenarios have been successfully tested and verified in comprehensive testing:

  1. String Column Creation ✅ Verified

    • Basic text field with default settings

    • Email format validation

    • Custom max length constraints

  2. Integer Column Creation ✅ Verified

    • Numeric field with min/max constraints (0-100 range)

    • Default value handling (not supported - properly handled)

  3. Boolean Column Creation ✅ Verified

    • Custom true/false labels ("Active"/"Inactive")

    • Default value configuration

  4. DateTime Column Creation ✅ Verified

    • DateOnly format for hire dates

    • DateAndTime format for login timestamps

  5. Picklist Column Creation ✅ Verified

    • Local option set with custom options

    • Global option set reference using existing option sets

  6. Lookup Column Creation ✅ Verified

    • Cross-table reference creation

    • Automatic relationship creation

  7. Decimal Column Creation ✅ Verified

    • Precision and scale configuration

    • Min/max value constraints

  8. Money Column Creation ✅ Verified

    • Currency field with precision

    • Proper money data type handling

  9. Memo Column Creation ✅ Verified

    • Long text field configuration

    • Max length settings

  10. Double Column Creation ✅ Verified

    • Floating-point number handling

    • Precision configuration

  11. BigInt Column Creation ✅ Verified

    • Large integer value support

    • Proper data type handling

Column Operations Status

Operation

Status

Description

Create

✅ Fully Tested

All column types with type-specific parameters

Read

✅ Fully Tested

Retrieve column metadata and configuration

Update

✅ Fully Tested

Modify display name, description, required level

Delete

✅ Fully Tested

Remove custom columns from tables (with dependency checking)

List

✅ Fully Tested

List all columns for a table with filtering

Testing & Quality Assurance

This MCP server has undergone comprehensive testing to ensure production readiness:

Test Coverage

  • ✅ 22 Major Test Phases Completed

  • ✅ 100% Tool Coverage - All 40+ tools tested

  • ✅ All Column Types Verified - Complete testing of all 11 supported column types

  • ✅ All Relationship Types Tested - One-to-Many and Many-to-Many relationships

  • ✅ Complete CRUD Operations - Create, Read, Update, Delete for all entity types

  • ✅ Error Handling Validated - Edge cases and invalid input handling

  • ✅ Microsoft Dataverse API Compliance - Full compliance with official API standards

Bugs Found and Fixed

During comprehensive testing, 7 critical bugs were identified and resolved:

  1. Integer Column Default Value Bug - Fixed unsupported DefaultValue property for IntegerAttributeMetadata

  2. Table Update Method Bug - Fixed to use PUT instead of PATCH for EntityMetadata updates

  3. Column Update Method Bug - Fixed to use PUT instead of PATCH for AttributeMetadata updates

  4. PublishXml Action Prefix Bug - Fixed global action calling without Microsoft.Dynamics.CRM prefix

  5. Option Set Update Method Bug - Fixed to use MetadataId instead of Name for PUT operations

  6. UpdateOptionValue Missing Parameter Bug - Added required MergeLabels parameter

  7. Option Set Action Prefix Bug - Fixed option set actions to not include incorrect prefix

Test Documentation

Production Readiness

  • ✅ Robust Error Handling - Comprehensive error handling for all scenarios

  • ✅ Dependency Management - Proper handling of entity dependencies and constraints

  • ✅ Security Compliance - Full security role and permission management

  • ✅ Performance Validated - Tested with large schemas and bulk operations

  • ✅ Microsoft Standards Compliant - Follows all Microsoft Dataverse best practices

Prerequisites

  1. Dataverse Environment - You need access to a Microsoft Dataverse environment

  2. Azure App Registration - An Azure AD app registration with appropriate permissions

  3. Client Credentials - Client ID, Client Secret, and Tenant ID for authentication

Setup

1. Azure App Registration

  1. Go to the Azure Portal

  2. Navigate to Azure Active Directory > App registrations

  3. Click New registration

  4. Provide a name (e.g., "Dataverse MCP Server")

  5. Select Accounts in this organizational directory only

  6. Click Register

2. Create Client Secret

  1. Go to Certificates & secrets

  2. Click New client secret

  3. Provide a description and expiration

  4. Click Add

  5. Copy the secret value immediately (you won't be able to see it again)

3. Create Application User in Dataverse

Critical Step: You must create an Application User in your Dataverse environment and assign appropriate permissions.

  1. Navigate to Dataverse Admin Center

  2. Create Application User

    • Click + New app user

    • Click + Add an app

    • Search for and select your Azure app registration (by Client ID)

    • Enter a Business unit (usually the root business unit)

    • Click Create

  3. Assign Security Roles

    • Select the newly created application user

    • Click Manage roles

    • Assign appropriate security roles based on your needs:

      • System Administrator: Full access (recommended for development/testing)

      • System Customizer: Schema operations without data access

      • Custom Role: Create specific permissions for production use

  4. Verify Application User Status

    • Ensure the application user is Enabled

    • Verify it shows as Application type (not User)

    • Note the Application ID matches your Azure app registration Client ID

4. Get Required Information

You'll need:

  • Tenant ID: Found in Azure AD > Overview

  • Client ID: Found in your app registration > Overview

  • Client Secret: The secret you just created

  • Dataverse URL: Your Dataverse environment URL (e.g., https://yourorg.crm.dynamics.com)

Installation

  1. Install dependencies:

npm install

  1. Build the server:

npm run build

  1. Copy the full path to the built index.js file:

    • The server will be built to the build/ directory

    • Copy the complete file path (e.g., /Users/yourname/path/to/dataverse-mcp/build/index.js)

    • You'll use this path in your MCP configuration file

  2. Configure the MCP server in your MCP settings file using the copied path (see Configuration section below for details)

Configuration

The server supports flexible environment variable configuration with the following precedence (highest to lowest):

  1. MCP environment variables (highest priority)

  2. System environment variables

  3. .env file variables (lowest priority)

Windows MCP Configuration

For Windows users, the MCP configuration requires using cmd with the /c flag to properly execute the Node.js server:

{
  "mcpServers": {
    "dataverse": {
      "command": "cmd",
      "args": [
        "/c",
        "node",
        "C:\\DEV\\projects\\dataverse-mcp\\build\\index.js"
      ],
      "env": {
        "DATAVERSE_URL": "https://yourorg.crm.dynamics.com",
        "DATAVERSE_CLIENT_ID": "your-client-id",
        "DATAVERSE_CLIENT_SECRET": "your-client-secret",
        "DATAVERSE_TENANT_ID": "your-tenant-id"
      },
      "disabled": false,
      "alwaysAllow": [],
      "disabledTools": [],
      "timeout": 900
    }
  }
}

Important Windows Notes:

  • Use cmd as the command with /c flag

  • Use full Windows paths with double backslashes (\\) or forward slashes (/)

  • The timeout setting is increased to 900 seconds (15 minutes) for longer operations

  • Environment variables can be configured directly in the MCP settings as shown above

⚠️ Security Warning: If you store your MCP settings file in your project directory (rather than in a global MCP configuration location), make sure to add it to your .gitignore file to prevent accidentally committing sensitive credentials:

# MCP configuration with sensitive credentials
mcp-settings.json
.mcp-settings.json
mcp.json

Option 1: Using .env file (Recommended for MCP Server Development)

The server automatically loads environment variables from a .env file in the project root. This is the recommended approach when contributing to or modifying the MCP server itself.

  1. Create your .env file:

cp .env.example .env

  1. Add the following configuration to your MCP settings file:

{
  "mcpServers": {
    "dataverse": {
      "command": "node",
      "args": ["/path/to/dataverse-mcp/build/index.js"],
      "disabled": false,
      "alwaysAllow": [],
      "disabledTools": [],
      "timeout": 900
    }
  }
}

Note: The timeout setting is increased to 900 seconds (15 minutes) to accommodate longer-running operations like schema export, which may need to process large amounts of metadata.

Option 2: Using MCP environment variables (Recommended for Normal Usage)

You can configure environment variables directly in the MCP settings. This is the recommended approach for normal usage when using the MCP Dataverse tool for development activities. These will override any values in the .env file:

{
  "mcpServers": {
    "dataverse": {
      "command": "node",
      "args": ["/path/to/dataverse-mcp/build/index.js"],
      "env": {
        "DATAVERSE_URL": "https://yourorg.crm.dynamics.com",
        "DATAVERSE_CLIENT_ID": "your-client-id",
        "DATAVERSE_CLIENT_SECRET": "your-client-secret",
        "DATAVERSE_TENANT_ID": "your-tenant-id"
      },
      "disabled": false,
      "alwaysAllow": [],
      "disabledTools": [],
      "timeout": 900
    }
  }
}

⚠️ Security Warning: If you store your MCP settings file in your project directory (rather than in a global MCP configuration location), make sure to add it to your .gitignore file to prevent accidentally committing sensitive credentials:

# MCP configuration with sensitive credentials
mcp-settings.json
.mcp-settings.json
mcp.json

Option 3: Hybrid Configuration

You can also use a combination approach where common settings are in .env and sensitive or environment-specific settings are overridden via MCP:

.env file:

DATAVERSE_URL=https://dev-org.crm.dynamics.com
DATAVERSE_TENANT_ID=common-tenant-id

MCP settings (overrides for production):

{
  "mcpServers": {
    "dataverse": {
      "command": "node",
      "args": ["/path/to/dataverse-mcp/build/index.js"],
      "env": {
        "DATAVERSE_URL": "https://prod-org.crm.dynamics.com",
        "DATAVERSE_CLIENT_ID": "prod-client-id",
        "DATAVERSE_CLIENT_SECRET": "prod-client-secret"
      },
      "disabled": false,
      "alwaysAllow": [],
      "disabledTools": [],
      "timeout": 900
    }
  }
}

Usage Examples

Creating a Custom Table

// Create a new custom table with automatic naming
// The system automatically generates:
// - Logical Name: xyz_project (using customization prefix from solution context)
// - Schema Name: xyz_Project (prefix lowercase, original case preserved, spaces removed)
// - Display Collection Name: Projects (auto-pluralized)
// - Primary Name Attribute: xyz_project_name
await use_mcp_tool("dataverse", "create_dataverse_table", {
  displayName: "Project",
  description: "Custom table for managing projects",
  ownershipType: "UserOwned",
  hasActivities: true,
  hasNotes: true
});

// Example with minimal parameters (most common usage)
await use_mcp_tool("dataverse", "create_dataverse_table", {
  displayName: "Customer Feedback"
});
// This creates:
// - Logical Name: xyz_customerfeedback
// - Schema Name: xyz_CustomerFeedback (prefix lowercase, original case preserved)
// - Display Collection Name: Customer Feedbacks
// - Primary Name Attribute: xyz_customerfeedback_name

Important: Before creating tables, ensure you have set a solution context using set_solution_context to provide the customization prefix. The system automatically uses the prefix from the active solution's publisher.

Adding Columns to a Table

// String column with email format and automatic naming
// The system automatically generates:
// - Logical Name: xyz_contactemail (prefix + lowercase, no spaces)
// - Schema Name: xyz_ContactEmail (prefix lowercase, original case preserved)
await use_mcp_tool("dataverse", "create_dataverse_column", {
  entityLogicalName: "xyz_project",
  displayName: "Contact Email",
  columnType: "String",
  format: "Email",
  maxLength: 100,
  requiredLevel: "ApplicationRequired"
});

// Integer column with constraints (generates xyz_priorityscore)
await use_mcp_tool("dataverse", "create_dataverse_column", {
  entityLogicalName: "xyz_project",
  displayName: "Priority Score",
  columnType: "Integer",
  minValue: 1,
  maxValue: 10,
  defaultValue: 5
});

// Boolean column with custom labels (generates xyz_isactive)
await use_mcp_tool("dataverse", "create_dataverse_column", {
  entityLogicalName: "xyz_project",
  displayName: "Is Active",
  columnType: "Boolean",
  trueOptionLabel: "Active",
  falseOptionLabel: "Inactive",
  defaultValue: true
});

// DateTime column (date only) (generates xyz_startdate)
await use_mcp_tool("dataverse", "create_dataverse_column", {
  entityLogicalName: "xyz_project",
  displayName: "Start Date",
  columnType: "DateTime",
  dateTimeFormat: "DateOnly",
  requiredLevel: "ApplicationRequired"
});

// DateTime column (date and time) (generates xyz_lastmodified)
await use_mcp_tool("dataverse", "create_dataverse_column", {
  entityLogicalName: "xyz_project",
  displayName: "Last Modified",
  columnType: "DateTime",
  dateTimeFormat: "DateAndTime"
});

// Picklist column with local options (generates xyz_status)
await use_mcp_tool("dataverse", "create_dataverse_column", {
  entityLogicalName: "xyz_project",
  displayName: "Status",
  columnType: "Picklist",
  options: [
    { value: 1, label: "Planning" },
    { value: 2, label: "In Progress" },
    { value: 3, label: "On Hold" },
    { value: 4, label: "Completed" }
  ]
});

// Picklist column using global option set (generates xyz_projectcolor)
await use_mcp_tool("dataverse", "create_dataverse_column", {
  entityLogicalName: "xyz_project",
  displayName: "Project Color",
  columnType: "Picklist",
  optionSetName: "xyz_colors"
});

// Lookup column (generates xyz_account)
await use_mcp_tool("dataverse", "create_dataverse_column", {
  entityLogicalName: "xyz_project",
  displayName: "Account",
  columnType: "Lookup",
  targetEntity: "account"
});

// Memo column for long text (generates xyz_description)
await use_mcp_tool("dataverse", "create_dataverse_column", {
  entityLogicalName: "xyz_project",
  displayName: "Description",
  columnType: "Memo",
  maxLength: 2000,
  requiredLevel: "Recommended"
});

Creating AutoNumber Columns

AutoNumber columns automatically generate unique alphanumeric strings using customizable format patterns. They're perfect for creating serial numbers, reference codes, and other automatically generated identifiers.

// Create an AutoNumber column with sequential numbering
await use_mcp_tool("dataverse", "create_autonumber_column", {
  entityLogicalName: "xyz_project",
  displayName: "Project Number",
  autoNumberFormat: "PRJ-{SEQNUM:5}",
  maxLength: 20,
  requiredLevel: "SystemRequired"
});
// Generates: PRJ-00001, PRJ-00002, PRJ-00003, etc.

// Create an AutoNumber column with date and random string
await use_mcp_tool("dataverse", "create_autonumber_column", {
  entityLogicalName: "xyz_invoice",
  displayName: "Invoice Reference",
  autoNumberFormat: "INV-{DATETIMEUTC:yyyyMMdd}-{RANDSTRING:4}",
  maxLength: 30,
  description: "Auto-generated invoice reference number"
});
// Generates: INV-20250814-A7K9, INV-20250814-M3X2, etc.

// Create a complex AutoNumber format with multiple placeholders
await use_mcp_tool("dataverse", "create_autonumber_column", {
  entityLogicalName: "xyz_order",
  displayName: "Order Code",
  autoNumberFormat: "ORD-{DATETIMEUTC:yyyy}-{SEQNUM:4}-{RANDSTRING:2}",
  maxLength: 25,
  requiredLevel: "ApplicationRequired"
});
// Generates: ORD-2025-0001-AB, ORD-2025-0002-XY, etc.

// Update an existing AutoNumber format
await use_mcp_tool("dataverse", "update_autonumber_format", {
  entityLogicalName: "xyz_project",
  columnLogicalName: "xyz_projectnumber",
  autoNumberFormat: "PROJECT-{DATETIMEUTC:yyyy}-{SEQNUM:6}",
  displayName: "Updated Project Number"
});

// Set the seed value for sequential numbering (starts next sequence from 10000)
await use_mcp_tool("dataverse", "set_autonumber_seed", {
  entityLogicalName: "xyz_project",
  columnLogicalName: "xyz_projectnumber",
  seedValue: 10000
});

// Convert an existing text column to AutoNumber
await use_mcp_tool("dataverse", "convert_to_autonumber", {
  entityLogicalName: "xyz_customer",
  columnLogicalName: "xyz_customercode",
  autoNumberFormat: "CUST-{SEQNUM:5}",
  maxLength: 15
});

// Get AutoNumber column information
await use_mcp_tool("dataverse", "get_autonumber_column", {
  entityLogicalName: "xyz_project",
  columnLogicalName: "xyz_projectnumber"
});

// List all AutoNumber columns in a table
await use_mcp_tool("dataverse", "list_autonumber_columns", {
  entityLogicalName: "xyz_project",
  customOnly: true
});

// List all AutoNumber columns across all tables
await use_mcp_tool("dataverse", "list_autonumber_columns", {
  customOnly: true,
  includeManaged: false
});

AutoNumber Format Placeholders

AutoNumber columns support the following format placeholders:

Placeholder

Description

Example

Output

{SEQNUM:n}

Sequential number with n digits (zero-padded)

{SEQNUM:4}

0001, 0002, 0003

{RANDSTRING:n}

Random string with n characters (1-6)

{RANDSTRING:3}

A7K, M3X, Q9Z

{DATETIMEUTC:format}

UTC date/time with custom format

{DATETIMEUTC:yyyyMMdd}

20250814

{DATETIMEUTC:yyyy-MM}

2025-08

{DATETIMEUTC:yyMMddHHmm}

2508141430

AutoNumber Format Examples

// Simple sequential numbering
"TICKET-{SEQNUM:5}"
// Output: TICKET-00001, TICKET-00002, TICKET-00003

// Date-based with sequence
"INV-{DATETIMEUTC:yyyyMM}-{SEQNUM:4}"
// Output: INV-202508-0001, INV-202508-0002

// Complex format with all placeholders
"REF-{DATETIMEUTC:yyyy}-{SEQNUM:3}-{RANDSTRING:2}"
// Output: REF-2025-001-AB, REF-2025-002-XY

// Year and random string only
"PROJ-{DATETIMEUTC:yy}{RANDSTRING:4}"
// Output: PROJ-25A7K9, PROJ-25M3X2

// Daily sequence reset pattern
"DAILY-{DATETIMEUTC:yyyyMMdd}-{SEQNUM:3}"
// Output: DAILY-20250814-001, DAILY-20250814-002

Creating Tables with AutoNumber Primary Names

You can create tables with AutoNumber primary name columns directly:

// Create a table with AutoNumber primary name
await use_mcp_tool("dataverse", "create_dataverse_table", {
  displayName: "Support Ticket",
  description: "Customer support tickets with auto-generated ticket numbers",
  primaryNameAutoNumberFormat: "TICKET-{DATETIMEUTC:yyyyMM}-{SEQNUM:4}",
  hasActivities: true,
  hasNotes: true
});
// Creates table with primary name column that generates: TICKET-202508-0001, TICKET-202508-0002, etc.

// Create a project table with year-based numbering
await use_mcp_tool("dataverse", "create_dataverse_table", {
  displayName: "Project",
  description: "Projects with auto-generated project codes",
  primaryNameAutoNumberFormat: "PRJ-{DATETIMEUTC:yyyy}-{SEQNUM:5}",
  ownershipType: "UserOwned"
});
// Creates: PRJ-2025-00001, PRJ-2025-00002, etc.

AutoNumber Best Practices

Format Design:

  • Keep formats concise but descriptive

  • Use consistent prefixes across related entities

  • Consider date formats for time-based organization

  • Plan for sufficient sequence digits to avoid overflow

Seed Management:

  • Set seed values in development to avoid conflicts

  • Remember that seeds are environment-specific

  • Use higher seed values in production (e.g., 10000+)

  • Document seed values for environment promotion

Column Configuration:

  • Set appropriate maxLength to accommodate format expansion

  • Use SystemRequired for critical identifier columns

  • Consider audit requirements for tracking changes

  • Test format patterns before production deployment

Environment Considerations:

  • Seed values don't transfer with solutions

  • Test AutoNumber generation in target environments

  • Plan for data migration scenarios

  • Consider backup and restore implications

Creating Relationships

// Create a One-to-Many relationship
await use_mcp_tool("dataverse", "create_dataverse_relationship", {
  relationshipType: "OneToMany",
  schemaName: "new_account_project",
  referencedEntity: "account",
  referencingEntity: "new_project",
  referencingAttributeLogicalName: "new_accountid",
  referencingAttributeDisplayName: "Account",
  cascadeDelete: "RemoveLink"
});

Managing Option Sets

// Create a global option set
await use_mcp_tool("dataverse", "create_dataverse_optionset", {
  name: "new_priority",
  displayName: "Priority Levels",
  options: [
    { value: 1, label: "Low", color: "#00FF00" },
    { value: 2, label: "Medium", color: "#FFFF00" },
    { value: 3, label: "High", color: "#FF0000" }
  ]
});

Managing Security Roles

// Create a new security role
await use_mcp_tool("dataverse", "create_dataverse_role", {
  name: "Project Manager",
  description: "Role for project managers with specific permissions",
  appliesTo: "Project management team members",
  isAutoAssigned: false,
  isInherited: "1",
  summaryOfCoreTablePermissions: "Read/Write access to project-related tables"
});

// Get security role information
await use_mcp_tool("dataverse", "get_dataverse_role", {
  roleId: "role-guid-here"
});

// List security roles
await use_mcp_tool("dataverse", "list_dataverse_roles", {
  customOnly: true,
  includeManaged: false,
  top: 20
});

// Add privileges to a role
await use_mcp_tool("dataverse", "add_privileges_to_role", {
  roleId: "role-guid-here",
  privileges: [
    { privilegeId: "privilege-guid-1", depth: "Global" },
    { privilegeId: "privilege-guid-2", depth: "Local" }
  ]
});

// Assign role to a user
await use_mcp_tool("dataverse", "assign_role_to_user", {
  roleId: "role-guid-here",
  userId: "user-guid-here"
});

// Assign role to a team
await use_mcp_tool("dataverse", "assign_role_to_team", {
  roleId: "role-guid-here",
  teamId: "team-guid-here"
});

// Get role privileges
await use_mcp_tool("dataverse", "get_role_privileges", {
  roleId: "role-guid-here"
});

Managing Teams

// Create a new team
await use_mcp_tool("dataverse", "create_dataverse_team", {
  name: "Development Team",
  description: "Team for software development activities",
  administratorId: "admin-user-guid-here",
  teamType: "0", // Owner team
  membershipType: "0", // Members and guests
  emailAddress: "devteam@company.com"
});

// Get team information
await use_mcp_tool("dataverse", "get_dataverse_team", {
  teamId: "team-guid-here"
});

// List teams with filtering
await use_mcp_tool("dataverse", "list_dataverse_teams", {
  teamType: "0", // Owner teams only
  excludeDefault: true,
  top: 20
});

// Add members to a team
await use_mcp_tool("dataverse", "add_members_to_team", {
  teamId: "team-guid-here",
  memberIds: ["user-guid-1", "user-guid-2", "user-guid-3"]
});

// Get team members
await use_mcp_tool("dataverse", "get_team_members", {
  teamId: "team-guid-here"
});

// Remove members from a team
await use_mcp_tool("dataverse", "remove_members_from_team", {
  teamId: "team-guid-here",
  memberIds: ["user-guid-1", "user-guid-2"]
});

// Update team properties
await use_mcp_tool("dataverse", "update_dataverse_team", {
  teamId: "team-guid-here",
  name: "Updated Development Team",
  description: "Updated description for the development team",
  emailAddress: "newdevteam@company.com"
});

// Convert owner team to access team
await use_mcp_tool("dataverse", "convert_owner_team_to_access_team", {
  teamId: "owner-team-guid-here"
});

Managing Business Units

// Create a new business unit with comprehensive information
await use_mcp_tool("dataverse", "create_dataverse_businessunit", {
  name: "Sales Division",
  description: "Business unit for sales operations",
  divisionName: "Sales",
  emailAddress: "sales@company.com",
  costCenter: "SALES-001",
  creditLimit: 100000,
  parentBusinessUnitId: "parent-bu-guid-here",
  // Address information
  address1_name: "Sales Office",
  address1_line1: "123 Business Street",
  address1_city: "New York",
  address1_stateorprovince: "NY",
  address1_postalcode: "10001",
  address1_country: "United States",
  address1_telephone1: "+1-555-0123",
  address1_fax: "+1-555-0124",
  // Website and other details
  webSiteUrl: "https://sales.company.com",
  stockExchange: "NYSE",
  tickerSymbol: "COMP"
});

// Get business unit information
await use_mcp_tool("dataverse", "get_dataverse_businessunit", {
  businessUnitId: "business-unit-guid-here"
});

// List business units with filtering
await use_mcp_tool("dataverse", "list_dataverse_businessunits", {
  filter: "isdisabled eq false",
  orderby: "name asc",
  top: 20
});

// Update business unit properties
await use_mcp_tool("dataverse", "update_dataverse_businessunit", {
  businessUnitId: "business-unit-guid-here",
  name: "Updated Sales Division",
  description: "Updated description for sales operations",
  emailAddress: "newsales@company.com",
  creditLimit: 150000,
  // Update address information
  address1_line1: "456 New Business Avenue",
  address1_telephone1: "+1-555-9999"
});

// Get business unit hierarchy
await use_mcp_tool("dataverse", "get_businessunit_hierarchy", {
  businessUnitId: "business-unit-guid-here"
});

// Change business unit parent (reorganization)
await use_mcp_tool("dataverse", "set_businessunit_parent", {
  businessUnitId: "child-bu-guid-here",
  parentBusinessUnitId: "new-parent-bu-guid-here"
});

// Get users in a business unit
await use_mcp_tool("dataverse", "get_businessunit_users", {
  businessUnitId: "business-unit-guid-here",
  includeSubsidiaryUsers: false // Set to true to include users from child business units
});

// Get teams in a business unit
await use_mcp_tool("dataverse", "get_businessunit_teams", {
  businessUnitId: "business-unit-guid-here",
  includeSubsidiaryTeams: true // Include teams from subsidiary business units
});

// Delete a business unit (ensure no dependencies exist)
await use_mcp_tool("dataverse", "delete_dataverse_businessunit", {
  businessUnitId: "business-unit-guid-here"
});

Exporting Solution Schema

// Export custom schema only (default settings)
// Exports tables, columns, option sets, and relationships to JSON
await use_mcp_tool("dataverse", "export_solution_schema", {
  outputPath: "my-solution-schema.json"
});

// Export with system entities included for comprehensive documentation
await use_mcp_tool("dataverse", "export_solution_schema", {
  outputPath: "complete-schema.json",
  includeAllSystemTables: true,
  includeSystemColumns: true,
  includeSystemOptionSets: true
});

// Export multiple customization prefixes simultaneously
await use_mcp_tool("dataverse", "export_solution_schema", {
  outputPath: "multi-prefix-schema.json",
  customizationPrefixes: ["xyz", "abc", "its"],
  systemTablesToInclude: ["contact", "account", "opportunity"]
});

// Export with column prefix exclusion (removes unwanted columns)
await use_mcp_tool("dataverse", "export_solution_schema", {
  outputPath: "clean-schema.json",
  excludeColumnPrefixes: ["adx_", "msa_", "msdyn_", "mspp_", "old_"],
  includeSystemColumns: false
});

// Export minified JSON for production use
await use_mcp_tool("dataverse", "export_solution_schema", {
  outputPath: "schema-minified.json",
  prettify: false
});

// Export only tables matching solution customization prefix (legacy approach)
await use_mcp_tool("dataverse", "export_solution_schema", {
  outputPath: "prefix-only-schema.json",
  prefixOnly: true,
  prettify: true
});

Schema Export Features:

  • Schema Capture: Exports tables, columns, and global option sets (relationships not yet implemented)

  • Flexible Filtering: Choose to include or exclude system entities

  • Solution Context Aware: Automatically includes solution metadata when context is set

  • Comprehensive Metadata: Captures all entity properties and column types

  • JSON Format: Human-readable or minified output options

  • Directory Creation: Automatically creates output directories if they don't exist

Example Output Structure:

{
  "metadata": {
    "exportedAt": "2025-07-26T17:30:00.000Z",
    "solutionUniqueName": "xyzsolution",
    "solutionDisplayName": "XYZ Test Solution",
    "publisherPrefix": "xyz",
    "includeSystemTables": false,
    "includeSystemColumns": false,
    "includeSystemOptionSets": false
  },
  "tables": [
    {
      "logicalName": "xyz_project",
      "displayName": "Project",
      "schemaName": "xyz_Project",
      "ownershipType": "UserOwned",
      "isCustomEntity": true,
      "columns": [
        {
          "logicalName": "xyz_name",
          "displayName": "Name",
          "attributeType": "String",
          "maxLength": 100,
          "isPrimaryName": true
        }
      ]
    }
  ],
  "globalOptionSets": [
    {
      "name": "xyz_priority",
      "displayName": "Priority Levels",
      "isGlobal": true,
      "options": [
        { "value": 1, "label": "Low" },
        { "value": 2, "label": "High" }
      ]
    }
  ]
}

Enhanced Features:

  • Multiple Customization Prefixes: Export tables from multiple publishers simultaneously

  • Column Prefix Exclusion: Filter out unwanted columns (default excludes: adx_, msa_, msdyn_, mspp_)

  • Primary Key Inclusion: All Primary Key columns are automatically included regardless of system column settings

  • Improved System Table Filtering: Better control over which system tables to include with sensible defaults

Mermaid Diagram Generation

The Mermaid Diagram Generation tool converts exported JSON schemas into professional Entity Relationship Diagrams using Mermaid syntax. This provides visual documentation of your Dataverse schema with relationships, column details, and professional formatting.

Key Features

  • Professional ERD Generation: Creates publication-ready Entity Relationship Diagrams

  • Schema-Based Relationships: Uses only exported relationship metadata for accurate representation

  • Enhanced Column Markers: Visual indicators for Primary Keys (PK), Foreign Keys (FK), Primary Names (PN), and required fields

  • Lookup Target Display: Shows which tables each lookup column references (e.g., "Lookup (contact, account)")

  • Table Filtering: Filter diagrams to specific tables using tableNameFilter parameter

  • Comprehensive Headers: Generated files include complete context and regeneration instructions

  • Mermaid Compatibility: Works with Mermaid Live Editor, VS Code extensions, GitHub, and documentation tools

Usage Examples

// Generate a complete diagram from exported schema
await use_mcp_tool("dataverse", "generate_mermaid_diagram", {
  schemaPath: "my-solution-schema.json",
  outputPath: "schema-diagram.mmd",
  includeColumns: true,
  includeRelationships: true
});

// Generate diagram without column details for overview
await use_mcp_tool("dataverse", "generate_mermaid_diagram", {
  schemaPath: "complete-schema.json",
  outputPath: "overview-diagram.mmd",
  includeColumns: false,
  includeRelationships: true
});

// Generate diagram for specific tables only
await use_mcp_tool("dataverse", "generate_mermaid_diagram", {
  schemaPath: "large-schema.json",
  outputPath: "filtered-diagram.mmd",
  tableNameFilter: ["its_customer", "its_bill", "its_payment"],
  includeColumns: true,
  includeRelationships: true
});

// Generate relationship-only diagram for architecture overview
await use_mcp_tool("dataverse", "generate_mermaid_diagram", {
  schemaPath: "schema-export.json",
  outputPath: "relationships-only.mmd",
  includeColumns: false,
  includeRelationships: true,
  tableNameFilter: ["contact", "account", "opportunity"]
});

Example Output

The tool generates professional Mermaid ERD syntax like this:

erDiagram
    its_customer {
        uuid its_customerid PK "NOT NULL"
        string its_customername "Primary Name NOT NULL"
        string its_email "NOT NULL"
        string its_phone
        boolean its_isactive "NOT NULL"
    }
    
    its_bill {
        uuid its_billid PK "NOT NULL"
        string its_billnumber "Primary Name NOT NULL"
        uuid its_customerid FK "Lookup (its_customer) NOT NULL"
        decimal its_amount "NOT NULL"
        datetime its_duedate "NOT NULL"
        int its_status "NOT NULL"
    }
    
    its_customer ||--o{ its_bill : "Customer Bills"

Column Markers Explained

  • PK: Primary Key columns (unique identifiers)

  • FK: Foreign Key columns (lookup references)

  • Primary Name: The display name column for records

  • NOT NULL: Required fields

  • Lookup (table1, table2): Shows which tables the lookup column can reference

Diagram Features

  • Table Visualization: Each table shows its logical name and all columns

  • Column Details: Data types, constraints, and special markers

  • Relationship Lines: Visual connections between related tables

  • Cardinality Indicators: Shows one-to-many (||--o{) and many-to-many (}o--o{) relationships

  • Professional Formatting: Clean, readable diagrams suitable for documentation

Integration with Documentation Tools

Generated Mermaid diagrams work seamlessly with:

  • Mermaid Live Editor (https://mermaid.live) - Online diagram editor and viewer

  • VS Code Mermaid Preview - Real-time diagram preview in your editor

  • GitHub/GitLab - Native Mermaid support in markdown files

  • Documentation Sites - Gitiles, MkDocs, and other documentation platforms

  • Confluence - Via Mermaid plugins for enterprise documentation

Workflow Example

  1. Export Schema: Use export_solution_schema to create JSON schema file

  2. Generate Diagram: Use generate_mermaid_diagram to create visual ERD

  3. Review Relationships: Verify all lookup columns show correct target tables

  4. Documentation: Include diagrams in project documentation or wiki

  5. Team Sharing: Share visual schema with stakeholders and developers

This tool is essential for documenting complex Dataverse schemas and communicating data relationships to both technical and non-technical stakeholders.

WebAPI Call Generator

The WebAPI Call Generator tool helps developers construct proper Dataverse WebAPI calls by generating complete HTTP requests with correct URLs, headers, and request bodies. This is particularly useful for:

  • Learning WebAPI syntax - See how different operations translate to HTTP calls

  • Debugging API issues - Generate reference calls to compare against your implementation

  • Documentation - Create examples for team members or API documentation

  • Testing - Get ready-to-use cURL commands and JavaScript fetch examples

// Generate a simple retrieve operation
await use_mcp_tool("dataverse", "generate_webapi_call", {
  operation: "retrieve",
  entitySetName: "accounts",
  entityId: "12345678-1234-1234-1234-123456789012",
  // When no select is provided, the generator includes primary id and primary name by default
});

// Generate a retrieve multiple with filtering and sorting
await use_mcp_tool("dataverse", "generate_webapi_call", {
  operation: "retrieveMultiple",
  entitySetName: "contacts",
  select: ["fullname", "emailaddress1"],
  filter: "statecode eq 0 and contains(fullname,'John')",
  orderby: "fullname asc",
  top: 10,
  count: true
});

// Generate a create operation with return preference
await use_mcp_tool("dataverse", "generate_webapi_call", {
  operation: "create",
  entitySetName: "accounts",
  data: {
    name: "Test Account",
    emailaddress1: "test@example.com",
    telephone1: "555-1234"
  },
  prefer: ["return=representation"],
  includeAuthHeader: true
});

// Generate an update operation with conditional headers
await use_mcp_tool("dataverse", "generate_webapi_call", {
  operation: "update",
  entitySetName: "accounts",
  entityId: "12345678-1234-1234-1234-123456789012",
  data: {
    name: "Updated Account Name",
    telephone1: "555-5678"
  },
  ifMatch: "*"
});

// Generate an associate operation for relationships
await use_mcp_tool("dataverse", "generate_webapi_call", {
  operation: "associate",
  entitySetName: "accounts",
  entityId: "12345678-1234-1234-1234-123456789012",
  relationshipName: "account_primary_contact",
  relatedEntitySetName: "contacts",
  relatedEntityId: "87654321-4321-4321-4321-210987654321"
});

// Generate a bound action call
await use_mcp_tool("dataverse", "generate_webapi_call", {
  operation: "callAction",
  actionOrFunctionName: "WinOpportunity",
  entitySetName: "opportunities",
  entityId: "11111111-1111-1111-1111-111111111111",
  parameters: {
    Status: 3,
    Subject: "Won Opportunity"
  }
});

// Generate an unbound function call
await use_mcp_tool("dataverse", "generate_webapi_call", {
  operation: "callFunction",
  actionOrFunctionName: "WhoAmI",
  includeAuthHeader: true
});

// Generate a function call with parameters
await use_mcp_tool("dataverse", "generate_webapi_call", {
  operation: "callFunction",
  actionOrFunctionName: "GetTimeZoneCodeByLocalizedName",
  parameters: {
    LocalizedStandardName: "Pacific Standard Time",
    LocaleId: 1033
  }
});

Output Features:

  • Complete HTTP Request: Method, URL, headers, and body

  • cURL Command: Ready-to-execute command-line example

  • JavaScript Fetch: Copy-paste JavaScript code

  • Solution Context: Automatically includes current solution headers

  • Authentication Placeholder: Optional Bearer token placeholder

  • OData Query Building: Proper encoding of complex filter expressions

  • @odata.bind Normalization: Emits relative references (e.g., "/accounts(GUID)"), strips base URLs, upgrades mistaken logical-name keys to "@odata.bind"

  • Schema Awareness: Uses live metadata to infer primaryName, required fields, and correct navigation properties for lookups

Example Output:

HTTP Method: GET
URL: https://yourorg.crm.dynamics.com/api/data/v9.2/accounts(12345678-1234-1234-1234-123456789012)?$select=name,emailaddress1,telephone1

Headers:
  Content-Type: application/json
  Accept: application/json
  OData-MaxVersion: 4.0
  OData-Version: 4.0
  MSCRM.SolutionUniqueName: xyzsolution

--- Additional Information ---
Operation Type: retrieve
Entity Set: accounts
Entity ID: 12345678-1234-1234-1234-123456789012

Curl Command:
curl -X GET \
  "https://yourorg.crm.dynamics.com/api/data/v9.2/accounts(12345678-1234-1234-1234-123456789012)?$select=name,emailaddress1,telephone1" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -H "OData-MaxVersion: 4.0" \
  -H "OData-Version: 4.0" \
  -H "MSCRM.SolutionUniqueName: xyzsolution"

JavaScript Fetch Example:
fetch('https://yourorg.crm.dynamics.com/api/data/v9.2/accounts(12345678-1234-1234-1234-123456789012)?$select=name,emailaddress1,telephone1', {
  method: 'GET',
  headers: {
    "Content-Type": "application/json",
    "Accept": "application/json",
    "OData-MaxVersion": "4.0",
    "OData-Version": "4.0",
    "MSCRM.SolutionUniqueName": "xyzsolution"
  }
})
.then(response => response.json())
.then(data => console.log(data));

Supported Operations:

  • retrieve - Get a single record by ID

  • retrieveMultiple - Query multiple records with OData

  • create - Create new records

  • update - Update existing records (PATCH)

  • delete - Delete records

  • associate - Create relationships between records

  • disassociate - Remove relationships between records

  • callAction - Execute Dataverse actions (bound/unbound)

  • callFunction - Execute Dataverse functions (bound/unbound)

Advanced Features:

  • OData Query Options: $select, $filter, $orderby, $top, $skip, $expand, $count

  • Prefer Headers: return=representation, odata.include-annotations=*

  • Conditional Updates: If-Match, If-None-Match headers

  • Impersonation: MSCRMCallerID header support

  • Solution Context: Automatic MSCRM.SolutionUniqueName header inclusion

PowerPages WebAPI Generator

The PowerPages WebAPI Generator creates API calls specifically for PowerPages Single Page Applications (SPAs) using the PowerPages WebAPI format /_api/[logicalEntityName]s. This tool is designed for developers building modern React, Angular, or Vue applications within PowerPages environments.

Key Features:

  • Schema-Aware Operation: Automatically retrieves entity metadata for intelligent field selection and validation

  • @odata.bind Support: Full relationship management with automatic navigation property mapping and payload correction

  • Intelligent Field Selection: Automatically selects primary fields (ID and primary name) when no fields are specified

  • URL Format: Uses /_api/[logicalEntityName]s instead of /api/data/v9.2/[entitySetName] (note: 's' suffix is automatically added)

  • Authentication: Integrates with PowerPages authentication context and request verification tokens

  • Client-Side Focus: Optimized for browser-based applications with React component examples

  • PowerPages Security: Respects PowerPages table permissions and web roles

  • Enhanced Documentation: Comprehensive examples and schema information in generated output

// Generate a PowerPages retrieve multiple operation with schema-aware field selection
await use_mcp_tool("dataverse", "generate_powerpages_webapi_call", {
  operation: "retrieveMultiple",
  logicalEntityName: "cr7ae_creditcardses",
  select: ["cr7ae_name", "cr7ae_type", "cr7ae_features"],
  filter: "cr7ae_type eq 'Premium'",
  orderby: "cr7ae_name asc",
  top: 10,
  baseUrl: "https://contoso.powerappsportals.com",
  includeAuthContext: true
});

// Generate a PowerPages create operation with @odata.bind relationship management
await use_mcp_tool("dataverse", "generate_powerpages_webapi_call", {
  operation: "create",
  logicalEntityName: "cr7ae_creditcardses",
  data: {
    cr7ae_name: "New Premium Card",
    cr7ae_type: "Premium",
    cr7ae_features: "Cashback, Travel Insurance",
    // @odata.bind automatically maps to correct navigation property
    "cr7ae_accountid@odata.bind": "/accounts(12345678-1234-1234-1234-123456789012)"
  },
  baseUrl: "https://contoso.powerappsportals.com",
  requestVerificationToken: true
});

// Generate a PowerPages retrieve single record with automatic field inference
await use_mcp_tool("dataverse", "generate_powerpages_webapi_call", {
  operation: "retrieve",
  logicalEntityName: "contacts",
  entityId: "12345678-1234-1234-1234-123456789012",
  // When no select is provided, automatically includes primary ID and primary name
  baseUrl: "https://yoursite.powerappsportals.com"
});

// Generate an update operation with relationship management
await use_mcp_tool("dataverse", "generate_powerpages_webapi_call", {
  operation: "update",
  logicalEntityName: "cr7ae_creditcardses",
  entityId: "87654321-4321-4321-4321-210987654321",
  data: {
    cr7ae_name: "Updated Premium Card",
    // Associate with a different account
    "cr7ae_accountid@odata.bind": "/accounts(11111111-1111-1111-1111-111111111111)",
    // Disassociate from contact by setting to null
    "cr7ae_contactid@odata.bind": null
  },
  baseUrl: "https://contoso.powerappsportals.com",
  requestVerificationToken: true
});

// Generate with custom headers for advanced scenarios
await use_mcp_tool("dataverse", "generate_powerpages_webapi_call", {
  operation: "retrieveMultiple",
  logicalEntityName: "contacts",
  select: ["fullname", "emailaddress1"],
  filter: "contains(fullname,'John')",
  customHeaders: {
    "X-Custom-Header": "PowerPages-API",
    "X-Client-Version": "1.0"
  }
});

Output Features:

  • Schema-Aware Generation: Automatically retrieves entity metadata for intelligent code generation

  • @odata.bind Processing: Full relationship management with navigation property mapping and payload correction

  • Intelligent Field Selection: Automatically includes primary ID and primary name when no fields specified

  • PowerPages URL Format: Correct /_api/[logicalEntityName]s endpoint construction (automatic 's' suffix)

  • Request Verification Token: Automatic token handling for POST/PATCH/DELETE operations

  • JavaScript Examples: Ready-to-use fetch code with error handling and relationship management

  • React Components: Complete React hook examples for data fetching with schema information

  • Authentication Context: PowerPages user context and token management

  • OData Query Support: Full OData query parameter support with proper encoding

  • Enhanced Documentation: Comprehensive schema information and relationship examples in output

Example Output:

// PowerPages WebAPI Call with Schema-Aware Features
const fetchData = async () => {
  // Get the request verification token
  const token = document.querySelector('input[name="__RequestVerificationToken"]')?.value;

  try {
    const response = await fetch('/_api/cr7ae_creditcardses', {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
        'Accept': 'application/json',
        '__RequestVerificationToken': token
      },
      body: JSON.stringify({
        "cr7ae_name": "New Premium Card",
        "cr7ae_type": "Premium",
        "cr7ae_features": "Cashback, Travel Insurance",
        // @odata.bind automatically mapped to correct navigation property
        "cr7ae_accountid@odata.bind": "/accounts(12345678-1234-1234-1234-123456789012)"
      })
    });

    if (!response.ok) {
      throw new Error(`HTTP error! status: ${response.status}`);
    }

    const createdRecord = await response.json();
    console.log('Created record:', createdRecord);
    return createdRecord;
  } catch (error) {
    console.error('Error:', error);
    throw error;
  }
};

// Schema Information (automatically included in output)
/*
Entity: cr7ae_creditcardses
Primary ID: cr7ae_creditcardsesid
Primary Name: cr7ae_name
Navigation Properties:
- cr7ae_accountid -> accounts (Many-to-One)
- cr7ae_contactid -> contacts (Many-to-One)
*/

React Component Example with Schema-Aware Features:

// React Hook Example with Schema-Aware Field Selection
import React, { useState, useEffect } from 'react';

const CreditCardsList = () => {
  const [records, setRecords] = useState([]);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    const fetchRecords = async () => {
      try {
        // Schema-aware: automatically includes primary ID and name when no $select specified
        const response = await fetch('/_api/cr7ae_creditcardses?$select=cr7ae_name,cr7ae_type,cr7ae_accountid');
        
        if (!response.ok) {
          throw new Error(`HTTP error! status: ${response.status}`);
        }
        
        const data = await response.json();
        setRecords(data.value);
      } catch (error) {
        console.error('Error fetching records:', error);
        setError(error.message);
      } finally {
        setLoading(false);
      }
    };

    fetchRecords();
  }, []);

  const createRecord = async (recordData) => {
    const token = document.querySelector('input[name="__RequestVerificationToken"]')?.value;
    
    try {
      const response = await fetch('/_api/cr7ae_creditcardses', {
        method: 'POST',
        headers: {
          'Content-Type': 'application/json',
          'Accept': 'application/json',
          '__RequestVerificationToken': token
        },
        body: JSON.stringify({
          cr7ae_name: recordData.name,
          cr7ae_type: recordData.type,
          // @odata.bind for relationship management
          "cr7ae_accountid@odata.bind": recordData.accountId ? `/accounts(${recordData.accountId})` : null
        })
      });

      if (!response.ok) {
        throw new Error(`HTTP error! status: ${response.status}`);
      }

      const createdRecord = await response.json();
      setRecords(prev => [...prev, createdRecord]);
      return createdRecord;
    } catch (error) {
      console.error('Error creating record:', error);
      throw error;
    }
  };

  if (loading) return <div>Loading...</div>;
  if (error) return <div>Error: {error}</div>;

  return (
    <div>
      <h2>Credit Cards</h2>
      {records.map((record, index) => (
        <div key={record.cr7ae_creditcardsesid || index}>
          <h3>{record.cr7ae_name}</h3>
          <p>Type: {record.cr7ae_type}</p>
          {record.cr7ae_accountid && (
            <p>Account ID: {record.cr7ae_accountid}</p>
          )}
        </div>
      ))}
    </div>
  );
};

// Schema Information automatically provided:
/*
Entity: cr7ae_creditcardses
Primary ID: cr7ae_creditcardsesid
Primary Name: cr7ae_name
Navigation Properties:
- cr7ae_accountid -> accounts (Many-to-One)
- cr7ae_contactid -> contacts (Many-to-One)
*/

Authentication Context Integration:

// Access user information in PowerPages
const user = window["Microsoft"]?.Dynamic365?.Portal?.User;
const userName = user?.userName || "";
const firstName = user?.firstName || "";
const lastName = user?.lastName || "";
const isAuthenticated = userName !== "";

// Get authentication token (if needed)
const getToken = async () => {
  try {
    const token = await window.shell.getTokenDeferred();
    return token;
  } catch (error) {
    console.error('Error fetching token:', error);
    return null;
  }
};

PowerPages-Specific Features:

  • Schema-Aware Operation: Automatically retrieves and uses entity metadata for intelligent code generation

  • @odata.bind Relationship Management: Full support for creating, updating, and removing relationships with automatic navigation property mapping

  • Intelligent Field Selection: Automatically includes primary ID and primary name fields when no selection specified

  • Payload Correction: Automatically corrects lookup attribute names to proper navigation properties

  • Request Verification Token: Automatic __RequestVerificationToken header handling for secure operations

  • Authentication Integration: Built-in PowerPages user context access with comprehensive examples

  • React-Ready: Complete React component examples with hooks, state management, and relationship handling

  • Error Handling: Comprehensive error handling patterns for PowerPages environments

  • Security Compliance: Respects PowerPages table permissions and web role security

  • SPA Optimization: Designed for single-page application development patterns

  • Enhanced Documentation: Comprehensive schema information and relationship examples in generated output

Supported Operations:

  • retrieve - Get a single record by ID with automatic field selection

  • retrieveMultiple - Query multiple records with OData filtering and schema-aware field inference

  • create - Create new records with @odata.bind relationship management and request verification token

  • update - Update existing records (PATCH) with relationship management and token handling

  • delete - Delete records with proper authentication

Advanced Relationship Management:

  • @odata.bind Support: Full relationship management with automatic navigation property mapping

  • Payload Correction: Automatically converts lookup attribute names to navigation properties

  • Relationship Examples: Comprehensive examples for creating, updating, and removing relationships

  • Schema Validation: Uses live entity metadata to validate navigation properties and field names

This tool is essential for PowerPages developers building modern SPAs that need to interact with Dataverse data while maintaining PowerPages security and authentication patterns. The schema-aware capabilities ensure generated code is always accurate and up-to-date with your Dataverse schema.

PowerPages Configuration Management

The manage_powerpages_webapi_config tool helps manage table permissions and WebAPI site settings for PowerPages Code Sites. It automates the configuration of YAML files in the .powerpages-site directory structure, making it easier to set up and maintain WebAPI access for your PowerPages applications.

Key Features

  • Automated YAML Management: Creates and updates sitesetting.yml, webrole.yml, and table permission files

  • WebAPI Configuration: Enables WebAPI access with proper site settings

  • Table Permissions: Manages granular permissions for specific tables and web roles

  • Status Checking: Provides comprehensive status of current configurations

  • PowerPages Code Site Integration: Works seamlessly with the .powerpages-site directory structure

Usage Examples

Check Configuration Status

{
  "operation": "status"
}

Sample Output:

PowerPages WebAPI Configuration Status:

WebAPI Configuration:
✅ WebAPI is enabled (Webapi/cr7ae_creditcardses/Enabled = true)
✅ WebAPI fields are configured (Webapi/cr7ae_creditcardses/Fields = cr7ae_name,cr7ae_type,cr7ae_limit)

Web Roles:
✅ Authenticated Users role exists
✅ Anonymous Users role exists

Table Permissions:
✅ cr7ae_creditcardses permissions configured for Authenticated Users
  - Read: ✅, Create: ✅, Write: ✅, Delete: ❌
  - Scope: Global

Enable WebAPI for a Table

{
  "operation": "configure-webapi",
  "tableName": "cr7ae_creditcardses",
  "fields": ["cr7ae_name", "cr7ae_type", "cr7ae_limit", "cr7ae_isactive"],
  "enabled": true
}

Result:

  • Updates .powerpages-site/sitesetting.yml with WebAPI settings

  • Enables WebAPI access for the specified table

  • Configures allowed fields for WebAPI operations

Create Table Permissions

{
  "operation": "create-table-permission",
  "tableName": "cr7ae_creditcardses",
  "webRoleName": "Authenticated Users",
  "permissions": {
    "read": true,
    "create": true,
    "write": true,
    "delete": false
  },
  "scope": "Global"
}

Result:

  • Creates .powerpages-site/table-permissions/cr7ae_creditcardses_authenticated_users.yml

  • Configures specific CRUD permissions for the web role

  • Sets appropriate scope (Global, Contact, Account, Self, Parent, etc.)

List Current Configurations

{
  "operation": "list-configurations"
}

Sample Output:

Current PowerPages Configurations:

Site Settings (3 total):
- Webapi/cr7ae_creditcardses/Enabled = true
- Webapi/cr7ae_creditcardses/Fields = cr7ae_name,cr7ae_type,cr7ae_limit
- Authentication/Registration/Enabled = true

Web Roles (2 total):
- Authenticated Users (ID: 12345678-1234-1234-1234-123456789012)
- Anonymous Users (ID: 87654321-4321-4321-4321-210987654321)

Table Permissions (1 total):
- cr7ae_creditcardses_authenticated_users.yml
  Table: cr7ae_creditcardses, Role: Authenticated Users
  Permissions: Read ✅, Create ✅, Write ✅, Delete ❌
  Scope: Global

Operations

status

Provides a comprehensive overview of the current PowerPages WebAPI configuration including:

  • WebAPI enablement status for tables

  • Configured fields and permissions

  • Web role definitions

  • Table permission summaries

configure-webapi

Enables or configures WebAPI access for specific tables:

  • tableName (required): Logical name of the table

  • fields (optional): Array of field names to allow in WebAPI calls

  • enabled (optional): Boolean to enable/disable WebAPI access

create-table-permission

Creates granular table permissions for web roles:

  • tableName (required): Logical name of the table

  • webRoleName (required): Name of the web role

  • permissions (required): Object with read, create, write, delete boolean values

  • scope (optional): Permission scope (Global, Contact, Account, Self, Parent, etc.)

list-configurations

Lists all current configurations including:

  • Site settings with their values

  • Web roles with IDs

  • Table permissions with detailed permission breakdown

PowerPages Code Site Integration

This tool is designed to work with PowerPages Code Sites that follow the standard directory structure:

your-powerpages-project/
├── .powerpages-site/
│   ├── sitesetting.yml          # WebAPI and other site settings
│   ├── webrole.yml             # Web role definitions
│   └── table-permissions/      # Individual permission files
│       ├── cr7ae_creditcardses_authenticated_users.yml
│       └── contact_anonymous_users.yml
├── src/                        # Your React components
└── package.json

Example Workflow

  1. Check Current Status:

    {"operation": "status"}

  2. Enable WebAPI for Your Custom Table:

    {
  "operation": "configure-webapi",
  "tableName": "cr7ae_creditcardses",
  "fields": ["cr7ae_name", "cr7ae_type", "cr7ae_limit"],
  "enabled": true
}

  3. Create Table Permissions:

    {
  "operation": "create-table-permission",
  "tableName": "cr7ae_creditcardses",
  "webRoleName": "Authenticated Users",
  "permissions": {
    "read": true,
    "create": true,
    "write": true,
    "delete": false
  },
  "scope": "Global"
}

  4. Verify Configuration:

    {"operation": "list-configurations"}

  5. Use with PowerPages WebAPI Generator:

    {
  "operation": "retrieveMultiple",
  "logicalEntityName": "cr7ae_creditcardses",
  "select": ["cr7ae_name", "cr7ae_type", "cr7ae_limit"]
}

This workflow ensures your PowerPages Code Site is properly configured to handle WebAPI calls for your custom tables with appropriate security permissions.

Authentication

The server uses Client Credentials flow (Server-to-Server authentication) with Azure AD. This provides:

  • Secure authentication without user interaction

  • Application-level permissions

  • Suitable for automated scenarios

  • Token refresh handling

Error Handling

The server includes comprehensive error handling:

  • Authentication errors - Invalid credentials or expired tokens

  • API errors - Dataverse-specific error messages with codes

  • Validation errors - Parameter validation and type checking

  • Network errors - Connection and timeout handling

Security Considerations

  1. Store secrets securely - Never commit client secrets to version control

  2. Use environment variables - Configure secrets through environment variables

  3. Principle of least privilege - Grant only necessary permissions

  4. Monitor usage - Track API calls and authentication attempts

  5. Rotate secrets regularly - Update client secrets periodically

Troubleshooting

Common Issues

  1. Authentication Failed

    • Verify client ID, secret, and tenant ID

    • Check that the app registration is properly configured

  2. Permission Denied

    • Verify Application User Exists: Check that an application user has been created in Dataverse for your app registration

    • Check Security Roles: Ensure the application user has appropriate security roles:

      • System Administrator: Required for full schema operations

      • System Customizer: Minimum for table/column operations

      • Environment Maker: May be needed for solution operations

    • Verify User Status: Ensure the application user is enabled and not disabled

    • Check Business Unit: Verify the application user is assigned to the correct business unit

    • Validate Client ID: Confirm the Application ID in Dataverse matches your Azure app registration Client ID

  3. Entity Not Found

    • Verify entity logical names are correct

    • Check if entities exist in the target environment

  4. Invalid Column Type

    • Review supported column types in the documentation

    • Verify required parameters for specific column types

Debug Mode

Set environment variable DEBUG=true for verbose logging:

DEBUG=true node build/index.js

API Reference

For detailed parameter information for each tool, refer to the tool definitions in the source code:

Solution Management Best Practices

Publisher Configuration

When creating publishers, follow these guidelines:

  • Unique Prefixes: Use 2-8 character prefixes that identify your organization

  • Option Value Ranges: Use non-overlapping ranges (e.g., 10000-19999 for one publisher, 20000-29999 for another)

  • Descriptive Names: Use clear, professional names for publishers and solutions

Solution Context Management

// Check current context
await use_mcp_tool("dataverse", "get_solution_context", {});

// Switch to different solution
await use_mcp_tool("dataverse", "set_solution_context", {
  solutionUniqueName: "anothersolution"
});

// Clear context (removes persistence file)
await use_mcp_tool("dataverse", "clear_solution_context", {});

Environment Promotion

  1. Development: Create and test schema changes in dev environment with solution context

  2. Export: Use Power Platform CLI or admin center to export solution

  3. Import: Deploy solution to test/production environments

  4. Validation: Verify all customizations use proper prefixes

Git Integration

The .dataverse-mcp file is automatically excluded from version control:

# MCP Dataverse context file
.dataverse-mcp

This allows each developer to maintain their own solution context while preventing accidental sharing of environment-specific settings.

Developer Notebook

MCP Configuration Recommendations

This section provides real-world recommendations for configuring the Dataverse MCP server to accelerate development workflows.

Read-Only Tools for alwaysAllow Configuration

For faster development cycles, consider adding these read-only tools to your MCP server's alwaysAllow configuration. Since these tools only read data and don't make any changes to your Dataverse environment, they're safe to auto-approve and won't cause any side effects.

Recommended alwaysAllow configuration:

{
  "mcpServers": {
    "dataverse": {
      "command": "cmd",
      "args": ["/c", "node", "C:\\path\\to\\dataverse-mcp\\build\\index.js"],
      "env": {
        "DATAVERSE_URL": "https://yourorg.crm.dynamics.com",
        "DATAVERSE_CLIENT_ID": "your-client-id",
        "DATAVERSE_CLIENT_SECRET": "your-client-secret",
        "DATAVERSE_TENANT_ID": "your-tenant-id"
      },
      "alwaysAllow": [
        "get_dataverse_table",
        "list_dataverse_tables",
        "get_dataverse_column",
        "list_dataverse_columns",
        "get_dataverse_relationship",
        "list_dataverse_relationships",
        "get_dataverse_optionset",
        "list_dataverse_optionsets",
        "get_dataverse_optionset_options",
        "get_dataverse_solution",
        "get_dataverse_publisher",
        "list_dataverse_solutions",
        "list_dataverse_publishers",
        "get_solution_context",
        "get_dataverse_role",
        "list_dataverse_roles",
        "get_role_privileges",
        "get_dataverse_team",
        "list_dataverse_teams",
        "get_team_members",
        "get_dataverse_businessunit",
        "list_dataverse_businessunits",
        "get_businessunit_hierarchy",
        "get_businessunit_users",
        "get_businessunit_teams",
        "export_solution_schema",
        "generate_mermaid_diagram",
        "generate_webapi_call",
        "generate_powerpages_webapi_call"
      ],
      "timeout": 900
    }
  }
}

Benefits of This Configuration

🚀 Accelerated Development:

  • No approval prompts for schema exploration

  • Instant access to table and column information

  • Quick solution and publisher lookups

  • Immediate schema documentation generation

🔒 Zero Risk:

  • All listed tools are read-only operations

  • No data modification or schema changes

  • Safe for production environment connections

  • No side effects or unintended consequences

📊 Enhanced Productivity:

  • Faster debugging and troubleshooting

  • Instant schema validation and exploration

  • Quick relationship and dependency analysis

  • Seamless documentation generation workflow

Common Development Workflows

Schema Exploration:

// These will execute immediately without approval prompts
await use_mcp_tool("dataverse", "list_dataverse_tables", { customOnly: true });
await use_mcp_tool("dataverse", "get_dataverse_table", { logicalName: "xyz_project" });
await use_mcp_tool("dataverse", "list_dataverse_columns", { entityLogicalName: "xyz_project" });

Solution Analysis:

// Instant solution context and publisher information
await use_mcp_tool("dataverse", "get_solution_context", {});
await use_mcp_tool("dataverse", "list_dataverse_solutions", { includeManaged: false });
await use_mcp_tool("dataverse", "get_dataverse_publisher", { uniqueName: "xyzpublisher" });

Documentation Generation:

// Generate schema documentation without approval delays
await use_mcp_tool("dataverse", "export_solution_schema", {
  outputPath: "current-schema.json"
});
await use_mcp_tool("dataverse", "generate_mermaid_diagram", {
  schemaPath: "current-schema.json",
  outputPath: "schema-diagram.mmd"
});

WebAPI Code Generation:

// Generate API calls instantly for development
await use_mcp_tool("dataverse", "generate_webapi_call", {
  operation: "retrieveMultiple",
  entitySetName: "xyz_projects",
  select: ["xyz_name", "xyz_status"]
});

Developer Security Considerations

While these tools are read-only and safe, consider these security practices:

  • Environment Separation: Use different MCP configurations for dev/test/prod environments

  • Credential Management: Store sensitive credentials in secure environment variables

  • Access Monitoring: Regularly review which tools are in alwaysAllow lists

  • Team Guidelines: Establish team standards for MCP configuration management

Advanced Configuration Tips

Selective Tool Enabling: If you prefer more granular control, start with the most commonly used read-only tools:

"alwaysAllow": [
  "get_dataverse_table",
  "list_dataverse_tables",
  "get_dataverse_column",
  "list_dataverse_columns",
  "get_solution_context",
  "export_solution_schema"
]

This configuration approach significantly improves the developer experience while maintaining security through the separation of read-only and write operations.

Contributing

  1. Fork the repository

  2. Create a feature branch

  3. Make your changes

  4. Add tests if applicable

  5. Submit a pull request

Changelog

For a detailed history of changes, new features, and bug fixes, see the CHANGELOG.md file.

Recent Updates

  • v0.2.6: Schema-aware WebAPI generator, @odata.bind normalization, and lookup auto-correction

  • v0.1.2: Added comprehensive Security Role Management system with 13 new tools

  • v0.1.1: Introduced Solution-Based Architecture with persistent context

  • v0.1.0: Initial release with core table, column, relationship, and option set operations

The changelog follows Keep a Changelog format and includes:

  • Added: New features and capabilities

  • Changed: Modifications to existing functionality

  • Fixed: Bug fixes and corrections

  • Security: Security-related updates

Releasing

This project includes automated release scripts for maintainers:

Creating a Release

# Patch release (0.1.0 -> 0.1.1)
npm run release

# Minor release (0.1.0 -> 0.2.0)
npm run release:minor

# Major release (0.1.0 -> 1.0.0)
npm run release:major

These scripts will:

  1. Build the project

  2. Bump the version in package.json

  3. Create a git tag

  4. Push the changes and tag to GitHub

Automated GitHub Releases

When a tag is pushed to GitHub, the GitHub Actions workflow will automatically:

  1. Build the project

  2. Create release archives (.tar.gz and .zip)

  3. Create a GitHub release with the archives attached

  4. Include installation instructions in the release notes

Manual Release Process

If you prefer to create releases manually:

  1. Build the project: npm run build

  2. Update version: npm version [patch|minor|major]

  3. Push changes: git push && git push --tags

  4. The GitHub Actions workflow will handle the rest

License

MIT License - see LICENSE file for details.

Support

For issues and questions:

  1. Check the troubleshooting section

  2. Review Dataverse Web API documentation

  3. Create an issue in the repository

Available Tools

71 tools
add_members_to_teamAdd Members to TeamB

Adds users as members to a team, granting them access to team-owned records and team-based permissions. Use this to expand team membership and provide users with team-level access to resources.

ParametersJSON Schema
NameRequiredDescriptionDefault
memberIdsYesArray of user IDs to add as team members
teamIdYesID of the team to add members to

TDQS

B3.2/5.0
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.

add_privileges_to_roleAdd Privileges to Dataverse RoleB

Adds specific privileges with defined access levels to a security role. Use this to grant permissions for specific operations (create, read, write, delete, etc.) on entities or system functions. Each privilege can have different access levels (Basic, Local, Deep, Global).

ParametersJSON Schema
NameRequiredDescriptionDefault
privilegesYesArray of privileges to add to the role
roleIdYesID of the role to add privileges to

TDQS

B3.4/5.0
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.

assign_role_to_teamAssign Role to TeamA

Assigns a security role to a team, granting all team members the permissions defined in that role. Use this to provide consistent access levels to groups of users working together on similar tasks.

ParametersJSON Schema
NameRequiredDescriptionDefault
roleIdYesID of the role to assign
teamIdYesID of the team to assign the role to

TDQS

A3.6/5.0
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.

assign_role_to_userAssign Role to UserB

Assigns a security role to a specific user, granting them all the permissions defined in that role. Use this to provide users with the appropriate access levels for their job functions and responsibilities.

ParametersJSON Schema
NameRequiredDescriptionDefault
roleIdYesID of the role to assign
userIdYesID of the user to assign the role to

TDQS

B3.1/5.0
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.

clear_solution_contextClear Solution ContextA

Clears the currently active solution context. After clearing, metadata operations will not be associated with any specific solution. Use this when you want to work without a solution context or before switching to a different solution.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.6/5.0
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.

convert_owner_team_to_access_teamConvert Owner Team to Access TeamA

Converts an owner team to an access team, changing how the team can be used for record ownership and sharing. WARNING: This action cannot be undone and affects how records owned by this team are managed.

ParametersJSON Schema
NameRequiredDescriptionDefault
teamIdYesID of the owner team to convert to access team

TDQS

A4/5.0
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.

convert_to_autonumberConvert to AutoNumberA

Converts an existing text column to an AutoNumber column by adding an AutoNumberFormat. The column must be a String type with Text format and should be empty or contain compatible data.

ParametersJSON Schema
NameRequiredDescriptionDefault
autoNumberFormatYesAutoNumber format to apply using placeholders like "PREFIX-{SEQNUM:4}-{RANDSTRING:3}"
columnLogicalNameYesLogical name of the existing text column to convert
entityLogicalNameYesLogical name of the table containing the column
maxLengthNoNew maximum length if needed (ensure enough room for format expansion)

TDQS

A3.9/5.0
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.

create_autonumber_columnCreate AutoNumber ColumnA

Creates a new AutoNumber column in a Dataverse table with specified format. AutoNumber columns automatically generate alphanumeric strings using sequential numbers, random strings, and datetime placeholders. Requires a solution context to be set first.

ParametersJSON Schema
NameRequiredDescriptionDefault
autoNumberFormatYesAutoNumber format using placeholders like "PREFIX-{SEQNUM:4}-{RANDSTRING:3}-{DATETIMEUTC:yyyyMMdd}"
descriptionNoDescription of the AutoNumber column
displayNameYesDisplay name for the AutoNumber column (e.g., "Serial Number")
entityLogicalNameYesLogical name of the table to add the AutoNumber column to
isAuditEnabledNoWhether auditing is enabled for this column
isValidForAdvancedFindNoWhether the column appears in Advanced Find
isValidForCreateNoWhether the column can be set during create
isValidForUpdateNoWhether the column can be updated
maxLengthNoMaximum length for the column (default: 100, ensure enough room for format expansion)
requiredLevelNoRequired level of the columnNone
schemaNameNoSchema name for the column (auto-generated if not provided)

TDQS

A3.9/5.0
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.

create_dataverse_businessunitCreate Dataverse Business UnitB

Creates a new business unit in Dataverse with comprehensive configuration options including contact information, addresses, and organizational hierarchy. Business units are used to organize users and control data access in Dataverse.

ParametersJSON Schema
NameRequiredDescriptionDefault
address1_cityNoCity name for address 1
address1_countryNoCountry/region name for address 1
address1_countyNoCounty name for address 1
address1_faxNoFax number for address 1
address1_latitudeNoLatitude for address 1
address1_line1NoFirst line for address 1
address1_line2NoSecond line for address 1
address1_line3NoThird line for address 1
address1_longitudeNoLongitude for address 1
address1_nameNoName for address 1
address1_postalcodeNoZIP Code or postal code for address 1
address1_postofficeboxNoPost office box number for address 1
address1_stateorprovinceNoState or province for address 1
address1_telephone1NoMain phone number for address 1
address1_telephone2NoOther phone number for address 1
address1_telephone3NoThird telephone number for address 1
address1_upszoneNoUPS zone for address 1
address1_utcoffsetNoUTC offset for address 1
address2_cityNoCity name for address 2
address2_countryNoCountry/region name for address 2
address2_countyNoCounty name for address 2
address2_faxNoFax number for address 2
address2_latitudeNoLatitude for address 2
address2_line1NoFirst line for address 2
address2_line2NoSecond line for address 2
address2_line3NoThird line for address 2
address2_longitudeNoLongitude for address 2
address2_nameNoName for address 2
address2_postalcodeNoZIP Code or postal code for address 2
address2_postofficeboxNoPost office box number for address 2
address2_stateorprovinceNoState or province for address 2
address2_telephone1NoFirst telephone number for address 2
address2_telephone2NoSecond telephone number for address 2
address2_telephone3NoThird telephone number for address 2
address2_upszoneNoUPS zone for address 2
address2_utcoffsetNoUTC offset for address 2
costCenterNoName of the business unit cost center
creditLimitNoCredit limit for the business unit
descriptionNoDescription of the business unit
divisionNameNoName of the division to which the business unit belongs
emailAddressNoEmail address for the business unit
fileAsNameNoAlternative name under which the business unit can be filed
ftpSiteUrlNoFTP site URL for the business unit
isDisabledNoWhether the business unit is disabled
nameYesName of the business unit
parentBusinessUnitIdNoUnique identifier for the parent business unit
stockExchangeNoStock exchange on which the business is listed
tickerSymbolNoStock exchange ticker symbol for the business unit
webSiteUrlNoWebsite URL for the business unit

TDQS

B3.3/5.0
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.

create_dataverse_columnCreate Dataverse ColumnA

Creates a new column (field) in a Dataverse table with the specified data type and configuration. Supports various column types including text, numbers, dates, lookups, and choice lists. Use this to add new fields to store specific data in your tables. Requires a solution context to be set first.

ParametersJSON Schema
NameRequiredDescriptionDefault
columnTypeYesType of the column
dateTimeFormatNoFormat for datetime columns
defaultValueNoDefault value for the column
descriptionNoDescription of the column
displayNameYesDisplay name for the column (e.g., 'Customer Email')
entityLogicalNameYesLogical name of the table to add the column to
falseOptionLabelNoLabel for false option in boolean columns (default: 'No')
formatNoFormat for string columns
isAuditEnabledNoWhether auditing is enabled for this column
isValidForAdvancedFindNoWhether the column appears in Advanced Find
isValidForCreateNoWhether the column can be set during create
isValidForUpdateNoWhether the column can be updated
maxLengthNoMaximum length for string columns (default: 100)
maxValueNoMaximum value for integer/decimal columns
minValueNoMinimum value for integer/decimal columns
optionSetNameNoName of the option set for picklist columns
optionsNoOptions for picklist columns
precisionNoPrecision for decimal columns (default: 2)
requiredLevelNoRequired level of the columnNone
targetEntityNoTarget entity for lookup columns
trueOptionLabelNoLabel for true option in boolean columns (default: 'Yes')

TDQS

A3.8/5.0
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.

create_dataverse_optionsetCreate Dataverse Option SetA

Creates a new global option set (choice list) in Dataverse with predefined options. Use this to create reusable choice lists that can be used across multiple tables and columns. Option sets provide consistent data entry options and improve data quality.

ParametersJSON Schema
NameRequiredDescriptionDefault
descriptionNoDescription of the option set
displayNameYesDisplay name for the option set
isGlobalNoWhether this is a global option set
nameYesName for the option set (e.g., 'new_priority')
optionsYesArray of options for the option set

TDQS

A3.7/5.0
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.

create_dataverse_publisherCreate Dataverse PublisherA

Creates a new publisher in Dataverse. Publishers are required for creating solutions and provide customization prefixes for schema names. Use this to establish a publisher identity before creating solutions and custom components.

ParametersJSON Schema
NameRequiredDescriptionDefault
customizationOptionValuePrefixYesOption value prefix (e.g., 72700)
customizationPrefixYesCustomization prefix for schema names (e.g., 'sample')
descriptionNoDescription of the publisher
friendlyNameYesFriendly name for the publisher
uniqueNameYesUnique name for the publisher (e.g., 'examplepublisher')

TDQS

A3.7/5.0
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.

create_dataverse_relationshipCreate Dataverse RelationshipA

Creates a relationship between two Dataverse tables. Supports One-to-Many relationships (parent-child with lookup field) and Many-to-Many relationships (junction table). Use this to establish data connections between tables, enable navigation, and maintain referential integrity.

ParametersJSON Schema
NameRequiredDescriptionDefault
cascadeAssignNoCascade behavior for assign operationsNoCascade
cascadeDeleteNoCascade behavior for delete operationsRemoveLink
cascadeMergeNoCascade behavior for merge operationsNoCascade
cascadeReparentNoCascade behavior for reparent operationsNoCascade
cascadeShareNoCascade behavior for share operationsNoCascade
cascadeUnshareNoCascade behavior for unshare operationsNoCascade
entity1LogicalNameNoFirst entity logical name for Many-to-Many relationships
entity2LogicalNameNoSecond entity logical name for Many-to-Many relationships
intersectEntityNameNoName for the intersect entity (auto-generated if not provided)
isHierarchicalNoWhether this is a hierarchical relationship (One-to-Many only)
isValidForAdvancedFindNoWhether the relationship is valid for Advanced Find
menuBehaviorNoHow the relationship appears in associated menusUseCollectionName
menuGroupNoMenu group for the relationshipDetails
menuLabelNoCustom label for the menu (required if menuBehavior is UseLabel)
menuOrderNoOrder in the menu
referencedEntityNoReferenced (parent) entity logical name for One-to-Many relationships
referencingAttributeDisplayNameNoDisplay name for the lookup attribute
referencingAttributeLogicalNameNoLogical name for the lookup attribute to be created
referencingEntityNoReferencing (child) entity logical name for One-to-Many relationships
relationshipTypeYesType of relationship to create
schemaNameYesSchema name for the relationship (e.g., 'new_account_contact')

TDQS

A3.6/5.0
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.

create_dataverse_roleCreate Dataverse Security RoleA

Creates a new security role in Dataverse to define permissions and access levels for users and teams. Security roles control what users can see and do within the system. Use this to establish custom permission sets for different user types or job functions.

ParametersJSON Schema
NameRequiredDescriptionDefault
appliesToNoPersonas/Licenses the security role applies to
businessUnitIdNoBusiness unit ID to associate the role with (defaults to root business unit)
descriptionNoDescription of the security role
isAutoAssignedNoWhether the role is auto-assigned based on user license
isInheritedNo0 = Team privileges only, 1 = Direct User access level and Team privileges1
nameYesName of the security role
summaryOfCoreTablePermissionsNoSummary of Core Table Permissions of the Role

TDQS

A3.7/5.0
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.

create_dataverse_solutionCreate Dataverse SolutionA

Creates a new unmanaged solution in Dataverse. Solutions are containers for customizations and allow you to package, deploy, and manage custom components. Use this to create a solution before adding tables, columns, and other customizations.

ParametersJSON Schema
NameRequiredDescriptionDefault
descriptionNoDescription of the solution
friendlyNameYesFriendly name for the solution
publisherUniqueNameYesUnique name of the publisher to associate with this solution
uniqueNameYesUnique name for the solution (e.g., 'examplesolution')
versionNoVersion of the solution1.0.0.0

TDQS

A3.9/5.0
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.

create_dataverse_tableCreate Dataverse TableA

Creates a new custom table in Dataverse with the specified configuration. Use this when you need to create a new entity to store business data. Requires a solution context to be set first.

ParametersJSON Schema
NameRequiredDescriptionDefault
descriptionNoDescription of the table
displayNameYesDisplay name for the table (e.g., 'Test Table')
hasActivitiesNoWhether the table can have activities
hasNotesNoWhether the table can have notes
isAuditEnabledNoWhether auditing is enabled
isConnectionsEnabledNoWhether connections are enabled
isDocumentManagementEnabledNoWhether document management is enabled
isDuplicateDetectionEnabledNoWhether duplicate detection is enabled
isMailMergeEnabledNoWhether mail merge is enabled
isValidForQueueNoWhether records can be added to queues
ownershipTypeNoOwnership type of the tableUserOwned
primaryNameAttributeNoLogical name of the primary name attribute (will be auto-generated if not provided)
primaryNameAutoNumberFormatNoAutoNumber format for the primary name column using placeholders like 'PREFIX-{SEQNUM:4}-{RANDSTRING:3}-{DATETIMEUTC:yyyyMMdd}'. If specified, the primary name column will be created as an AutoNumber column.

TDQS

A3.9/5.0
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.

create_dataverse_teamCreate Dataverse TeamA

Creates a new team in Dataverse for organizing users and managing permissions. Teams can be owner teams (for record ownership) or access teams (for sharing records). Use this to establish groups of users who work together and need similar access levels.

ParametersJSON Schema
NameRequiredDescriptionDefault
administratorIdYesUser ID of the team administrator
azureActiveDirectoryObjectIdNoAzure AD Object ID for the team
businessUnitIdNoBusiness unit ID to associate the team with (defaults to root business unit)
delegatedAuthorizationIdNoDelegated authorization context for the team
descriptionNoDescription of the team
emailAddressNoEmail address for the team
membershipTypeNoMembership type: 0=Members and guests, 1=Members, 2=Owners, 3=Guests0
nameYesName of the team
queueIdNoDefault queue ID for the team
teamTemplateIdNoTeam template ID to associate with the team
teamTypeNoTeam type: 0=Owner, 1=Access, 2=Security Group, 3=Office Group0
transactionCurrencyIdNoCurrency ID associated with the team
yomiNameNoPronunciation of the team name in phonetic characters

TDQS

A3.7/5.0
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.

delete_dataverse_businessunitDelete Dataverse Business UnitA

Permanently deletes a business unit from Dataverse. WARNING: This action cannot be undone and may affect users and teams associated with the business unit. Use with extreme caution.

ParametersJSON Schema
NameRequiredDescriptionDefault
businessUnitIdYesUnique identifier of the business unit to delete

TDQS

A4.4/5.0
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.

delete_dataverse_columnDelete Dataverse ColumnA

Permanently deletes a column from a Dataverse table. WARNING: This action cannot be undone and will remove all data stored in this column. Use with extreme caution and only for columns that are no longer needed.

ParametersJSON Schema
NameRequiredDescriptionDefault
entityLogicalNameYesLogical name of the table
logicalNameYesLogical name of the column to delete

TDQS

A4.4/5.0
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.

delete_dataverse_optionsetDelete Dataverse Option SetA

Permanently deletes an option set from Dataverse. WARNING: This action cannot be undone and will fail if the option set is being used by any columns. Ensure no columns reference this option set before deletion.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesName of the option set to delete

TDQS

A4.4/5.0
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.

delete_dataverse_relationshipDelete Dataverse RelationshipA

Permanently deletes a relationship between Dataverse tables. WARNING: This action cannot be undone and will remove the connection between tables, including any lookup fields for One-to-Many relationships. Use with extreme caution.

ParametersJSON Schema
NameRequiredDescriptionDefault
schemaNameYesSchema name of the relationship to delete

TDQS

A4.4/5.0
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.

delete_dataverse_roleDelete Dataverse Security RoleA

Permanently deletes a security role from Dataverse. WARNING: This action cannot be undone and will fail if the role is assigned to any users or teams. Ensure the role is not in use before deletion.

ParametersJSON Schema
NameRequiredDescriptionDefault
roleIdYesID of the role to delete

TDQS

A4.4/5.0
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.

delete_dataverse_tableDelete Dataverse TableA

Permanently deletes a custom table from Dataverse. WARNING: This action cannot be undone and will remove all data in the table. Use with extreme caution and only for tables that are no longer needed.

ParametersJSON Schema
NameRequiredDescriptionDefault
logicalNameYesLogical name of the table to delete

TDQS

A4.4/5.0
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.

delete_dataverse_teamDelete Dataverse TeamA

Permanently deletes a team from Dataverse. WARNING: This action cannot be undone and will fail if the team owns records or has assigned security roles. Ensure the team is not in use before deletion.

ParametersJSON Schema
NameRequiredDescriptionDefault
teamIdYesID of the team to delete

TDQS

A4.4/5.0
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.

export_solution_schemaExport Solution SchemaA

Exports a comprehensive JSON schema of Dataverse tables, columns, relationships, and option sets. Use this to document your data model, generate diagrams, or analyze solution structure. Supports filtering by prefixes, system/custom components, and specific tables.

ParametersJSON Schema
NameRequiredDescriptionDefault
customizationPrefixesNoList of customization prefixes to include (e.g., ["new", "xyz", "its"]). If not provided and prefixOnly is true, uses solution context prefix
excludeColumnPrefixesNoList of column prefixes to exclude from export (default: ["adx_", "msa_", "msdyn_", "mspp_"])
includeAllSystemTablesNoWhether to include all system tables in the export
includeSystemColumnsNoWhether to include system columns in the export
includeSystemOptionSetsNoWhether to include system option sets in the export
includeSystemRelationshipsNoWhether to include system (non-custom) relationships in the export
outputPathNoPath where to save the schema JSON file (default: schema-export.json)
prefixOnlyNoWhether to export only tables that match the solution customization prefix (deprecated - use customizationPrefixes instead)
prettifyNoWhether to format the JSON output for readability
systemTablesToIncludeNoList of system tables to include when includeAllSystemTables is false (default: contact, account)

TDQS

A4/5.0
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.

generate_mermaid_diagramGenerate Mermaid DiagramA

Generates a Mermaid entity relationship diagram from an exported schema JSON file. Creates visual documentation of your data model with tables, columns, and relationships. Perfect for documentation, presentations, and understanding data structure.

ParametersJSON Schema
NameRequiredDescriptionDefault
includeColumnsNoWhether to include column details in the diagram
includeRelationshipsNoWhether to include relationships in the diagram
outputPathNoPath where to save the Mermaid diagram file (default: schema-diagram.mmd)
schemaPathYesPath to the exported JSON schema file
tableNameFilterNoList of table logical names to include in the diagram. If not specified, all tables will be included.

TDQS

A3.7/5.0
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.

generate_powerpages_webapi_callGenerate PowerPages WebAPI CallC

Generate PowerPages-specific API calls, JavaScript examples, and React components for Dataverse operations through PowerPages portals. Includes authentication context and portal-specific patterns.

ParametersJSON Schema
NameRequiredDescriptionDefault
baseUrlNoPowerPages site base URL (e.g., 'https://yoursite.powerappsportals.com')
countNoInclude count of records
customHeadersNoCustom headers to include in the request
dataNoData to send in request body for create/update operations
entityIdNoEntity ID for single record operations (GUID)
expandNoRelated entities to expand
filterNoOData filter expression
includeAuthContextNoInclude authentication context information
logicalEntityNameYesLogical entity name (e.g., 'cr7ae_creditcardse', 'contact') - will be automatically suffixed with 's' for PowerPages API URLs
operationYesType of operation to perform
orderbyNoOData orderby expression
requestVerificationTokenNoInclude __RequestVerificationToken placeholder for POST operations
selectNoFields to select (e.g., ['cr7ae_name', 'cr7ae_type'])
skipNoNumber of records to skip
topNoNumber of records to return

TDQS

C2.9/5.0
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.

generate_webapi_callGenerate Dataverse WebAPI CallB

Generate HTTP requests, curl commands, and JavaScript examples for Dataverse WebAPI operations. Supports all CRUD operations, associations, actions, and functions with proper OData query parameters and headers.

ParametersJSON Schema
NameRequiredDescriptionDefault
actionOrFunctionNameNoName of the action or function to call
callerIdNoMSCRMCallerID header for impersonation
countNoInclude count of records
dataNoData to send in request body for create/update operations
entityIdNoEntity ID for single record operations
entitySetNameNoEntity set name or logical entity name (e.g., 'account', 'contact') - will be automatically suffixed with 's' for Dataverse API URLs
expandNoRelated entities to expand
filterNoOData filter expression
ifMatchNoIf-Match header for conditional updates
ifNoneMatchNoIf-None-Match header
includeAuthHeaderNoInclude Authorization header placeholder in output
includeSolutionContextNoInclude current solution context in headers
operationYesType of operation to perform
orderbyNoOData orderby expression
parametersNoParameters for action/function calls
preferNoPrefer header values (e.g., ['return=representation', 'odata.include-annotations=*'])
relatedEntityIdNoRelated entity ID for associations
relatedEntitySetNameNoRelated entity set name for associations
relationshipNameNoRelationship name for associate/disassociate operations
selectNoFields to select (e.g., ['name', 'emailaddress1'])
skipNoNumber of records to skip
topNoNumber of records to return

TDQS

B3.2/5.0
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.

get_autonumber_columnGet AutoNumber ColumnC

Retrieves detailed information about an AutoNumber column including its current format, properties, and configuration.

ParametersJSON Schema
NameRequiredDescriptionDefault
columnLogicalNameYesLogical name of the AutoNumber column to retrieve
entityLogicalNameYesLogical name of the table

TDQS

C2.9/5.0
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.

get_businessunit_hierarchyGet Business Unit HierarchyB

Retrieves the complete organizational hierarchy for a specific business unit, showing parent-child relationships and the full organizational structure. Use this to understand business unit relationships and organizational structure.

ParametersJSON Schema
NameRequiredDescriptionDefault
businessUnitIdYesUnique identifier of the business unit to get hierarchy for

TDQS

B3.2/5.0
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.

get_businessunit_teamsGet Business Unit TeamsA

Retrieves all teams associated with a specific business unit, with option to include teams from subsidiary business units. Use this to understand team organization and business unit relationships.

ParametersJSON Schema
NameRequiredDescriptionDefault
businessUnitIdYesUnique identifier of the business unit
includeSubsidiaryTeamsNoWhether to include teams from subsidiary business units

TDQS

A3.7/5.0
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.

get_businessunit_usersGet Business Unit UsersA

Retrieves all users associated with a specific business unit, with option to include users from subsidiary business units. Use this to understand user assignments and organizational membership.

ParametersJSON Schema
NameRequiredDescriptionDefault
businessUnitIdYesUnique identifier of the business unit
includeSubsidiaryUsersNoWhether to include users from subsidiary business units

TDQS

A3.9/5.0
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.

get_dataverse_businessunitGet Dataverse Business UnitB

Retrieves detailed information about a specific business unit including all properties, addresses, and related information. Use this to inspect business unit configuration and hierarchy relationships.

ParametersJSON Schema
NameRequiredDescriptionDefault
businessUnitIdYesUnique identifier of the business unit to retrieve

TDQS

B3.2/5.0
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.

get_dataverse_columnGet Dataverse ColumnA

Retrieves detailed information about a specific column in a Dataverse table, including its data type, properties, and configuration settings. Use this to inspect column definitions and understand field structure.

ParametersJSON Schema
NameRequiredDescriptionDefault
entityLogicalNameYesLogical name of the table
logicalNameYesLogical name of the column to retrieve

TDQS

A3.9/5.0
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.

get_dataverse_optionsetGet Dataverse Option SetB

Retrieves detailed information about a specific option set including its metadata, options, and configuration. Use this to inspect option set definitions and understand available choices.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesName of the option set to retrieve

TDQS

B3.3/5.0
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.

get_dataverse_optionset_optionsGet Dataverse Option Set OptionsA

Retrieves all options (choices) within a specific option set, including their values, labels, descriptions, and colors. Use this to inspect the available choices in an option set and understand their configuration.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesName of the option set to get options for

TDQS

A3.5/5.0
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.

get_dataverse_publisherGet Dataverse PublisherB

Retrieves detailed information about a specific publisher including its customization prefix, option value prefix, and configuration. Use this to inspect publisher properties and understand customization settings.

ParametersJSON Schema
NameRequiredDescriptionDefault
uniqueNameYesUnique name of the publisher to retrieve

TDQS

B3.2/5.0
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.

get_dataverse_relationshipGet Dataverse RelationshipA

Retrieves detailed information about a specific relationship between Dataverse tables, including its configuration, cascade settings, and menu behavior. Use this to inspect relationship definitions and understand table connections.

ParametersJSON Schema
NameRequiredDescriptionDefault
schemaNameYesSchema name of the relationship to retrieve

TDQS

A3.7/5.0
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.

get_dataverse_roleGet Dataverse Security RoleA

Retrieves detailed information about a specific security role including its properties, business unit association, and configuration settings. Use this to inspect role definitions and understand permission structures.

ParametersJSON Schema
NameRequiredDescriptionDefault
roleIdYesID of the role to retrieve

TDQS

A3.9/5.0
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.

get_dataverse_solutionGet Dataverse SolutionB

Retrieves detailed information about a specific solution including its metadata, version, publisher details, and configuration. Use this to inspect solution properties and understand solution structure.

ParametersJSON Schema
NameRequiredDescriptionDefault
uniqueNameYesUnique name of the solution to retrieve

TDQS

B3.3/5.0
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.

get_dataverse_tableGet Dataverse TableB

Retrieves detailed information about a specific Dataverse table including its metadata, properties, and configuration. Use this to inspect table definitions and understand table structure.

ParametersJSON Schema
NameRequiredDescriptionDefault
logicalNameYesLogical name of the table to retrieve

TDQS

B3.2/5.0
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.

get_dataverse_teamGet Dataverse TeamA

Retrieves detailed information about a specific team including its properties, administrator, business unit association, and configuration settings. Use this to inspect team definitions and understand team structure.

ParametersJSON Schema
NameRequiredDescriptionDefault
teamIdYesID of the team to retrieve

TDQS

A3.9/5.0
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.

get_role_privilegesGet Dataverse Role PrivilegesB

Retrieves all privileges currently assigned to a security role, showing what permissions the role grants. Use this to audit role permissions and understand what access a role provides to users and teams.

ParametersJSON Schema
NameRequiredDescriptionDefault
roleIdYesID of the role to retrieve privileges for

TDQS

B3.2/5.0
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.

get_solution_contextGet Solution ContextA

Retrieves the currently active solution context information. Use this to check which solution is currently set for metadata operations and to verify the customization prefix being used for new components.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.2/5.0
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.

get_team_membersGet Team MembersA

Retrieves a list of all users who are members of a specific team, including their basic information and status. Use this to audit team membership and understand who has team-based access.

ParametersJSON Schema
NameRequiredDescriptionDefault
teamIdYesID of the team to retrieve members for

TDQS

A3.9/5.0
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.

list_autonumber_columnsList AutoNumber ColumnsB

Lists all AutoNumber columns in a specific table or across all tables in the environment. Helps identify existing AutoNumber implementations.

ParametersJSON Schema
NameRequiredDescriptionDefault
customOnlyNoWhether to list only custom AutoNumber columns
entityLogicalNameNoLogical name of specific table (if not provided, searches all tables)
includeManagedNoWhether to include managed AutoNumber columns

TDQS

B3.3/5.0
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.

list_dataverse_businessunitsList Dataverse Business UnitsA

Retrieves a list of business units in the Dataverse environment with filtering and sorting options. Use this to discover available business units, understand organizational hierarchy, and find specific business units by criteria.

ParametersJSON Schema
NameRequiredDescriptionDefault
filterNoOData filter expression
orderbyNoOData orderby expression
selectNoOData select expression to specify which fields to return
topNoMaximum number of business units to return (default: 50)

TDQS

A3.9/5.0
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.

list_dataverse_columnsList Dataverse ColumnsA

Retrieves a list of columns in a specific Dataverse table with filtering options. Use this to discover available fields in a table, find custom columns, or get an overview of the table structure. Supports filtering by custom/system columns and managed/unmanaged status.

ParametersJSON Schema
NameRequiredDescriptionDefault
customOnlyNoWhether to list only custom columns
entityLogicalNameYesLogical name of the table
filterNoOData filter expression
includeManagedNoWhether to include managed columns

TDQS

A3.9/5.0
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.

list_dataverse_optionsetsList Dataverse Option SetsA

Retrieves a list of option sets in the Dataverse environment with filtering options. Use this to discover available choice lists, find custom option sets, or get an overview of reusable options. Supports filtering by custom/system and managed/unmanaged status.

ParametersJSON Schema
NameRequiredDescriptionDefault
customOnlyNoWhether to list only custom option sets
filterNoOData filter expression
includeManagedNoWhether to include managed option sets
topNoMaximum number of option sets to return (default: 50)

TDQS

A3.9/5.0
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.

list_dataverse_publishersList Dataverse PublishersB

Retrieves a list of publishers in the Dataverse environment with filtering options. Use this to discover available publishers, find custom publishers for solution creation, or get an overview of publisher configurations including customization prefixes.

ParametersJSON Schema
NameRequiredDescriptionDefault
customOnlyNoWhether to list only custom publishers
topNoMaximum number of publishers to return

TDQS

B3.2/5.0
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.

list_dataverse_relationshipsList Dataverse RelationshipsA

Retrieves a list of relationships in the Dataverse environment with filtering options. Use this to discover table connections, find custom relationships, or get an overview of the data model relationships. Supports filtering by entity, relationship type, and managed/unmanaged status.

ParametersJSON Schema
NameRequiredDescriptionDefault
customOnlyNoWhether to list only custom relationships
entityLogicalNameNoFilter relationships for a specific entity
filterNoOData filter expression
includeManagedNoWhether to include managed relationships
relationshipTypeNoType of relationships to listAll

TDQS

A3.7/5.0
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.

list_dataverse_rolesList Dataverse Security RolesA

Retrieves a list of security roles in the Dataverse environment with filtering options. Use this to discover available roles, find custom roles, or get an overview of permission structures. Supports filtering by business unit, custom/system roles, and managed/unmanaged status.

ParametersJSON Schema
NameRequiredDescriptionDefault
businessUnitIdNoFilter roles by business unit ID
customOnlyNoWhether to list only custom (non-system) roles
filterNoOData filter expression
includeManagedNoWhether to include managed roles
topNoMaximum number of roles to return (default: 50)

TDQS

A3.9/5.0
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.

list_dataverse_solutionsList Dataverse SolutionsB

Retrieves a list of solutions in the Dataverse environment with filtering options. Use this to discover available solutions, find unmanaged solutions for customization, or get an overview of solution packages. Includes publisher information for each solution.

ParametersJSON Schema
NameRequiredDescriptionDefault
includeManagedNoWhether to include managed solutions
topNoMaximum number of solutions to return

TDQS

B3.2/5.0
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.

list_dataverse_tablesList Dataverse TablesA

Retrieves a list of tables in the Dataverse environment with filtering options. Use this to discover available tables, find custom tables, or get an overview of the data model. Supports filtering by custom/system tables and managed/unmanaged status.

ParametersJSON Schema
NameRequiredDescriptionDefault
customOnlyNoWhether to list only custom tables
filterNoOData filter expression
includeManagedNoWhether to include managed tables

TDQS

A3.5/5.0
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.

list_dataverse_teamsList Dataverse TeamsB

Retrieves a list of teams in the Dataverse environment with filtering options. Use this to discover available teams, find teams by business unit or type, or get an overview of team organization. Supports filtering by business unit, team type, and system-managed status.

ParametersJSON Schema
NameRequiredDescriptionDefault
businessUnitIdNoFilter teams by business unit ID
excludeDefaultNoWhether to exclude default business unit teams
filterNoOData filter expression
systemManagedOnlyNoWhether to list only system-managed teams
teamTypeNoFilter by team type: 0=Owner, 1=Access, 2=Security Group, 3=Office Group
topNoMaximum number of teams to return (default: 50)

TDQS

B3.4/5.0
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.

manage_powerpages_webapi_configManage PowerPages WebAPI ConfigurationB

Manage PowerPages WebAPI configurations and table permissions. Add/remove WebAPI access for tables, configure table permissions, and check configuration status for PowerPages portals.

ParametersJSON Schema
NameRequiredDescriptionDefault
accessTypeNoAccess type for the permissionGlobal
fieldsNoFields to expose via WebAPI (default: '*' for all fields)*
operationYesType of configuration operation to perform
permissionNameNoName for the table permission
privilegesNoPrivileges to grant
projectPathNoPath to PowerPages project (defaults to current directory)
tableNameNoLogical name of the table (e.g., 'cr7ae_creditcardses', 'contacts')
webRoleNameNoWeb role name (default: 'Authenticated Users')Authenticated Users

TDQS

B3.3/5.0
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.

remove_members_from_teamRemove Members from TeamA

Removes users from team membership, revoking their access to team-owned records and team-based permissions. Use this when users no longer need team access or are changing roles.

ParametersJSON Schema
NameRequiredDescriptionDefault
memberIdsYesArray of user IDs to remove from team
teamIdYesID of the team to remove members from

TDQS

A3.9/5.0
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.

remove_privilege_from_roleRemove Privilege from Dataverse RoleA

Removes a specific privilege from a security role, revoking the associated permissions. Use this to restrict access by removing specific operation permissions from a role.

ParametersJSON Schema
NameRequiredDescriptionDefault
privilegeIdYesID of the privilege to remove
roleIdYesID of the role to remove privilege from

TDQS

A3.7/5.0
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.

remove_role_from_teamRemove Role from TeamA

Removes a security role assignment from a team, revoking the permissions granted by that role for all team members. Use this when teams no longer need certain access levels or when restructuring team permissions.

ParametersJSON Schema
NameRequiredDescriptionDefault
roleIdYesID of the role to remove
teamIdYesID of the team to remove the role from

TDQS

A3.7/5.0
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.

remove_role_from_userRemove Role from UserA

Removes a security role assignment from a specific user, revoking the permissions granted by that role. Use this when users change roles or no longer need certain access levels.

ParametersJSON Schema
NameRequiredDescriptionDefault
roleIdYesID of the role to remove
userIdYesID of the user to remove the role from

TDQS

A3.9/5.0
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.

replace_role_privilegesReplace Dataverse Role PrivilegesA

Completely replaces all existing privileges in a security role with a new set of privileges. WARNING: This removes all current privileges and replaces them with the specified ones. Use this for comprehensive role permission restructuring.

ParametersJSON Schema
NameRequiredDescriptionDefault
privilegesYesArray of privileges to replace existing privileges with
roleIdYesID of the role to replace privileges for

TDQS

A4.2/5.0
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.

set_autonumber_seedSet AutoNumber SeedA

Sets the seed value for an AutoNumber column's sequential segment using the SetAutoNumberSeed action. This controls the starting number for future records. Note: Seed values are environment-specific and not included in solutions.

ParametersJSON Schema
NameRequiredDescriptionDefault
columnLogicalNameYesLogical name of the AutoNumber column
entityLogicalNameYesLogical name of the table containing the AutoNumber column
seedValueYesNext sequential number to use (e.g., 10000 to start from 10000)

TDQS

A3.6/5.0
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.

set_businessunit_parentSet Business Unit ParentB

Changes the parent business unit for a given business unit, effectively moving it within the organizational hierarchy. Use this to reorganize business unit structure and reporting relationships.

ParametersJSON Schema
NameRequiredDescriptionDefault
businessUnitIdYesUnique identifier of the business unit
parentBusinessUnitIdYesUnique identifier of the new parent business unit

TDQS

B3.1/5.0
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.

set_solution_contextSet Solution ContextA

Sets the active solution context for all subsequent metadata operations. When a solution context is set, all created tables, columns, relationships, and other components will be automatically added to this solution. This is required before creating any custom components.

ParametersJSON Schema
NameRequiredDescriptionDefault
solutionUniqueNameYesUnique name of the solution to set as context for subsequent operations

TDQS

A4.2/5.0
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.

update_autonumber_formatUpdate AutoNumber FormatA

Updates the AutoNumberFormat of an existing AutoNumber column. This changes how future values will be generated but does not affect existing records.

ParametersJSON Schema
NameRequiredDescriptionDefault
autoNumberFormatYesNew AutoNumber format using placeholders like "PREFIX-{SEQNUM:4}-{RANDSTRING:3}-{DATETIMEUTC:yyyyMMdd}"
columnLogicalNameYesLogical name of the AutoNumber column to update
descriptionNoNew description for the column
displayNameNoNew display name for the column
entityLogicalNameYesLogical name of the table containing the AutoNumber column
maxLengthNoNew maximum length (ensure enough room for format expansion)

TDQS

A3.9/5.0
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.

update_dataverse_businessunitUpdate Dataverse Business UnitB

Updates the properties and configuration of an existing business unit. Use this to modify business unit information, contact details, addresses, and organizational settings. Only provided fields will be updated.

ParametersJSON Schema
NameRequiredDescriptionDefault
address1_cityNoCity name for address 1
address1_countryNoCountry/region name for address 1
address1_countyNoCounty name for address 1
address1_faxNoFax number for address 1
address1_latitudeNoLatitude for address 1
address1_line1NoFirst line for address 1
address1_line2NoSecond line for address 1
address1_line3NoThird line for address 1
address1_longitudeNoLongitude for address 1
address1_nameNoName for address 1
address1_postalcodeNoZIP Code or postal code for address 1
address1_postofficeboxNoPost office box number for address 1
address1_stateorprovinceNoState or province for address 1
address1_telephone1NoMain phone number for address 1
address1_telephone2NoOther phone number for address 1
address1_telephone3NoThird telephone number for address 1
address1_upszoneNoUPS zone for address 1
address1_utcoffsetNoUTC offset for address 1
address2_cityNoCity name for address 2
address2_countryNoCountry/region name for address 2
address2_countyNoCounty name for address 2
address2_faxNoFax number for address 2
address2_latitudeNoLatitude for address 2
address2_line1NoFirst line for address 2
address2_line2NoSecond line for address 2
address2_line3NoThird line for address 2
address2_longitudeNoLongitude for address 2
address2_nameNoName for address 2
address2_postalcodeNoZIP Code or postal code for address 2
address2_postofficeboxNoPost office box number for address 2
address2_stateorprovinceNoState or province for address 2
address2_telephone1NoFirst telephone number for address 2
address2_telephone2NoSecond telephone number for address 2
address2_telephone3NoThird telephone number for address 2
address2_upszoneNoUPS zone for address 2
address2_utcoffsetNoUTC offset for address 2
businessUnitIdYesUnique identifier of the business unit to update
costCenterNoName of the business unit cost center
creditLimitNoCredit limit for the business unit
descriptionNoDescription of the business unit
divisionNameNoName of the division to which the business unit belongs
emailAddressNoEmail address for the business unit
fileAsNameNoAlternative name under which the business unit can be filed
ftpSiteUrlNoFTP site URL for the business unit
isDisabledNoWhether the business unit is disabled
nameNoName of the business unit
stockExchangeNoStock exchange on which the business is listed
tickerSymbolNoStock exchange ticker symbol for the business unit
webSiteUrlNoWebsite URL for the business unit

TDQS

B3.1/5.0
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.

update_dataverse_columnUpdate Dataverse ColumnA

Updates the properties and configuration of an existing column in a Dataverse table. Use this to modify column settings like display names, descriptions, required levels, or audit settings. Note that data type cannot be changed after creation.

ParametersJSON Schema
NameRequiredDescriptionDefault
descriptionNoNew description of the column
displayNameNoNew display name for the column
entityLogicalNameYesLogical name of the table
isAuditEnabledNoWhether auditing is enabled for this column
isValidForAdvancedFindNoWhether the column appears in Advanced Find
isValidForCreateNoWhether the column can be set during create
isValidForUpdateNoWhether the column can be updated
logicalNameYesLogical name of the column to update
requiredLevelNoNew required level of the column

TDQS

A3.9/5.0
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.

update_dataverse_optionsetUpdate Dataverse Option SetA

Updates an existing option set by modifying its properties and managing its options. Use this to add new choices, update existing ones, remove obsolete options, or change the option set's display name and description. Changes affect all columns using this option set.

ParametersJSON Schema
NameRequiredDescriptionDefault
addOptionsNoNew options to add to the option set
descriptionNoNew description of the option set
displayNameNoNew display name for the option set
nameYesName of the option set to update
removeOptionsNoValues of options to remove from the option set
updateOptionsNoExisting options to update

TDQS

A3.9/5.0
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.

update_dataverse_roleUpdate Dataverse Security RoleB

Updates the properties and configuration of an existing security role. Use this to modify role settings like name, description, auto-assignment behavior, or inheritance settings without changing the actual privileges.

ParametersJSON Schema
NameRequiredDescriptionDefault
appliesToNoNew personas/licenses the security role applies to
descriptionNoNew description of the security role
isAutoAssignedNoWhether the role is auto-assigned based on user license
isInheritedNo0 = Team privileges only, 1 = Direct User access level and Team privileges
nameNoNew name of the security role
roleIdYesID of the role to update
summaryOfCoreTablePermissionsNoSummary of Core Table Permissions of the Role

TDQS

B3.4/5.0
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.

update_dataverse_tableUpdate Dataverse TableA

Updates the properties and configuration of an existing Dataverse table. Use this to modify table settings like display names, descriptions, or feature enablement (activities, notes, auditing, etc.). Changes are published automatically.

ParametersJSON Schema
NameRequiredDescriptionDefault
descriptionNoNew description of the table
displayCollectionNameNoNew display collection name for the table
displayNameNoNew display name for the table
hasActivitiesNoWhether the table can have activities
hasNotesNoWhether the table can have notes
isAuditEnabledNoWhether auditing is enabled
isConnectionsEnabledNoWhether connections are enabled
isDocumentManagementEnabledNoWhether document management is enabled
isDuplicateDetectionEnabledNoWhether duplicate detection is enabled
isMailMergeEnabledNoWhether mail merge is enabled
isValidForQueueNoWhether records can be added to queues
logicalNameYesLogical name of the table to update

TDQS

A3.9/5.0
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.

update_dataverse_teamUpdate Dataverse TeamB

Updates the properties and configuration of an existing team. Use this to modify team settings like name, description, administrator, or other team properties without changing team membership.

ParametersJSON Schema
NameRequiredDescriptionDefault
administratorIdNoNew administrator user ID
azureActiveDirectoryObjectIdNoAzure AD Object ID for the team
delegatedAuthorizationIdNoDelegated authorization context for the team
descriptionNoNew description of the team
emailAddressNoEmail address for the team
membershipTypeNoMembership type: 0=Members and guests, 1=Members, 2=Owners, 3=Guests
nameNoNew name of the team
queueIdNoDefault queue ID for the team
teamIdYesID of the team to update
teamTemplateIdNoTeam template ID to associate with the team
teamTypeNoTeam type: 0=Owner, 1=Access, 2=Security Group, 3=Office Group
transactionCurrencyIdNoCurrency ID associated with the team
yomiNameNoPronunciation of the team name in phonetic characters

TDQS

B3.2/5.0
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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 71 tool updatesv1.0.0
    • First observedadd_members_to_team
    • First observedadd_privileges_to_role
    • First observedassign_role_to_team
    • First observedassign_role_to_user
    • First observedclear_solution_context
    • First observedconvert_owner_team_to_access_team
    • First observedconvert_to_autonumber
    • First observedcreate_autonumber_column
    • First observedcreate_dataverse_businessunit
    • First observedcreate_dataverse_column
    • First observedcreate_dataverse_optionset
    • First observedcreate_dataverse_publisher
    • First observedcreate_dataverse_relationship
    • First observedcreate_dataverse_role
    • First observedcreate_dataverse_solution
    • First observedcreate_dataverse_table
    • First observedcreate_dataverse_team
    • First observeddelete_dataverse_businessunit
    • First observeddelete_dataverse_column
    • First observeddelete_dataverse_optionset
    • First observeddelete_dataverse_relationship
    • First observeddelete_dataverse_role
    • First observeddelete_dataverse_table
    • First observeddelete_dataverse_team
    • First observedexport_solution_schema
    • First observedgenerate_mermaid_diagram
    • First observedgenerate_powerpages_webapi_call
    • First observedgenerate_webapi_call
    • First observedget_autonumber_column
    • First observedget_businessunit_hierarchy
    • First observedget_businessunit_teams
    • First observedget_businessunit_users
    • First observedget_dataverse_businessunit
    • First observedget_dataverse_column
    • First observedget_dataverse_optionset
    • First observedget_dataverse_optionset_options
    • First observedget_dataverse_publisher
    • First observedget_dataverse_relationship
    • First observedget_dataverse_role
    • First observedget_dataverse_solution
    • First observedget_dataverse_table
    • First observedget_dataverse_team
    • First observedget_role_privileges
    • First observedget_solution_context
    • First observedget_team_members
    • First observedlist_autonumber_columns
    • First observedlist_dataverse_businessunits
    • First observedlist_dataverse_columns
    • First observedlist_dataverse_optionsets
    • First observedlist_dataverse_publishers
    • First observedlist_dataverse_relationships
    • First observedlist_dataverse_roles
    • First observedlist_dataverse_solutions
    • First observedlist_dataverse_tables
    • First observedlist_dataverse_teams
    • First observedmanage_powerpages_webapi_config
    • First observedremove_members_from_team
    • First observedremove_privilege_from_role
    • First observedremove_role_from_team
    • First observedremove_role_from_user
    • First observedreplace_role_privileges
    • First observedset_autonumber_seed
    • First observedset_businessunit_parent
    • First observedset_solution_context
    • First observedupdate_autonumber_format
    • First observedupdate_dataverse_businessunit
    • First observedupdate_dataverse_column
    • First observedupdate_dataverse_optionset
    • First observedupdate_dataverse_role
    • First observedupdate_dataverse_table
    • First observedupdate_dataverse_team
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.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.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • PowerPlatform MCP

    michsob
    A
    license
    B
    quality
    C
    maintenance
    A Model Context Protocol (MCP) server that provides intelligent access to PowerPlatform/Dataverse entities and records. This tool offers context-aware assistance, entity exploration and metadata access.
    38
    68
    42
    MIT

  • Dataverse MCP Server

    WizspDemo
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables comprehensive management of Microsoft Dataverse environments, including schema operations for tables, columns, and relationships through the Dataverse Web API. It also supports solution management, security role configuration, and the generation of WebAPI calls and Mermaid ERD diagrams.
    MIT

  • Dataverse MCP Server

    WizspDemo
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables comprehensive schema and solution management for Microsoft Dataverse, including operations for tables, columns, relationships, and security roles via the Dataverse Web API. It also supports PowerPages configuration, automated WebAPI call generation, and schema visualization through Mermaid ERD diagrams.
    MIT

  • MCP Dataverse Server

    carlosarmenta75
    F
    license
    Not graded
    quality
    D
    maintenance
    Enables CRUD operations and schema exploration on Microsoft Dataverse databases using service principal authentication. It allows users to query records with OData filters, manage table entries, and retrieve metadata through a standardized MCP interface.
    -

Latest Blog Posts

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