Business Central MCP Server

Server Quality Checklist

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

Latest release: v1.4.0
Disambiguation5/5
Each tool has a clearly distinct purpose: opening pages, navigating, reading/writing data, executing actions, closing pages, searching, responding to dialogs, switching companies, listing companies, running reports, driving wizards, looking up FK values, and bulk querying. There is no ambiguity or overlap.
Naming Consistency5/5
All tools follow the 'bc_' prefix with lowercase and underscores. Most use a verb_noun pattern (e.g., 'bc_open_page', 'bc_read_data'), and even those with just a verb (e.g., 'bc_navigate', 'bc_lookup') maintain consistency. No mixed conventions.
Tool Count5/5
14 tools is well within the ideal 3-15 range for a complex ERP system like Business Central. Each tool serves a specific and necessary function, covering page management, data operations, actions, search, reporting, wizards, lookups, and bulk queries.
Completeness5/5
The tool set covers the full lifecycle of interacting with Business Central: opening, navigating, reading, writing, executing actions, handling dialogs, closing pages, plus searching, company management, report execution, wizard driving, lookups, and bulk OData queries. No obvious gaps for typical agent workflows.
Average 4.8/5 across 14 of 14 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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 provided, so description carries full burden. It discloses that pageContextId becomes invalid, that it's safe after errors, and that it frees server resources. Could mention idempotency but still strong.
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 three paragraphs and front-loaded with key action. Every sentence adds value, though slightly verbose. Could be tightened without losing content.
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 simple close tool with one parameter and no output schema or annotations, the description is comprehensive. Covers purpose, usage, behavioral implications, and error handling.
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% and schema already describes pageContextId. Description adds that it requires context from bc_open_page and becomes invalid, but this is marginal. 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 'Closes an open Business Central page and frees its server-side resources', providing a specific verb (close) and resource (page). It effectively distinguishes from sibling tools like bc_open_page, bc_read_data, etc.
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 says 'Always call this when you are finished working with a page' and warns 'Do NOT call this in the middle of a multi-step workflow'. It also provides alternatives: 'use bc_read_data to refresh data instead' for resetting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses read-only nature (OData reads), company scoping, default top to prevent full-table scans, auth method (HTTP Basic), and special handling of 'companies' entity. However, it does not describe the response format (e.g., array of objects) or pagination behavior, which would be helpful.
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 but is somewhat verbose, including repeated entity lists and extended examples. It could be more concise without losing clarity.
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 7 parameters and no output schema, the description is highly complete, covering purpose, usage, parameter syntax, alternatives, auth, and edge cases. It lacks only the response format/pagination details, which slightly reduces completeness.
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 description coverage is 100%, so baseline is 3. The description adds significant value beyond schema by providing OData syntax examples for filter, select, orderby, expand, and explaining the default top behavior. It also lists valid entity names and clarifies company scope.
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 reads records in bulk via BC Standard API v2.0, specifying a specific verb ('reads') and resource ('records from Business Central'). It distinguishes from sibling tools like bc_open_page and bc_read_data by emphasizing server-side filtering and projection.
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' and 'When NOT to use' sections, listing appropriate use cases (e.g., structured data retrieval, bulk reads with server-side operations) and inappropriate ones (e.g., UI-driven flows, writing). It names alternative tools like bc_open_page and bc_execute_action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations were provided, so the description bears full responsibility. It explains the effects of different response values, mentions checking changedSections, and warns about chained dialogs. However, it does not mention any rate limits, authentication requirements, or potential irreversibility of actions beyond the dialog context.
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 the primary purpose upfront, followed by usage details, parameter guidance, and examples. It is somewhat long but each section adds necessary context for correct usage. Could be slightly more concise, but maintains clarity.
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 dialog handling in Business Central, the description covers all essential aspects: when to call, how to obtain identifiers, valid responses, what to check after calling (changedSections, chained dialogs). With no output schema, the description adequately explains expected outcomes.
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%, so baseline is 3. The description adds value by contextualizing parameters: where to find dialogFormId (from dialogsOpened or requestPage), what each response value means in context (e.g., 'yes' for yes/no questions), and example usage. This enhances the schematic definitions.
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 responds to Business Central dialogs/confirmation prompts, specifying that dialogs are triggered by other tools (bc_execute_action, bc_write_data, bc_run_report). This distinguishes it from sibling tools like bc_open_page or bc_read_data which have different purposes.
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-call guidance: only after receiving a dialogsOpened array or requestPage, and warns not to call without a preceding dialog. It also advises to use the exact dialogFormId from responses and gives examples of response values like 'ok' for confirmation dialogs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It details return shape, stateVersion usage, filtering/sorting/column selection behavior, clearFilters limitations (page-defined filters remain), and enum handling. Lacks explicit statement that tool is read-only, but context implies no side effects.
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?
Long but well-structured: paragraphs for each feature, front-loaded with purpose and return value. Each section adds value; could slightly reduce redundancy but appropriate for 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?
No output schema, but description explains return format (section object with fields, rows, totalRowCount, stateVersion). Covers all 8 parameters, including nested objects. Provides edge cases (clearFilters not fully clearing), pagination guidance, and multiple examples. Extremely complete for a complex tool.
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%, providing baseline 3. Description adds extensive context: filter syntax examples, sorting constraints (non-sortable columns), range slicing for pagination, clearFilters stacking behavior, and tab filtering. Examples illustrate each parameter's use.
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 refreshes a single section on an already-open page. It distinguishes from siblings like bc_query by explicitly saying when NOT to use it, and ties it to a prerequisite (bc_open_page).
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: '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 provides context on when to use different sections.
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 discloses non-mutating behavior, that it always cancels without selecting, and mentions error conditions for lookupCustom. Clearly defines side effects.
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?
Well-structured with purpose first, then usage, exclusions, and workflow. Slightly lengthy but each sentence is informative. No 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 of candidate rows and error handling. Covers prerequisites (open page), limits (maxRows), and search filtering. Complete for the tool's complexity.
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%, baseline 3. Description adds examples ('Salesperson Code'), clarifies search string usage, and states defaults for maxRows. Adds value 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 enumerates candidate values for FK fields via BC's Lookup. It distinguishes from siblings like bc_open_page and bc_write_data.
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 writing, field has isLookup=true) and when not to use (option fields, lookupCustom=true, isLookup false/absent). Provides example workflow.
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?
The description fully discloses behavioral traits: 'select' only moves cursor, does not return data; 'drill_down' opens a new page and returns a new pageContextId; both pages must be closed. No annotations provided, so description carries the full burden.
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 a summary, action breakdown, additional notes, and examples. It is slightly long but every sentence is informative. Could be more concise, but remains effective.
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 description covers prerequisites, action behaviors, return values (for drill_down), section targeting, and post-usage cleanup. It also differentiates from sibling tools, making it complete for the complexity of this 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%, but the description adds significant value by explaining the context and effects of each parameter, such as the action enum meanings, section targeting, and the role of pageContextId/bookmark in the workflow.
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 purpose: navigating to a specific record on a Business Central List or Document page using its bookmark. It defines two actions, 'select' and 'drill_down', and distinguishes from sibling tools like bc_lookup and 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?
The description provides explicit guidance on when to use the tool (e.g., not for Card pages, not for field lookups), when to use alternatives (bc_lookup for lookups, bc_execute_action for actions), and includes examples for clarity.
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 fully carries behavioral disclosure. Details return structure (sections, kinds, content shapes, header adaptation), extra properties for option/enum fields, stateVersion for stale state guarding, and the requirement to call bc_close_page. 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?
Relatively long but well-organized: begins with purpose and return structure, then workflow, parameter details, and examples. Every sentence adds value; front-loads key behavioral and usage info. Minor redundancy in examples but overall efficient for the 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?
No output schema, but description thoroughly explains return structure with examples and edge cases (card vs list pages, option/enum fields). Covers all parameters, workflow, sibling distinctions, and practical usage notes. Complete for an AI 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?
Schema coverage is 100%, baseline 3. Description adds meaning: explains bookmark origin from list rows, pageId numeric range and discovery via bc_search_pages, tenantId defaulting. Provides context beyond schema definitions.
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 'Opens a Business Central page by its numeric page ID and returns its complete state as a list of sections.' It distinguishes from siblings by naming tools that do not need a pageContextId, such as bc_query and bc_search_pages. Examples further clarify the tool's role.
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 workflow (bc_open_page -> bc_read_data -> ... -> bc_close_page). States when to avoid calling this tool (if page already open, reuse contextId) and recommends alternatives: prefer bc_query for bulk read-only, use bc_search_pages first if page ID unknown. Clearly distinguishes sibling tools that don't need pageContextId.
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?
Thoroughly discloses profile-scoped behavior and empty-result remediation. Explains that runTarget is AL name, not numeric ID, and that caller needs to map to page ID. Describes return format and note field.
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?
Well-structured with clear sections, examples, and edge-case handling. Slightly lengthy but every sentence adds value.
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 single parameter, no output schema, and sibling tools, description is exhaustive: covers return format, profile scoping, runTarget nuance, empty behavior, and examples.
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 description of 'query' parameter. Description adds context: fuzzy matching, keywords, and examples, going 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?
Clearly states it searches BC's Tell Me index for pages, reports, codeunits, etc. Returns specific fields. Distinguishes from sibling bc_open_page (use when page ID known).
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 says when to use (don't know page ID) and when not (already know numeric ID). Provides alternative tool bc_open_page. Also warns not to use for reading data.
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 full burden. It discloses key behaviors: server confirmation may differ from input due to formatting/auto-completion/lookups, read-only fields cause errors, validation cascades, and expectedStateVersion rejection with STALE_CONTEXT. No contradictions with annotations (none provided).
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?
Well-structured with clear paragraphs and bulleted examples. Each sentence adds value, though slightly verbose; could be trimmed without losing meaning. Front-loaded with core purpose.
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 6 parameters, nested objects, and no output schema, the description is thorough. However, it does not fully specify the return value structure beyond 'server-confirmed value', and examples omit return shapes. A minor gap for a complex write tool.
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?
All 6 parameters have schema descriptions (100% coverage), and the description adds substantial value: explains fields structure (caption-name keys, string values), section usage, bookmark vs rowIndex semantics, and expectedStateVersion as staleness guard with concrete examples. Goes well 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?
Explicitly states 'writes one or more field values on an already-open Business Central page', clearly identifying the action and resource. Distinguishes from siblings like bc_execute_action and bc_navigate by explicitly stating what not to use it for.
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 comprehensive when-to-use and when-not-to-use guidance, including explicit alternatives (e.g., 'Do NOT use this for triggering actions like Post, Delete, or Release -- use bc_execute_action instead'). Also advises on related fields grouping, bookmark vs rowIndex preference, and staleness guard 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?
Without annotations, the description fully details behavior: how format capture works (internal 'Send to...' flow, SaveValue, confirmation), that format availability depends on layouts, error behavior (returns available options), and that output includes download fields and optional disk saving. No contradictions since annotations are absent.
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 it is lengthy. Every part adds value, so it earns a high score, yet could be slightly more concise without losing clarity.
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 (request page handling, internal format capture), the description covers all essential aspects: parameters, usage steps, return values (download.bytes, contentType, fileName, savedPath), error behavior, and references to sibling tools. No output schema, but return info is adequately described.
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 significant context: explains format enum values (pdf is BC default, excel prefers 'data only', word targets any option containing 'Word'), clarifies that omitting format opens request page only, and provides example report IDs. This goes well beyond the schema descriptions.
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 'Execute a Business Central report by its numeric report ID.' It distinguishes reports from pages, listing specific use cases like batch posting and data processing, and provides examples for different modes (request page only vs. capturing PDF/Excel/Word). This matches the sibling context where bc_open_page and bc_read_data are for data 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?
Explicitly states when to use (server-side actions, request page inspection) and when not to use ('Do NOT use this for viewing data – use bc_open_page and bc_read_data'). Provides alternatives and explains the request page flow (bc_write_data, bc_respond_dialog) and format flow. Also lists common report IDs for reference.
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 fully carries the burden of behavioral disclosure. It explains how navigation buttons are identified (by icon resource), the response fields (new step fields, availableNav, closed flag), and the fact that the wizard closes itself on finish/cancel, invalidating the pageContextId. This is comprehensive.
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. It front-loads the core purpose, then provides details, examples, and warnings. Every sentence contributes meaning without redundancy. The example JSON helps clarify usage efficiently.
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 and the fact that no output schema exists, the description adequately covers return behavior (fields, availableNav, closed flag) and the typical workflow (bc_open_page -> bc_write_data -> navigate -> ...). It provides sufficient context for an AI agent to use the tool 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?
Input schema has 100% description coverage for both parameters, so baseline is 3. The description adds value by explaining the action enum values with more context (e.g., 'next' advances, 'back' returns) and providing a concrete JSON example. This enhances understanding beyond the schema alone.
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 identifies the tool's purpose: driving a Business Central NavigatePage/wizard by semantic step. It specifies the verb (navigate), resource (wizard), and distinguishes from siblings like bc_execute_action. The context of use (after bc_open_page on a modal NavigatePage) is precisely stated.
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 usage guidelines are provided: when to use (after bc_open_page with specific response conditions) and when not to use (non-wizard pages, instead use bc_execute_action). It also warns against using 'next' past the last step and advises using 'finish' when available. This offers clear decision support.
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 the description fully discloses behavior: validates action is enabled, sends RPC, applies events, returns updatedFields/changedSections/dialogsOpened/openedPages, fails with STALE_CONTEXT if state version mismatches, and describes dialog handling requiring bc_respond_dialog.
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: starts with a succinct summary, then details each mode, includes constraints, and ends with clear examples. Every sentence adds value 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?
Given the tool's complexity (7 parameters, two modes, staleness guard, dialog handling), the description covers all prerequisites, behavior, and follow-ups. Examples cover common use cases. No gaps.
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 the description adds critical semantics: mutual exclusivity of action/cue, section requirement for cue, rowIndex/bookmark for row-scoped actions, and expectedStateVersion guard. Examples illustrate 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?
The description clearly states the tool executes a named action or a cue-tile drill-down on an open page. It distinguishes itself from siblings by explicitly warning not to use for writing fields (bc_write_data) or opening records from a list (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 explicit when-to-use (execute actions, drill-down cues), when-not-to-use (writing fields, opening records), and alternatives (bc_write_data, bc_navigate). Also explains staleness guard and mutual exclusivity of action/cue.
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?
Details internal behavior (opens BC Companies system page, reads entries, closes it) and explicitly states no effect on currently open pages or session state. With no annotations, the description fully discloses behavioral traits.
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?
Every sentence is purposeful. The description is front-loaded with the core purpose, followed by usage guidance and behavioral notes. No redundancy or filler.
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 tool with zero parameters and no output schema, the description covers all necessary context: purpose, usage, internal behavior, side effects, and relationship to sibling tools. Nothing is missing.
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 has no parameters, and description explicitly confirms 'No parameters are required.' This adds clarity beyond the empty schema, especially by explaining the absence.
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 'List all companies available' with specific verb and resource. Distinguishes itself from sibling bc_switch_company by indicating its role as a discovery/verification step before switching.
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 says to use before bc_switch_company to verify existence, and not to use if company name is already known. Provides a recommended workflow: bc_switch_company then bc_open_page for working with data.
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?
Discloses that all pages are invalidated, pageContextIds become unusable, and subsequent calls affect the new company. No annotations provided, so description fully covers behavioral traits.
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 main purpose first, followed by detailed behavior, usage warnings, and example. No redundant information.
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 or annotations, description covers all necessary context: prerequisites, side effects, workflow implications, and example usage.
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 covers 100% of parameters with description, and description adds example, exact match requirement, and reference to bc_list_companies, enhancing clarity 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?
Description clearly states 'Switch to a different company' and specifies that it invalidates pages, distinguishing it from sibling tools like bc_open_page 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?
Provides explicit guidance: use bc_list_companies first, avoid switching mid-workflow, and exact match required. Clearly states when to use and when not to.
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

Business-Central-MCP-Integration MCP server

Copy to your README.md:

[![Business-Central-MCP-Integration MCP server](https://glama.ai/mcp/servers/MehrozeKhan73/Business-Central-MCP-Integration/badges/card.svg)](https://glama.ai/mcp/servers/MehrozeKhan73/Business-Central-MCP-Integration)

Score Badge

Copy to your README.md:

[![Business-Central-MCP-Integration MCP server](https://glama.ai/mcp/servers/MehrozeKhan73/Business-Central-MCP-Integration/badges/score.svg)](https://glama.ai/mcp/servers/MehrozeKhan73/Business-Central-MCP-Integration)

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/MehrozeKhan73/Business-Central-MCP-Integration'

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