business-central-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.6.0
Disambiguation5/5
Each tool has a distinct and unique purpose with no functional overlap. For example, bc_read_data refreshes UI sections while bc_query performs bulk OData reads, and bc_execute_action triggers actions while bc_wizard_navigate drives wizard steps. Descriptions clearly differentiate when to use each tool.
Naming Consistency5/5
All tools follow the 'bc_' prefix with consistent snake_case naming. The pattern is verb_noun (e.g., bc_open_page, bc_write_data, bc_list_companies) with clear, descriptive names. No mixed conventions or ambiguous abbreviations.
Tool Count5/5
With 14 tools, the set covers the essential operations for interacting with Business Central (page management, data reading/writing, actions, reports, company switching, lookup, search) without being bloated or sparse. Each tool serves a well-defined role in the workflow.
Completeness5/5
The tool surface provides comprehensive coverage of Business Central interactions: opening, reading, writing, navigating, executing actions, running reports, handling dialogs, switching companies, and querying via OData. The workflow from discovery (bc_search_pages) through lifecycle is complete with no obvious gaps.
Average 4.8/5 across 14 of 14 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 127 commits in the last 12 weeks
- Last stable release on August 17, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but the description discloses key behaviors: non-mutating, cancels without selecting, leaves field unchanged, returns error for lookupCustom fields. Does not cover edge cases like closed pages but covers major aspects.
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 main purpose and workflow, but includes some repetitive explanations. Still clear and well-organized despite moderate length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and no annotations, the description is thorough: explains preconditions, workflow, and behavioral results. Lacks detail on return format but sufficient for a lookup tool.
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%, and the description adds meaning: field must be editable FK, search uses BC's native search, maxRows default and max. Provides context beyond 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 clearly states the tool enumerates candidate values for a related-table (FK) field using BC's built-in Lookup. It provides specific examples like listing Salesperson Codes, and distinguishes itself from sibling tools by focusing on field enumeration.
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 details when to use (field has isLookup=true) and when not to use (option/enum fields, isLookup false, lookupCustom=true). Provides workflow and alternative suggestions, making the decision clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It thoroughly explains that the pageContextId becomes invalid, subsequent calls will fail, it is safe to call after errors, and when to close drill-down pages.
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?
The description is concise, front-loaded, and every sentence adds value. It could be slightly more terse but is well-structured.
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?
Given no annotations, no output schema, and one parameter, the description is very complete, covering purpose, usage, behavior, and pitfalls.
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?
Schema coverage is 100% with one parameter already described well. The description adds minimal extra meaning (e.g., confirms it's from bc_open_page), so baseline 3 is appropriate.
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 tool closes an open Business Central page and frees server resources, distinguishing it from siblings like bc_read_data or bc_navigate.
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 explicitly states when to call (after finishing work), when not to call (mid-workflow or to reset), and alternatives (use bc_read_data to refresh). It also covers special cases like drill-down pages.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses that the tool opens, reads, and closes the BC Companies page internally, and does not affect open pages or session state.
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?
Description is clear and front-loaded, but includes a slightly redundant sentence about not using if company name is known. Still concise overall.
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?
Covers purpose, return details, usage context, and behavioral side effects. No output schema exists, but description adequately explains what is returned.
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?
No parameters exist; schema coverage is 100%. Description states no parameters are required, which adds clarity beyond the empty 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 clearly states the tool lists all companies and returns company names plus the active company. It distinguishes from sibling tools by specifying it is used before bc_switch_company.
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 states when to use (before bc_switch_company to verify target company) and when not to use (if company name is known). Provides workflow guidance: use bc_switch_company then bc_open_page.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: select does not open or return data, drill_down returns a new pageContextId, both pages remain open, and the need to close both. It also explains section targeting for subpages, leaving no ambiguity.
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?
The description is well-structured with clear sections for actions, examples, and targeting. However, it is somewhat lengthy; some redundancy could be trimmed without losing clarity. Still, it is effectively front-loaded with the main purpose.
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?
Despite no output schema, the description covers return behavior (new pageContextId for drill_down, none for select) and all required parameters. It addresses edge cases (section targeting, exclusion of Card pages), making the tool fully understandable for correct invocation.
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 baseline is 3. The description adds value by providing examples, explaining the action enum in context, and clarifying the role of pageContextId and bookmark beyond the schema descriptions. Thus a score of 4 is warranted.
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 tool navigates to a record on a List or Document page using a bookmark, and distinguishes two actions: select (cursor positioning) and drill_down (opens detail page). It differentiates from sibling tools (bc_lookup for field lookups, bc_execute_action for direct row targeting), making the purpose unambiguous.
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?
It provides explicit guidance on when to use each action, includes examples, and explicitly states when not to use (e.g., Card pages, confusion between select and drill_down). It also directs to bc_lookup for field lookups, covering both positive and negative cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses effect on workflow, chained dialogs, side effects (changedSections, downloads, externalUris). Warns against guessing dialogFormId. No contradictions.
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?
Description is detailed but front-loaded with main purpose. All sentences are necessary for complex workflow; could be slightly more concise but not overly verbose.
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?
Covers all aspects: workflow usage, parameter sources, chained dialogs, side effects like downloads/URIs. No output schema but explains expected result fields adequately.
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 description coverage is 100%, but tool description adds context: how to obtain dialogFormId and pageContextId from previous responses, and clarifies response enum options beyond schema. Adds meaningful value.
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?
Clearly states it responds to dialogs triggered by other tools (bc_execute_action, bc_write_data, bc_run_report). Differentiates from siblings by specifying its role as a follow-up to dialog triggers.
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 states when to call (upon dialogsOpened or requestPage) and when not to call (without preceding dialog). Provides examples, mentions chained dialogs, and explains response options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the internal flow: request page handling, format selection via SystemAction 410, error on unavailable format, oversized file handling, and server-side execution.
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?
The description is long but well-structured: core action first, then request page path, then format path, then usage guidance, then examples. It could trim some redundant detail but remains focused.
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?
Given the tool's complexity (two execution modes, format handling, error cases, no output schema), the description is thorough: it covers the dialog flow, format availability, oversized files, and common use cases.
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?
Input schema already describes both parameters with 100% coverage. The description adds value by providing examples, explaining internal behavior of the format parameter, and listing common report IDs.
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 it executes a BC report by numeric ID, distinguishes from data-viewing tools like bc_open_page/bc_read_data, and explains both request page and format capture modes.
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 states when to use (reports with server-side actions, inspect request pages) and when not (data viewing, confusing with pages), and references sibling tools as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: profile scoping, return format including a note for empty results, AL names vs numeric IDs, and the need to map runTarget to page IDs for opening. This is comprehensive and transparent.
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?
The description is well-organized with front-loaded purpose and clear sections, but it is somewhat lengthy. Each paragraph adds important context, so no waste, but could be slightly more concise.
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?
Given the complexity (Tell Me index, profile scoping, AL name resolution) and lack of output schema, the description covers return structure, empty result behavior, and example use cases, making it fully complete for an agent to use 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?
Only one parameter (query) with schema coverage 100%. The description adds value by providing example queries ('customer', 'sales order') and noting fuzzy matching, going beyond the schema's basic 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 that the tool searches BC's Tell Me index for pages and other run-targets, specifying the resource and return types. It distinguishes from siblings like bc_open_page and bc_read_data, making the purpose specific and unambiguous.
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 guidance on when to use (unknown page ID) and when not (known numeric page ID or reading data). It also explains profile scoping and suggests BC_PROFILE remediation for empty results, providing clear context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses how navigation buttons are identified (by icon resource, not SystemAction/caption), localised wizards work, response fields (fields, availableNav, closed flag), and special handling for file downloads and external URIs. Also notes pageContextId becomes invalid after finish/cancel.
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?
The description is well-structured with main purpose, mechanism details, workflow, dos/don'ts, example, and edge cases. Every sentence adds value, though it could be slightly more concise. Front-loaded with purpose and usage conditions.
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?
Given the complexity of wizard navigation with state, the description covers usage, behavior, parameters, output (including download and external URI handling), and lifecycle of pageContextId. No output schema exists, but response fields are described sufficiently.
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 covers both parameters with descriptions (100% coverage). Description adds context: action values are listed with their effects, pageContextId is from bc_open_page for a NavigatePage, and provides an example. Adds workflow guidance on when to use each action, which is valuable beyond 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 clearly states the tool drives a Business Central NavigatePage/wizard by semantic step, specifying the context after bc_open_page on a NavigatePage. It lists the four possible actions and distinguishes from sibling tool bc_execute_action.
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 states when to use (after bc_open_page on a NavigatePage with isModal true and pageType NavigatePage) and when not to (non-wizard pages, use bc_execute_action instead). Provides a typical workflow and warns not to call 'next' past the last step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavior: validates action, sends RPC, applies events, returns various response fields, handles batch operations, staleness guard, file downloads, and dialog requirements.
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?
The description is well-structured with clear sections and examples, but somewhat lengthy. It earns its length with valuable information, though could be slightly more concise.
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?
Covers all necessary aspects given 8 parameters and no output schema: prerequisites, mutually exclusive fields, batch behavior, dialog handling, staleness guard, and file outputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, yet description adds substantial context beyond schema definitions: examples for cue, section, bookmarks; explains mutual exclusivity; describes staleness guard behavior for expectedStateVersion.
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 explicitly states it executes a named action or cue-tile drill-down on an open page, using strong verbs and specific resource references. It distinguishes from siblings like bc_write_data and bc_navigate.
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?
Provides clear when-to-use guidance, including explicit exclusions for writing fields (use bc_write_data) and navigating (use bc_navigate). Also explains when to follow up with bc_respond_dialog.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return structure (sections, kinds, card vs list shapes), the pageContextId and stateVersion semantics, the sign-in window on BC Online, the need to call bc_close_page, and the enum/options handling with exact usage instructions.
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 lengthy but dense and well-organized. It front-loads the core purpose, then logically expands into structure, usage guidance, workflow, and examples. Every sentence adds essential context for a complex tool; no fluff or redundancy exists.
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?
Given the lack of an output schema and the complexity of the tool, the description thoroughly explains the return format (sections with kinds, shapes, and content), the workflow integration, and special cases (Card, List, Document pages). It covers all essential aspects an agent needs to invoke and interpret the results 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 all three parameters with descriptions, but the tool description adds extra context: pageId examples, bookmark origin ('Bookmarks come from list rows in any prior section'), and the enum/options handling (though that is not parameter-specific). It reinforces schema info with concrete examples and clarifies the usage of bookmark and pageId.
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 tool's function: 'Opens a Business Central page by its numeric page ID and returns its complete state as a list of sections.' It distinguishes itself from siblings by explicitly contrasting with bc_query for bulk reads and bc_search_pages for finding IDs, and clarifies it is the entry point for interactive page-scoped work.
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?
Provides explicit guidance: recommends bc_query for bulk read-only, bc_search_pages for finding IDs, and reusing an existing pageContextId instead of reopening. It also lays out the typical workflow sequence and warns against calling when the page is already open.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It thoroughly discloses return shape (section with fields/rows, stateVersion), behavior differences between card and list sections, filtering/sorting/clearFilters nuances, and limitations like SourceTableView filters remaining active. StateVersion usage for stale-state rejection is clearly explained.
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?
Description is well-structured with clear sections and examples, but it is quite lengthy. While every part adds value, some redundancy exists (e.g., filter syntax repeated in schema and description). Front-loaded with core purpose, but could be slightly more concise.
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?
Given no output schema, description adequately explains return values, all parameters, prerequisites, and error conditions (non-sortable columns). Includes practical examples covering common use cases. Covers all necessary aspects for correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds substantial context beyond schema: default section='header', how options work for enum fields, filter syntax, sorting details, clearFilters caveats. This significantly aids correct parameter usage.
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 exactly what the tool does: 'Refreshes a single section on an already-open page.' Clearly distinguishes from sibling tools like bc_query and bc_write_data by specifying when to use each.
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?
Provides explicit when-to-use and when-not-to-use guidance: 'Do NOT use this for bulk or analytical reads... prefer bc_query' and 'Use bc_read_data when you need the interactive page's exact rows, factboxes, or option metadata.' Also notes prerequisite of pageContextId from bc_open_page.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It fully discloses that all open pages are invalidated, pageContextIds become unusable, and subsequent operations target the new company. The mid-workflow warning adds critical behavioral context.
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 concise and well-structured: first the purpose, then behavioral effects, usage guidelines, and an example. Every sentence adds value, and the length is appropriate for the tool's complexity.
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?
Given the tool's impact (session state change), the description covers all necessary context: prerequisites (list companies), exact match requirement, effect on pages, and workflow restrictions. No output schema needed; the description is complete.
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% with a basic description. The description adds value by stating 'exact match', directing to use bc_list_companies, and providing an example. This goes beyond the schema's minimal description, though not dramatically so.
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 'Switch to a different company within the current Business Central session' using a specific verb and resource. It distinguishes itself from siblings like bc_list_companies (which lists companies) and bc_open_page (which opens pages), making the tool's unique role clear.
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 provides explicit when-to-use guidance: use bc_list_companies first, require exact match, and warns against switching mid-multi-step workflow. It also explains the effect on pages, offering clear alternatives and restrictions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully covers behavioral traits: BC validation, server-confirmed values, read-only field errors, cascading updates, and staleness guard with expectedStateVersion.
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?
Well-structured with clear sections, explicit do/don't, and four relevant examples. Every sentence is informative without redundancy.
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?
Despite no output schema, description explains return value (server-confirmed value) and staleness rejection. Complex tool (6 params, nested objects) is fully covered with usage details.
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%, but description adds significant context beyond schema, such as how to use section, rowIndex, bookmark, and expectedStateVersion, plus examples. Baseline 3, increased due to extra guidance.
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 tool writes field values on an already-open BC page, distinguishes from siblings like bc_execute_action and bc_navigate, and includes specific usage cases.
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 tells when to use (write fields) and when not to (actions, navigation), with alternative tools named. Provides guidance on grouping related fields and using bookmark over rowIndex.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It explicitly states the tool is read-only, describes the auth flow (Basic auth for on-prem, DEVICE_LOGIN_REQUIRED for SaaS), explains the default top=100, and notes company-scoping with the special exception for the 'companies' entity. It also warns that $expand increases response size. This is thorough and transparent.
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?
Despite being lengthy, the description is tightly organized with clear topic headers and no filler. Each sentence adds distinctive value: core functionality, entity list, parameter guidance, auth notes, and exclusions. The front-loading of purpose and the structured sections make it easy to scan.
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?
The tool is complex with 7 parameters and many integration details, but the description covers all essentials: what it reads, how filtering/projection work, entity naming, auth modes, default behavior, sibling alternatives, and the one special-case entity. It even addresses pagination via the top parameter. The absence of an output schema is mitigated by the clear 'reads records' semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description enriches each parameter with concrete OData syntax examples and operational semantics (e.g., 'top defaults to 100 if omitted', 'pass company to target a specific company'). It goes well beyond the schema's simple field explanations, making the parameter usage immediately actionable.
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: 'Reads records from Business Central in bulk using the Standard API v2.0 (OData/REST on port 7048).' It distinguishes from siblings by explicitly stating it is more efficient than bc_open_page + bc_read_data for bulk reads and by noting it does not use a WebSocket session. This leaves no ambiguity about what the tool does.
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 contains dedicated 'When to use' and 'When NOT to use' sections. It names specific alternatives for UI flows (bc_open_page + bc_execute_action) and mutations (bc_write_data and bc_execute_action), and even points to bc_list_companies for company discovery. This is exemplary guidance for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![business-central-mcp MCP server](https://glama.ai/mcp/servers/SShadowS/business-central-mcp/badges/card.svg)](https://glama.ai/mcp/servers/SShadowS/business-central-mcp)

Score Badge

Copy to your README.md:

[![business-central-mcp MCP server](https://glama.ai/mcp/servers/SShadowS/business-central-mcp/badges/score.svg)](https://glama.ai/mcp/servers/SShadowS/business-central-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SShadowS/business-central-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server