Dynamics 365 Finance & Operations MCP Server

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 key behavioral traits: the simplified filtering limitation ('only supports "eq" operations with wildcard patterns'), pagination behavior (top/skip parameters), and return format ('Dictionary with query results including data array, count, and pagination info'). It doesn't mention rate limits, authentication needs, or error handling, but covers the core operational behavior well.

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

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

The description is well-structured with clear sections (Args, Returns, Note) and front-loaded purpose. Every sentence adds value: the opening statement defines purpose, parameter explanations are necessary given schema gaps, and the note provides crucial limitations. It could be slightly more concise in the filter examples but remains efficient for a complex tool.

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

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

For a complex query tool with 9 parameters, 0% schema coverage, no annotations, and no output schema, the description provides substantial context. It explains parameters thoroughly, describes return format, and notes limitations. It doesn't cover authentication, error cases, or performance characteristics, but given the schema/annotation gaps, it does a strong job of making the tool usable.

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

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

With 0% schema description coverage for 9 parameters, the description must compensate, which it does excellently. It provides detailed semantic explanations for all key parameters: entity_name (with examples), filter (with syntax rules and multiple examples), order_by, top (including default value), skip, count, expand, and profile. Each parameter's purpose and usage is clearly explained beyond what the bare schema provides.

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

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

The description clearly states the tool's purpose: 'Query D365FO data entities with simplified filtering capabilities.' It specifies the verb ('query'), resource ('D365FO data entities'), and key capability ('simplified filtering'), distinguishing it from siblings like d365fo_get_entity_record (single record retrieval) or d365fo_execute_sql_query (SQL-based queries).

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

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

The description provides explicit usage guidance: 'For complex queries, retrieve data first and filter programmatically.' This clearly indicates when NOT to use this tool (complex queries) and suggests an alternative approach, helping the agent choose between this simplified query tool and other data retrieval methods among siblings.

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