Skip to main content
Glama
Dynamics 365 MCP Server

Dynamics 365 MCP Server

by Kenny-666

list_crm_charts

Read-onlyIdempotent

Retrieve saved or unpublished system and personal charts for a Dynamics 365 entity to inspect available CRM visualizations.

Instructions

List bounded system saved/unpublished or personal charts for an entity.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "scope": "<scope>",
      "entity_logical_name": "<entity_logical_name>"
    },
    "name": "list_crm_charts"
  }
}

Input Schema

NameRequiredDescriptionDefault
topNo
scopeYes
entity_logical_nameYes
environment_profileNoOptional named environment profile for this call; omit to use the configured default.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.1.2

TDQS

C2.9/5.0
Behavior3/5

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

Annotations already establish readOnly, idempotent and non-destructive behavior, so the description's added burden is small but real: it discloses that system charts include 'saved/unpublished' items, which is non-obvious status information. However, 'bounded' is never defined (a cap? pagination?) and nothing is said about ordering or default limits, leaving a key behavioral trait opaque.

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?

A single front-loaded sentence with no filler or redundancy. It is efficient, though the terseness comes at the cost of the clarity gaps noted elsewhere rather than being purely a virtue.

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 four-parameter tool with no output schema, an agent still lacks the return shape (chart names? ids? types?), the meaning of 'bounded', default/none behavior for top, and how the two required parameters must be combined. Annotations cover safety only, so the description should have done more.

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

Parameters2/5

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

Schema description coverage is only 25%, with only environment_profile documented, so the description needs to carry the load for scope, entity_logical_name and top. It weakly gestures at scope ('system ... or personal' and 'for an entity') but says nothing about the top parameter, its 1-100 range, or whether results are truncated by default.

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 names a specific verb and resource ('List ... charts') and adds scope qualifiers ('system saved/unpublished or personal ... for an entity'), which clearly separates it from the singular get_crm_chart and the mutating change_crm_chart siblings. It stops short of 5 because the qualifier 'bounded' is unexplained and the exact scope semantics remain ambiguous.

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?

There is no when-to-use guidance: nothing says to call this before get_crm_chart, or how scope values map to which chart set an agent should retrieve. The only implied usage is that it is a listing call, which the agent could already infer from the name.

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

Deploy Server

Other Tools