Skip to main content
Glama
Kenny-666

Dynamics 365 MCP Server

by Kenny-666

d365_plugin_assemblies_query

Read-only

Query Dynamics 365/Dataverse plugin assembly metadata with optional exact ID or name filters, returning bounded results without content, credentials, or configuration.

Instructions

List native plugin assembly metadata with optional exact ID/name filters. Excludes content, credentials and configuration; bounded completeness is explicit. Does not invoke the .NET reader.

Input Schema

NameRequiredDescriptionDefault
topNo
nameNo
assemblyIdNo
assembly_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

B3.4/5.0
Behavior4/5

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

With readOnlyHint already declaring the safety profile, the description adds real value: it names what is deliberately excluded from results (content, credentials, configuration) and flags that completeness is bounded. That tells the agent results may be truncated, which annotations alone would not convey.

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

Conciseness4/5

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

Three tight sentences with the core purpose front-loaded and no filler. The phrase 'bounded completeness is explicit' is slightly abstract/self-referential but still earns its place by flagging truncation.

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?

A read-only list tool with no output schema, so the description needn't explain return values. It covers exclusions and bounded results but leaves the pagination/limit parameter and the alias duplication unexplained, which matters for a 4-param tool with zero schema documentation.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must carry parameter meaning. It conveys that ID/name filters are exact-match, which is useful, but says nothing about the `top` limit, its 500 maximum, or the assemblyId/assembly_id alias pair — half the parameters remain opaque.

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?

States a specific verb and resource: 'List native plugin assembly metadata'. The clause 'Does not invoke the .NET reader' implicitly distinguishes it from the d365_plugin_assembly_inspect sibling, so an agent can tell which one to reach for, though the sibling is not named outright.

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?

Usage context is only implied. The exclusion of content/credentials/configuration and the note about the .NET reader hint that this is for lightweight metadata listing rather than full inspection, but there is no explicit 'use X instead when you need Y' routing to d365_plugin_assembly_inspect.

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