business-central-mcp

bc_data_get_table_schema

Read-only

Returns a Business Central table's field names, types, option values, FlowField formulas, and relations so you can write correct AL queries without name errors.

Instructions

Returns the fields of a Business Central table as compact pipe-delimited text: a header with the table name, ID and primary key, then one line per field with its exact name and type, option values for Option fields, the formula for FlowFields (e.g. "FlowField: Sum("Cust. Ledger Entry"."Amount")"), and TableRelation targets ("rel: Country/Region"). Field names differ between environments and installed extensions, so call this for EVERY table before writing an AL query for bc_data_query — a wrong name is a compile error (AL0345).

Use fieldClass to list only Normal fields, FlowFields or FlowFilters, and nameContains to keep the answer small on wide tables (e.g. ["No.", "Amount", "Date"]). Get table IDs from bc_data_find_tables. When NOT to use: to read field values (this returns metadata only; run a query with bc_data_query, or read a page with bc_open_page). Runs on BC's own MCP server (BC 29+, "Data Query Tools (Preview)" enabled); needs no web-client session.

Input Schema

Name	Required	Description
`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.
`tableId`	Yes	Numeric BC table ID (e.g., 18 Customer, 17 G/L Entry, 37 Sales Line). Find IDs with bc_data_find_tables.
`fieldClass`	No	Only fields of this class. FlowFields are calculated (e.g., Customer "Balance (LCY)"); FlowFilters only narrow FlowField calculations.
`nameContains`	No	Only fields whose name contains any of these fragments (case-insensitive), e.g. ["No.", "Amount"]. Use it on wide tables to keep the answer small.

Output Schema

Name	Required	Description	Default
`schema`	Yes
`company`	Yes
`tableId`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv2.4.7Nov 5, 2026

TDQS

A4.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is known. The description goes beyond them usefully by disclosing that Option values, FlowField formulas, and TableRelation targets are included, plus the runtime prerequisite (BC 29+, "Data Query Tools (Preview)" enabled, no web-client session). However, much of the format detail is already carried by the output schema, so the added behavioral content is real but partly redundant.

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 output contract, then practical routing, then exclusions and runtime prerequisites — a sensible order with no filler sentences. It is dense, and the formula/TableRelation examples are long, but each clause carries actionable information rather than padding.

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?

With an output schema present, the description needn't explain return values in full, yet it still characterizes the field-line format enough to parse the response. Combined with the prerequisite note, sibling routing, and filter strategy, an agent has everything needed to invoke this correctly on the first try.

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 the baseline is 3, but the description adds operational meaning: fieldClass is framed as a way to list only a given class, and nameContains is explained as a size-control mechanism for wide tables with a concrete example fragment list. That is guidance on how to combine filters, not just restatement of 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 ("Returns the fields of a Business Central table") and immediately specifies the output shape (pipe-delimited text with header, name, ID, primary key). It is unmistakably distinct from siblings bc_data_find_tables (ID lookup) and bc_data_query (value retrieval).

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?

Explicit when-to-use: call this for EVERY table before writing an AL query for bc_data_query, with the consequence spelled out (wrong name is AL0345 compile error). It also names where table IDs come from (bc_data_find_tables) and gives a dedicated "When NOT to use" clause routing to bc_data_query and bc_open_page for values.

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