Microsoft Business Central MCP Server

Server Quality Checklist

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

Latest release: v0.1.4
Disambiguation4/5
Most tools are clearly distinct: create, update, delete, and schema retrieval are unambiguous. However, list_items and get_items_by_field both retrieve items and could be confused, though descriptions clarify that one is general listing and the other is field-based lookup.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern: get_schema, list_items, get_items_by_field, create_item, update_item, delete_item. The mix of 'get' and 'list' for retrieval is standard and predictable.
Tool Count5/5
With 6 tools covering schema access and full CRUD for items, the count is well-scoped for the server's stated purpose. No redundant tools, and each one has a clear role.
Completeness4/5
The tool surface covers the core item lifecycle (create, read, update, delete) and schema introspection. A direct get-by-ID tool is missing, but list_items with filters effectively covers that need. For a single-resource server, this is nearly complete.
Average 3.1/5 across 6 of 6 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavior. It only states 'Create a new item' without mentioning any side effects, permissions needed, error conditions, or how existing data might be affected. This is minimal transparency for a mutation tool.
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 a single, concise sentence that gets to the point quickly. It is not verbose, but it lacks some detail that could be included without sacrificing brevity. Overall, it is appropriately sized for a simple create tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters including a nested object and no output schema, the one-sentence description is insufficient. It does not explain what 'item' means, how to structure item_data, or what the response will be. Sibling tool context suggests it is a generic create, but that is not conveyed.
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 both parameters described ('resource' and 'item_data'), so the schema already provides the essential meanings. The description adds no extra parameter context, but with full schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (creating) and the resource ('new item in Business Central'), distinguishing it from sibling tools like update_item and delete_item. However, it does not clarify that the 'resource' parameter makes it a generic create tool for various entity types, which could cause slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as update_item or list_items. There is no mention of prerequisites, exclusions, or specific scenarios where this tool is appropriate, leaving usage inferred solely from the verb 'create'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states 'Update an existing item' without explaining whether item_data is a partial or full replacement, what happens to omitted fields, or any error behavior. This is insufficient for a mutation tool.
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 a single concise sentence, efficiently conveying the tool's purpose without unnecessary detail. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description should compensate by explaining how to use item_data and what the tool returns. It does not. The nested object item_data is left ambiguous, and there is no information about the update semantics, making the description incomplete for a successful invocation.
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 all three parameters described, so the baseline is 3. The description adds no additional semantic meaning beyond the schema; it does not clarify the structure or expected format of item_data, which is a nested object with no defined properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and target ('existing item in Business Central'), which distinguishes it from sibling tools like create_item, delete_item, and list_items. While it could be more specific about which item types are supported, it is unambiguous about its core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as create_item or get_items_by_field. It also fails to mention prerequisites like needing to obtain the item_id via list_items, or whether items must exist before updating.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It merely restates the action 'Delete' without describing the deletion's effects, reversibility, or any required confirmation.
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 a single, straightforward sentence with no unnecessary words. It's appropriately front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, but it's a simple delete with only two parameters. The description covers the basic action but lacks context about the target resource type or the deletion's outcome, which is a gap. Still, the schema fills in the parameters, making it minimally viable.
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?
Both parameters are fully described in the schema. The description adds no additional meaning about item_id or resource, so it doesn't exceed the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action ('Delete') and system context ('Business Central'), which distinguishes it from sibling tools like create/update. However, 'item' is generic and doesn't indicate the resource parameter, so it's slightly less precise than ideal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No information about when to use this tool, such as requiring an existing item or not using for bulk operations. No exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It conveys a read-only operation but lacks details about pagination, result limits, or response format. The phrase 'matching a field value' adds minimal 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 a single sentence that immediately states the action and criterion, making it highly efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity and full parameter schemas, the lack of output schema and annotations leaves return behavior unexplained. The description gives no indication of output shape, pagination, or edge cases, making it incomplete for an agent.
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?
The schema covers all three parameters with descriptions (100% coverage), so the baseline is 3. The description's 'matching a field value' aligns with schema semantics but does not add new detail beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and clearly indicates filtered retrieval by field value, distinguishing it from list_items (unfiltered listing) and get_schema. However, it doesn't explicitly name the resource scope beyond the schema parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when fetching items by a known field/value pair, but it provides no explicit when-not or alternative tool references. With siblings like list_items, a comparative note would strengthen guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It only says 'Get schema information' without stating what is returned (e.g., field definitions, types), whether it is a read-only operation, or any limitations. The behavior is implicitly simple but not fully 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?
The description is a single, front-loaded sentence with no unnecessary words. It is highly concise while still conveying the core action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and a simple single-parameter input, the description still leaves ambiguity about what 'schema information' entails. An agent may not know if the response includes field names, types, or constraints, making it incomplete for a metadata-retrieval tool.
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?
The schema already provides 100% coverage of the single parameter 'resource' with a clear description and examples. The description adds little beyond the schema, but the 'Business Central' context provides some external meaning. 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 a specific verb ('Get') and resource ('schema information for a Business Central resource'), which distinguishes it from sibling tools like list_items and create_item. The resource examples in the schema further clarify its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any preconditions or follow-up steps. Sibling tools are item operations, so the schema tool's role as a metadata lookup is implied but not stated explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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. It only restates 'Get items' and 'filtering and pagination' without disclosing additional behavioral traits like read-only nature, pagination limits, error handling, or required permissions. The description adds little beyond what the name and schema already convey.
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 a single, focused sentence that front-loads the action and resource. It contains no fluff or unnecessary details, exemplifying conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple list operation with 4 params and schema coverage 100%, the description is minimally adequate. However, it lacks guidance on usage vs siblings, return value structure (no output schema), and any edge-case behavior, leaving some gaps for an agent.
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 description coverage is 100%, so the baseline is 3. The description mentions 'filtering and pagination' which maps to filter/top/skip, but this adds no new information beyond the schema descriptions. It does not provide extra meaning for any parameter.
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 action ('Get items') and the resource ('from Business Central'), with key features 'filtering and pagination'. This distinguishes it from siblings like get_schema, create_item, update_item, and delete_item, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing items with filtering/pagination but does not explicitly compare with alternatives like get_items_by_field. No 'when-to-use' or 'when-not-to-use' guidance is given, making the usage context only implied rather than clearly stated.
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:

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

Score Badge

Copy to your README.md:

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

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/keithdev21/Mcp-Business-Central'

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