business-central-mcp

bc_api_describe

Read-only

Returns the full schema of a Business Central API action, including parameters and available fields, so you can build exact filters, selects, and invoke parameters.

Instructions

Returns the full schema of one Business Central API action found with bc_api_search: what it does, and the JSON schema of its parameters. For a List action the schema's "_availableFields" lists every field with its type and option values, and says which fields can be used in filter, orderby and select. For Create the properties are the editable fields; for Modify the required "id" and "If-Match" (the record's current "@odata.etag") plus the editable fields; for Delete the key; for a bound action the key and the action's own parameters.

Call it before bc_api_list (to know the exact field names for filter/select/orderby) and before every bc_api_invoke (to send exactly the parameters the action takes; bc_api_invoke's "parameters" object uses the property names from this schema). When NOT to use: to discover action names (bc_api_search) or to read data (bc_api_list). Runs on BC's own MCP server (BC 29+, API tools enabled); needs no web-client session.

Input Schema

Name	Required	Description	Default
`company`	No	Company to run in (exact, case-sensitive name from bc_list_companies). Defaults to the current session company, then BC_ODATA_COMPANY, then the user's default company in BC.
`actionName`	Yes	Exact, case-sensitive action name from bc_api_search, e.g. "List_Customers_PAG30009" or "Create_Customer_PAG30009".

Output Schema

Name	Required	Description	Default
`name`	Yes
`schema`	Yes
`company`	Yes
`description`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv2.4.7Nov 5, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the description's main added value is the runtime context: it runs on BC's own MCP server, requires BC 29+ with API tools enabled, and needs no web-client session. It also discloses how each action type shapes the returned schema, but it does not discuss error behavior for an unknown or misspelled actionName.

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?

Front-loaded with the core purpose, then procedural guidance, then exclusions — a sensible ordering. The per-action-type enumeration of schema contents is dense but each clause carries information the agent needs; only the List/Create/Modify/Delete breakdown borders on over-detailed.

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?

An output schema exists, so return values need not be re-described, and annotations cover the safety profile. The description fills the remaining gap for a two-step discover-then-inspect workflow by naming the prerequisite tool and the downstream consumers.

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 coverage is 100%, so both parameters are documented structurally; the description still adds cross-tool meaning by tying actionName to bc_api_search results and by explaining that bc_api_invoke's 'parameters' object uses the property names from this schema. The company parameter's fallback chain is left entirely to the schema, which is acceptable at full coverage.

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 specific verb and resource ('Returns the full schema of one Business Central API action found with bc_api_search') and immediately enumerates what that schema contains for each action type (List, Create, Modify, Delete, bound action). It is clearly distinguishable from bc_api_search and bc_api_list, which are named.

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?

Explicitly prescribes sequencing ('Call it before bc_api_list ... and before every bc_api_invoke') with the reason for each, and provides an explicit exclusion clause ('When NOT to use: to discover action names (bc_api_search) or to read data (bc_api_list)'). Nothing about when to reach for this tool is left to inference.

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