business-central-mcp

bc_get_operation

Read-only

Check if a Business Central mutating operation succeeded by operationId; returns status and can re-read the target to verify changes after a timeout or unknown outcome.

Instructions

Look up what happened to an earlier mutating call made with an operationId (bc_write_data, bc_execute_action, bc_respond_dialog, bc_wizard_navigate, bc_close_page, bc_switch_company, bc_run_report, bc_upload_file). Returns the operation ledger entry: status (sent, completed, unknown), tool, timestamps, replaySafe, the stored result, and the target snapshot captured before the call ran.

When the outcome is unknown or replaySafe is false, this tool also re-reads the target in the current session: it re-opens the page by page id and record bookmark, reads the identified fields (the record's key fields and any written fields, plus the lines of a document such as a sales order) or the targeted row, closes the page again, and returns them as readBack plus evidenceHash, a SHA-256 of the canonical JSON of readBack. A key field marked source 'bookmark' has no control on the page and is decoded from the record bookmark: an Option key shows its ordinal (Sales Order "Document Type" = '1', meaning Order), not its caption. Use it after OPERATION_IN_DOUBT, a timeout, or SESSION_LOST to decide whether the change landed before acting again under a new operationId.

This tool changes nothing in BC. A completed, replay-safe operation is returned without a read-back. If the operation ran in another company, readBackError COMPANY_MISMATCH tells you to bc_switch_company first. If a dialog is open in the session, readBackError MODAL_OPEN: answer it with bc_respond_dialog first (opening a page would cancel it). If the record no longer exists (a fully posted document is deleted), readBackError RECORD_NOT_OPENED. If the re-opened page shows a different key value than the recorded one, readBackError KEY_MISMATCH returns readBack WITHOUT an evidenceHash: the page landed on another record, so the read-back proves nothing about the target. Do NOT use it to read arbitrary records -- use bc_open_page and bc_read_data for that.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`operationId`	Yes	The operationId you passed to a mutating tool (bc_write_data, bc_execute_action, ...).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`entry`	Yes
`readBack`	No
`evidenceHash`	No
`readBackError`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv2.0.0Oct 15, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare readOnlyHint/openWorldHint; the description goes far beyond, disclosing the conditional read-back behavior, that a completed replay-safe operation skips the read-back, that BC state is unchanged, and four distinct failure modes (COMPANY_MISMATCH, MODAL_OPEN, RECORD_NOT_OPENED, KEY_MISMATCH) with their remediation. The bookmark-decoding caveat for 'source: bookmark' keys is exactly the non-obvious behavioral detail that earns a 5.

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?

Dense but well front-loaded: it opens with what the tool does and the return shape, then behavior, then error routing. Some material (the full return-field enumeration) partly duplicates the output schema, but almost every sentence carries operational weight.

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?

For a lookup/diagnostic tool with an output schema, the description supplies all the decision-relevant context an agent needs: what triggers a call, what a normal vs. read-back response means, and how to resolve each readBackError. Nothing needed to invoke or interpret it is missing.

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

Parameters3/5

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

There is a single parameter with 100% schema description coverage, so the schema already defines operationId's origin. The description restates the same idea (operationId from the listed mutating tools) without adding format/syntax meaning. Baseline 3 is correct.

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?

States a precise verb+resource ('look up what happened to an earlier mutating call made with an operationId') and enumerates the sibling tools that produce such operations. It also explicitly contrasts itself with bc_open_page/bc_read_data for arbitrary reads, so an agent can route correctly without opening any schema.

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?

Gives explicit trigger conditions ('after OPERATION_IN_DOUBT, a timeout, or SESSION_LOST') and an explicit exclusion plus alternative ('Do NOT use it to read arbitrary records -- use bc_open_page and bc_read_data'). This is the when/when-not/alternative trifecta.

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

Deploy Server