Skip to main content
Glama
jukkan

xrm-mcp

by jukkan
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

xrm-mcp

A minimal MCP server that gives AI coding agents (Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI) clean read + careful write access to Microsoft Dataverse / XRM environments via the Dataverse Web API v9.2.

xrm-mcp-300px

Why this exists: Microsoft ships its own Dataverse MCP server, but it requires Power Platform admin setup, Managed Environments, and Copilot Credits per call. xrm-mcp is a drop-in alternative that works with any Dataverse environment using your existing Azure CLI or Microsoft account. Read more →

Features

  • No Microsoft MCP billing — calls the Dataverse Web API directly, no Copilot Credits consumed

  • No admin toggles — works with any Dataverse environment you can log into

  • No Managed Environment required — standard environments work fine

  • No per-environment setup — org_url is a parameter on every tool call

  • Multi-tenant by design — connect to multiple orgs in the same session, with per-environment identity caching so switching between tenants doesn't require re-authenticating each time

  • Azure CLI + MSAL auth — tries az first, falls back to interactive device flow

  • 8 MCP tools — ping, find/list tables, describe schema, query, create, update, upsert

Related MCP server: dataverse-mcp-server

Installation

Install via pipx (recommended):

pipx install git+https://github.com/jukkan/xrm-mcp.git

Or via pip:

pip install git+https://github.com/jukkan/xrm-mcp.git

Usage

Configuring your AI agent

Add xrm-mcp to your agent's MCP configuration.

Claude Desktop / Claude Code (~/.claude/claude_desktop_config.json or .mcp.json):

{
  "mcpServers": {
    "xrm-mcp": {
      "command": "xrm-mcp"
    }
  }
}

GitHub Copilot (VS Code) — add to .vscode/mcp.json in your workspace:

{
  "servers": {
    "xrm-mcp": {
      "type": "stdio",
      "command": "xrm-mcp"
    }
  }
}

Once configured, pass your environment URL with every request and the agent takes it from there:

"Show me all project records from https://myorg.crm4.dynamics.com created in the last 30 days"

Running the server manually

xrm-mcp

The server uses FastMCP and communicates over stdin/stdout (stdio transport).

Authentication

XRM MCP attempts authentication in the following order:

  1. Azure CLI — if az is available and logged in

  2. MSAL device flow — interactive browser-based login

Tokens are cached at ~/.xrm-mcp/cache.json.

If you work across multiple tenants (e.g. your own production environment, demo environments, and customer tenants), XRM MCP remembers which identity last worked for each org_url in ~/.xrm-mcp/identity_cache.json and prefers it on the next call — so switching tenants doesn't depend on which az account happens to be active. If a call gets a 401/403, that org's cached identity is cleared automatically and the error message tells you to just retry, which re-discovers a working identity.

To re-authenticate, delete ~/.xrm-mcp/cache.json or use az login. To reset which identity is used for a specific org, delete its entry from ~/.xrm-mcp/identity_cache.json.

Testing authentication manually

python -m xrm_mcp.auth https://yourorg.crm4.dynamics.com

MCP Tools

Read Tools

ping(org_url)

  • Verify connectivity and authentication to a Dataverse environment

  • Returns: status, org_url, user_id, business_unit_id, org_id, auth_method, tenant_id

  • Call this first when connecting to a new environment; auth_method/tenant_id let you confirm which identity answered the call

find_table(org_url, name)

  • Search for a table by display name or partial logical name

  • Use when the user says "hour entries" and you need the exact logical name

  • Returns all matching tables sorted by exact display name match first

list_tables(org_url, search="", custom_only=True, prefix="", exclude_ms_prefixes=True)

  • List Dataverse tables, defaulting to custom entities only

  • custom_only=True — only return custom entities (default)

  • prefix="na_" — filter to a specific publisher prefix

  • exclude_ms_prefixes=False — include Microsoft solution tables (msdyn_, adx_, etc.)

  • Returns: logical_name, display_name, entity_set_name, is_custom, description

describe_table(org_url, table)

  • Get columns, types and descriptions for a Dataverse table

  • Call this before querying when you need exact column names for $select or $filter

  • Returns: table_name, columns with metadata

query_records(org_url, table, select="", filter="", top=100, orderby="")

  • Query records from a table using OData filter syntax

  • Returns: {count, records}

  • Top is capped at 5000

  • select is validated against real column names before querying; an invalid column raises a clear error naming it, instead of silently returning every column

Write Tools

create_record(org_url, table, data)

  • Create a single record

  • Returns: {id}

update_record(org_url, table, record_id, data)

  • Update specific fields on an existing record

  • Returns: {success, id}

upsert_record(org_url, table, alternate_key, alternate_value, data)

  • Create or update a record using an alternate key (for sync/import scenarios)

  • Returns: {success, alternate_key, alternate_value}

Example Usage

See CLAUDE.md for detailed agent usage examples and WHY.md for how this compares to Microsoft's own Dataverse MCP server.

Requirements

  • Python 3.10+

  • Azure CLI (optional, for az authentication)

  • Access to a Dataverse / Dynamics 365 environment

Dependencies

  • fastmcp >= 0.1.0, < 3

  • msal >= 1.28.0

  • httpx >= 0.27.0

Development

Clone the repository:

git clone https://github.com/jukkan/xrm-mcp.git
cd xrm-mcp

Install in development mode:

pip install -e .

License

MIT

Contributing

Contributions welcome! Please open an issue or pull request.

Available Tools

8 tools
create_recordC

Create a single record in an XRM table.

ParametersJSON Schema
NameRequiredDescriptionDefault
dataYesDictionary of logical column names to values
tableYesThe logical name of the table
org_urlYesThe Dataverse organization URL

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden but only states 'create a single record'. It omits details on behavior on conflicts, error handling, authentication needs, rate limits, or side effects. The output schema exists but is not described here, so transparency is minimal.

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, front-loaded sentence of 10 words with no superfluous content. It is highly concise.

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 that this is a mutation tool with 3 required parameters and an output schema (not shown), the description lacks details on return values, error states, data format requirements, and validation rules. It feels incomplete for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage for all parameters, so the description does not need to add more. The baseline score of 3 is appropriate as the description adds no further semantic value beyond the 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 'create' and the resource 'record in an XRM table'. It is specific enough to distinguish from sibling tools like 'update_record' and 'upsert_record', though it does not explicitly differentiate them.

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 (e.g., 'upsert_record' for creation or update). There is no mention of prerequisites, when not to use, or context for its usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

describe_tableA

Get columns, types and descriptions for an XRM table.

Call this before querying when you need to know column names for $select or $filter.

ParametersJSON Schema
NameRequiredDescriptionDefault
tableYesThe logical name of the table (e.g., account, cr123_hourentry)
org_urlYesThe Dataverse organization URL

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4/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 correctly implies a read-only operation ('Get columns, types and descriptions'). However, it does not disclose potential side effects, rate limits, or authorization requirements. The output schema exists, which helps, but more behavioral detail would be beneficial.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description consists of two concise sentences. It is front-loaded with the primary action and provides usage guidance in the second sentence. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (2 parameters, both well-documented) and the presence of an output schema, the description is sufficiently complete. It adds usage context beyond the schema, making it effective for 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?

Schema description coverage is 100%, so the baseline is 3. The description adds an example for the 'table' parameter ('e.g., account, cr123_hourentry') and implies the purpose of parameters through context. It does not add extensive meaning beyond the schema but is adequate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Get columns, types and descriptions for an XRM table.' This is a specific verb+resource, and it clearly distinguishes from sibling tools like list_tables (which lists table names) and find_table (which searches for tables).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly advises when to use this tool: 'Call this before querying when you need to know column names for $select or $filter.' It provides clear context for usage, though it does not mention when not to use it or name alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

find_tableA

Search for a table by display name or partial logical name.

Use this when the user gives a friendly name like 'hour entry' or 'hours' and you don't know the exact logical name. Returns all candidate matches from this specific environment — do not use workspace files or project notes to infer table names.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesThe search term (display name or partial logical name)
org_urlYesThe Dataverse organization URL

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/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 'Returns all candidate matches from this specific environment', implying a read-only search. Could be more explicit about no side effects, but adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose, no wasted words. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description sufficiently covers purpose and usage context given the simple parameter set and presence of an output schema. No missing information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline 3. The description does not add any additional information about the parameters beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'search' and resource 'table', with clear scope ('by display name or partial logical name'). It differentiates from siblings like list_tables and describe_table by specifying the lookup method.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use with examples ('hour entry', 'hours') and a negative directive ('do not use workspace files or project notes'), which clearly guides the agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_tablesA

Lists Dataverse tables. Defaults to custom tables only, excluding Microsoft-prefixed solution tables (msdyn_, msfp_, adx_ etc).

Use prefix='na_' to filter to a specific publisher. Use exclude_ms_prefixes=False to see all custom tables.

ParametersJSON Schema
NameRequiredDescriptionDefault
prefixNoOptional prefix to filter logical names (e.g., "cr123_")
searchNoOptional search term to filter tables
org_urlYesThe Dataverse organization URL (e.g., https://yourorg.crm4.dynamics.com)
custom_onlyNoIf True, only return custom entities (default: True)
exclude_ms_prefixesNoIf True, exclude Microsoft-prefixed solution tables (default: True)

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries the full burden. It clearly discloses default filtering behaviors (custom only, excluding Microsoft prefixes) and how to modify them. No destructive or authentication details are needed for a read-only list 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?

Two highly informative sentences with no filler. The default behavior is stated first, followed by two specific usage hints. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 5 parameters and an output schema, the description covers defaults and filtering options adequately. It could mention pagination or rate limits, but this is not critical for a read-only list tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, providing baseline 3. The description adds meaning beyond the schema with concrete examples like 'na_' for prefix and mentions specific prefixes (msdyn_, msfp_, adx_). This helps agents understand usage beyond parameter types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool 'Lists Dataverse tables' with specific defaults (custom tables only, excluding Microsoft prefixes). It clearly identifies the resource and action, distinguishing from siblings like 'find_table' which searches for a specific table.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides guidance on using prefix filtering ('Use prefix='na_' to filter') and the exclude_ms_prefixes parameter ('Use exclude_ms_prefixes=False to see all custom tables'). However, it does not explicitly compare to alternatives like 'find_table' or 'describe_table' for related use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pingA

Test connectivity to an XRM/Dataverse environment and verify authentication.

Call this first to verify your setup and connection to the Dataverse environment.

ParametersJSON Schema
NameRequiredDescriptionDefault
org_urlYesThe Dataverse organization URL (e.g., https://yourorg.crm4.dynamics.com)

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.3/5.0
Behavior4/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 indicates the tool tests connectivity and authentication, implying no destructive side effects. The output schema (context: has output schema) likely details the response, so the description is sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with no wasted words. The key purpose and usage advice are front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple single-parameter tool with output schema available, the description fully captures the tool's purpose and recommendation. No additional information 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% coverage with a description for 'org_url'. The tool description does not add new semantic info beyond what the schema already provides, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Test connectivity to an XRM/Dataverse environment and verify authentication,' which is a specific verb+resource. It distinguishes from sibling tools (data manipulation or metadata queries) by focusing on connectivity testing.

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 says 'Call this first to verify your setup,' providing explicit usage context. However, it does not mention when not to use it or alternatives, though its purpose is naturally limited.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

query_recordsA

Query records from an XRM/Dataverse table.

ParametersJSON Schema
NameRequiredDescriptionDefault
topNoMaximum records to return (hard cap 5000)
tableYesThe logical name (e.g., account, cr123_hourentry)
filterNoOData $filter expression
selectNoComma-separated column names to retrieve
orderbyNoOData $orderby expression
org_urlYesThe Dataverse organization URL

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.7/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description lacks any behavioral details such as authentication requirements, rate limits, pagination behavior, or error handling. It does not add value beyond 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 a single sentence with no waste. It front-loads the key action and resource, making it efficient for an AI agent 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 that the tool has an output schema and all parameters are documented, the description is minimally adequate. However, it lacks context about typical usage patterns, such as how to construct OData filter expressions or handle pagination beyond the top parameter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, meaning all parameters are described in the schema. The description does not add any additional meaning beyond what is already in the schema, 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 action (query) and resource (records from a table). It distinguishes itself from sibling tools like create_record, update_record, upsert_record (mutations) and describe_table, find_table, list_tables (metadata).

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 implies usage for retrieving data, but does not explicitly state when not to use it or provide alternatives. However, the context of sibling tools makes it clear that this is for reading records.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_recordB

Update fields on a single existing XRM record.

ParametersJSON Schema
NameRequiredDescriptionDefault
dataYesDictionary of fields to change (only the fields to update)
tableYesThe logical name of the table
org_urlYesThe Dataverse organization URL
record_idYesThe GUID of the record to update

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.3/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description does not disclose behavioral traits such as whether the tool performs a partial update, overwrites all fields, or returns the updated record. This 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that efficiently conveys the tool's purpose without any 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 the presence of an output schema and clear parameter descriptions in the schema, the description provides adequate but minimal context. However, it lacks behavioral details and usage 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 coverage is 100%, so the input schema already describes each parameter. The description adds no extra meaning beyond the schema, meeting the baseline.

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 'Update' and the resource 'fields on a single existing XRM record', distinguishing it from sibling tools like create_record, upsert_record, and query_records.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives like create_record or upsert_record. The description does not mention preconditions or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

upsert_recordA

Create or update a record matched by an alternate key column.

Use this for sync/import scenarios where you don't have the record GUID.

ParametersJSON Schema
NameRequiredDescriptionDefault
dataYesDictionary of fields to set
tableYesThe logical name of the table
org_urlYesThe Dataverse organization URL
alternate_keyYesThe logical name of the alternate key column
alternate_valueYesThe value to match

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.2/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 discloses that the tool creates or updates a record (a mutation), but does not mention potential side effects, return behavior, or conflict resolution. This is adequate but leaves some uncertainty.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description consists of two concise sentences. The first sentence immediately states the purpose, and the second provides usage guidance. No extraneous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (5 required params, nested objects, output schema present), the description is lean but functional. It covers the core purpose and usage context. However, it could be improved by noting that this is a mutation and what happens on conflict or missing 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%, so the baseline is 3. The description adds contextual value by mentioning 'sync/import scenarios', but it does not provide additional semantics for individual parameters beyond what the schema already describes.

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 'Create or update' and the resource 'record', and specifies the method 'matched by an alternate key column'. This distinguishes it from sibling tools like create_record and update_record, which operate on GUIDs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use this for sync/import scenarios where you don't have the record GUID', providing clear guidance on when to use this tool versus alternatives that require a GUID.

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.

  1. 8 tool updatesv0.1.1
    • First observedcreate_record
    • First observeddescribe_table
    • First observedfind_table
    • First observedlist_tables
    • First observedping
    • First observedquery_records
    • First observedupdate_record
    • First observedupsert_record
Deploy Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Scored across 8 tools

Disambiguation5/5

Each tool targets a distinct operation (CRUD, metadata queries, connectivity test) with no functional overlap, making it easy for an agent to select the correct one.

Naming Consistency4/5

Most tools follow a clear verb_noun pattern (create_record, query_records, etc.), but ping uses a single verb, which is a minor inconsistency.

Tool Count5/5

The tool count of 8 is well-scoped for a Dataverse MCP server, covering essential operations without unnecessary bloat.

Completeness3/5

The tool set covers creation, update, query, and metadata, but lacks a delete_record tool and a direct get-by-ID tool, which may cause agent failures in typical workflows.

Maintenance

ActivityStale
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • dataverse-mcp-server

    rededis
    A
    license
    A
    quality
    A
    maintenance
    MCP server for Microsoft Dataverse API with safe-by-default configuration. Works with any Dataverse / Dynamics 365 environment.
    23
    24
    7
    MIT

  • odatav4-mcp

    singlebarrel
    F
    license
    Not graded
    quality
    C
    maintenance
    An MCP server for OData v4 endpoints, especially Microsoft Dataverse/Dynamics 365, enabling authentication, schema discovery, querying, CRUD, and more via natural language.
    -