Skip to main content
Glama
Kenny-666

Dynamics 365 MCP Server

by Kenny-666
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

search_records_by_odata

Query Dynamics 365/Dataverse records using OData filters, ordering, and bounded paging to get precise results and resume large result sets with continuation.

Instructions

Query records using OData with explicit state policy, stable ordering and bounded server-driven paging. Defaults to one page and legacy statecode=0 where valid; all adds no implicit state filter. Returns completeness and continuation.

Input Schema

NameRequiredDescriptionDefault
topNoNative query limit, independent of per-call max_records. Cannot be combined with page_size.
expandNoOData navigation expansion. Nested child collections are not independently auto-paged.
filterNoOData filter expression
selectNoComma-separated list of attributes to retrieve
orderbyNoComma-separated property paths with optional asc/desc. Primary key is appended as a tie-breaker where available.
fetch_allNoFollow server paging up to max_records/max_pages. Default false returns one page.
max_pagesNoMaximum server pages read per call, default 10, when fetch_all=true.
page_sizeNoRequested server page size, default 500. Cannot be combined with top. FetchXML count is preserved unless the same value is supplied.
state_modeNolegacy preserves valid implicit statecode=0 filtering; all adds no state filter; values uses state_values validated against this table.
max_recordsNoMaximum records returned in this call, default 5000. Remaining records can be resumed with continuation.
continuationNoOpaque cursor from a previous result; valid for five minutes in this server connection. Resumes saved query and buffered records.
state_valuesNoExplicit numeric state values; requires state_mode=values.
collection_nameYesEntitySetName (Web API collection name), e.g. accounts; use table metadata rather than guessing a plural name.
formatted_valuesNoInclude formatted labels and display values returned by CRM.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden and discloses non-obvious defaults: one page by default, legacy statecode=0 filtering where valid, no implicit state filter for all, stable ordering, bounded paging, and returned completeness/continuation. It does not explicitly state read-only safety, permission requirements, or rate limits, though the query verb strongly implies 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 two sentences, front-loaded with the tool’s purpose, and dense with relevant behavioral defaults. It avoids repeating schema parameter descriptions and each clause contributes useful 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?

For a 14-parameter query tool with no annotations and no output schema, the description covers key state and paging behavior and mentions return completeness/continuation. However, it leaves gaps around explicit read-only safety, permissions, error behavior, and fuller return-shape context.

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 description coverage is 100%, so baseline is 3. The description adds useful semantic context beyond the schema by explaining the state policy distinction between legacy and all, and by summarizing the one-page default and continuation behavior.

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 states a specific verb and resource: querying records using OData, with scope around state policy, stable ordering, and bounded paging. It implicitly distinguishes itself from FetchXML-based siblings by naming OData, but it does not explicitly compare itself to any sibling tool.

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 OData phrasing implies when this tool is appropriate, but there is no explicit guidance on when to choose it over query_by_fetchxml, preview_fetchxml_query, or get_record_by_id. It also lacks stated exclusions or alternative-selection rules.

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