Skip to main content
Glama
ryanmichaeljames

Dataverse MCP Server

dataverse_retrieve_unpublished

Read-onlyIdempotent

Read the unpublished draft of a Dataverse customization record (form, view, app, web resource) to confirm your recent edits, avoiding accidental overwrites from stale published data.

Instructions

Read the UNPUBLISHED (draft) definition of one customization record.

A normal GET — and therefore dataverse_get_form, dataverse_get_view and dataverse_get_web_resource — returns the PUBLISHED row. Writes such as dataverse_set_formxml, dataverse_add_form_control, dataverse_update_view and dataverse_add_view_column save to the draft, so after any of them the published read is stale until dataverse_publish_customizations runs. Call this tool to read back what you just wrote; reading the published row and then editing it can silently clobber your own unpublished changes.

Supported entity_set_name values: 'savedqueries' (views), 'systemforms' (forms), 'appmodules', 'webresourceset'. Dataverse accepts the RetrieveUnpublished message for only certain customization entity types, and sitemap is NOT one of them — a sitemap draft cannot be read this way, so do not go looking for it. Ordinary data tables such as 'accounts' have no unpublished layer at all.

Returns one record, not a list. By default a small projection is returned with the large XML/binary columns held back (formxml, fetchxml, layoutxml, content) — pass select to ask for them explicitly, e.g. select=['formid','name','formxml']. select is honoured and validated: an unknown column name comes back as an HTTP 400 naming the property.

IMPORTANT — the returned column set is NOT the set you asked for, and it differs in BOTH directions.

  • FEWER: unlike a plain GET, RetrieveUnpublished omits a requested column whose value is NULL instead of returning it as null. A missing key means "this column is null", NOT "this column does not exist".

  • MORE: the platform also returns columns you never requested. It is an open-ended set, not one known extra — _organizationid_value comes back on every entity set, and a narrow select on 'systemforms' also returned objecttypecode and type. Treat any unrequested column as possible. So never assume returned set == requested set, and do NOT diff requested against returned to detect a mistyped select column: nulls vanish from that diff and platform extras pollute it. The reliable signal for a bad column name is Dataverse's own HTTP 400 "Could not find a property named ''", surfaced through the error envelope.

If the record has no unpublished changes, the draft and the published row are identical, which is the expected result rather than an error.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

Beyond annotations (readOnlyHint, openWorldHint, idempotentHint), the description discloses critical behaviors: the returned column set is NOT the requested set, NULL-valued columns are omitted, unexpected extra columns like _organizationid_value appear, and invalid column names produce an HTTP 400. It also notes that a record with no changes returns a draft identical to published. This is richly transparent and aligns with the annotations.

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 long but every paragraph earns its place, with a clear first-line definition, bold IMPORTANT warnings, and explicit do/don't guidance. It front-loads the core purpose and then layers specialized details, making it easy for an agent to scan. No redundant fluff or repetition of annotation values.

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 covers the full decision context: when to use, expected return shape (one record), select projection caveats, error signaling, and the identity case (no changes). It also names supporting list tools to find record IDs. Given the output schema exists and annotations are present, this description is complete.

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

Parameters5/5

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

The context reports 0% top-level schema coverage because the only top-level property ('params') lacks a description, but the nested schema (RetrieveUnpublishedInput) provides detailed descriptions for all four real parameters. The tool description adds even more critical nuance about select behavior: default projection excludes large XML/binary columns, NULL columns vanish, and unrequested columns may appear. It also clarifies entity_set_name irregulars and the sitemap limitation, going beyond the schema.

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 opens with a specific verb and resource: 'Read the UNPUBLISHED (draft) definition of one customization record.' It distinguishes itself from sibling read tools by explicitly stating that normal GETs and dataverse_get_form/view/web_resource return the PUBLISHED row, while this tool reads the draft. This is a precise purpose statement with clear sibling differentiation.

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?

Usage is explicitly tied to the write-then-read workflow: 'Call this tool to read back what you just wrote' after describing how write tools save to draft. It also states when NOT to use it: sitemap is not supported, ordinary data tables have no unpublished layer, and reading the published row can 'silently clobber your own unpublished changes.' This is model guidance on when and when-not.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ryanmichaeljames/dataverse-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server