business-central-mcp

bc_data_get_table_relations

Read-only

Lists a Business Central table's outgoing and incoming TableRelation links, revealing join fields needed to write correct multi-table AL queries.

Instructions

Lists the TableRelation links of a Business Central table, so you can join tables correctly in an AL query. direction "outgoing" returns the tables this table points to and the fields that link them (e.g. Customer -> Country/Region via "Country/Region Code"); "incoming" returns the tables that point to this one (e.g. which ledger tables reference Customer), capped at 50 source tables with incomingTruncated/incomingTotalCount when cut. Conditional relations carry a "conditions" text (e.g. "Type=CONST(Item)").

Use it before writing a multi-dataitem query for bc_data_query: the via-field gives the DataItemLink. Pass relatedToTableIds to ask only about specific tables, which is also how to get past a truncated incoming list. Follow up with bc_data_get_table_schema for exact field names and types. When NOT to use: for single-table queries, or to read data. 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.
`direction`	Yes	"outgoing": tables this table points to through TableRelation fields (e.g., Customer -> Country/Region). "incoming": tables that point to this one (capped at 50 source tables).
`relatedToTableIds`	No	Only relations to/from these table IDs. Use it to find the join path between two known tables, or when an incoming answer was truncated.

Output Schema

Name	Required	Description	Default
`hint`	No
`company`	Yes
`tableId`	Yes
`incoming`	No
`outgoing`	No
`tableName`	Yes
`incomingTruncated`	No
`incomingTotalCount`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv2.4.7Nov 5, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description stays consistent while adding substantial behavior the annotations cannot express: the 50-source-table cap, the incomingTruncated/incomingTotalCount truncation markers, the shape of the "conditions" text for conditional relations, and the via-field that supplies the DataItemLink. It also discloses runtime prerequisites (BC 29+, "Data Query Tools (Preview)" enabled, no web-client session needed), which changes whether the agent should attempt the call at all.

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 purpose, then direction semantics, then the workflow rule, then exclusions and environment — a sensible order with no filler paragraphs. It is dense and slightly long, and the Customer/Country-Region example appears twice (once per direction), but each sentence still carries information an agent needs.

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 structure needn't be explained, yet the description still flags the truncation fields and the conditions text format that an agent would otherwise miss. Combined with annotations, full schema coverage, prerequisites, and the handoff to bc_data_query and bc_data_get_table_schema, nothing needed to call this correctly is absent.

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 genuine meaning: concrete direction examples (Customer -> Country/Region via "Country/Region Code" for outgoing; ledger tables referencing Customer for incoming) and two distinct use cases for relatedToTableIds (finding a join path between two known tables, escaping a truncated incoming list). These are usage semantics rather than restatements of the schema text.

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 ("Lists the TableRelation links of a Business Central table") plus the downstream purpose (joining tables in an AL query). It explicitly separates itself from bc_data_get_table_schema and bc_data_query by naming them as follow-up/precursor tools, so an agent can pick it out of a 24-tool sibling list immediately.

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 an explicit trigger ("Use it before writing a multi-dataitem query for bc_data_query"), an explicit anti-trigger ("When NOT to use: for single-table queries, or to read data"), and names the alternative for the follow-up step (bc_data_get_table_schema). It also explains the recovery path when the incoming list is truncated (pass relatedToTableIds), which is a real decision the agent will face.

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