Skip to main content
Glama
SShadowS

business-central-mcp

by SShadowS
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

bc_switch_company

Switch the active Business Central session to a different company. Use bc_list_companies first, then provide the exact company name; open pages are invalidated and must be reopened after the switch.

Instructions

Switch to a different company within the current Business Central session. All currently open pages will be invalidated and their pageContextIds will become unusable -- you must call bc_open_page to re-open any pages you need in the new company context.

Use bc_list_companies first to see the available company names and verify the target company exists. The companyName must be an exact, case-sensitive match (a wrong-case or unknown name returns COMPANY_NOT_FOUND and leaves the session on its current company). After switching, all subsequent bc_open_page, bc_read_data, bc_write_data, and bc_execute_action calls will operate against the new company's data.

Do NOT switch companies in the middle of a multi-step workflow (e.g., between creating a Sales Order and posting it). Complete all operations in the current company first, then switch.

Example: { "companyName": "CRONUS International Ltd." }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
companyNameYesExact company name to switch to. Use bc_list_companies to see available company names.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.5.0

TDQS

A4.9/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden—and it delivers. It discloses that open pages are invalidated, pageContextIds become unusable, unknown names return COMPANY_NOT_FOUND without changing the company, and all later data/action calls target the new company. This is rich behavioral disclosure beyond the basic mutation.

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 longer than average, but every sentence earns its place: purpose, critical invalidation side effect, prerequisite, failure behavior, post-switch scope, and a workflow warning. It is front-loaded with the most important consequence and uses structure to emphasize the 'do NOT' case.

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 one-parameter, high-stakes session-switching tool with no annotations and no output schema, the description is complete. It covers prerequisite, exact input requirements, failure mode, side effects, and safe workflow usage. Nothing essential is missing for an agent to invoke it correctly.

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?

The schema already covers the single parameter at 100%, so the baseline is 3. The description adds meaningful semantics: exact case-sensitivity, error behavior for wrong-case names, and a concrete example. This goes beyond the schema's minimal description.

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 clearly states the verb and resource: 'Switch to a different company within the current Business Central session.' It is explicitly distinguished from siblings like bc_list_companies, which lists companies rather than switching to one. The purpose is unambiguous and not a tautology.

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?

The description gives strong usage guidance: call bc_list_companies first to verify the target, require an exact case-sensitive match, and avoid switching mid-workflow. It explicitly warns against a common misuse case and explains the session-wide effect on subsequent tool calls.

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

Deploy Server

Other Tools