How do I use Microsoft Business Central MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Microsoft Business Central MCP Server show me my top 10 customers by sales" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Microsoft Business Central MCP Server

by knowall-ai

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Microsoft Business Central MCP Server

Model Context Protocol (MCP) server for Microsoft Dynamics 365 Business Central. Provides AI assistants with direct access to Business Central data through properly formatted API v2.0 calls.

Features

✅ Correct API URLs: Uses proper /companies(id)/resource format (no ODataV4 segment)
✅ Zero Installation: Run with npx - no pre-installation required
✅ Azure CLI Auth: Leverages existing Azure CLI authentication
✅ Client Credentials Auth: Service-to-service authentication for AI agents
✅ Clean Tool Names: No prefixes, just get_schema, list_items, etc.
✅ Full CRUD: Create, read, update, and delete Business Central records

Related MCP server: Microsoft Business Central MCP Server

Installation

Using npx (Recommended)

No installation needed! Configure in Claude Desktop or Claude Code:

{
  "mcpServers": {
    "business-central": {
      "type": "stdio",
      "command": "cmd",
      "args": ["/c", "npx", "-y", "@knowall-ai/mcp-business-central"],
      "env": {
        "BC_URL_SERVER": "https://api.businesscentral.dynamics.com/v2.0/{tenant-id}/{environment}/api/v2.0",
        "BC_COMPANY": "Your Company Name",
        "BC_AUTH_TYPE": "azure_cli"
      }
    }
  }
}

Note for Windows: Use cmd with /c as shown above for proper npx execution.

Using Smithery

Install via Smithery:

npx -y @smithery/cli install @knowall-ai/mcp-business-central --client claude

Local Development

git clone https://github.com/knowall-ai/mcp-business-central.git
cd mcp-business-central
npm install
npm run build
node build/index.js

Configuration

Environment Variables

Variable	Required	Description	Example
`BC_URL_SERVER`	Yes	Business Central API base URL	`https://api.businesscentral.dynamics.com/v2.0/{tenant}/Production/api/v2.0`
`BC_COMPANY`	Yes	Company display name	`KnowAll Ltd`
`BC_AUTH_TYPE`	No	Authentication type (default: `azure_cli`)	`azure_cli` or `client_credentials`
`BC_TENANT_ID`	For client_credentials	Azure AD tenant ID	`00000000-0000-0000-0000-000000000000`
`BC_CLIENT_ID`	For client_credentials	App registration client ID	`00000000-0000-0000-0000-000000000000`
`BC_CLIENT_SECRET`	For client_credentials	App registration client secret	`your-secret-value`

Getting Your Configuration Values

Tenant ID: Find in Azure Portal → Azure Active Directory → Overview
Environment: Usually Production or Sandbox
Company Name: The display name shown in Business Central

Example URL format:

https://api.businesscentral.dynamics.com/v2.0/00000000-0000-0000-0000-000000000000/Production/api/v2.0

Authentication

Recommendation: Use azure_cli authentication - it's simpler to set up and more reliable. The client_credentials method is also supported but has known configuration challenges with Business Central's Microsoft Entra Applications setup. See docs/TROUBLESHOOTING.adoc for details.

Option 1: Azure CLI (Recommended)

The simplest and most reliable authentication method. Uses your existing Azure CLI login.

Prerequisites:

Install Azure CLI: https://docs.microsoft.com/cli/azure/install-azure-cli
Login: az login
Verify access: az account get-access-token --resource https://api.businesscentral.dynamics.com

Configuration:

{
  "mcpServers": {
    "business-central": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@knowall-ai/mcp-business-central"],
      "env": {
        "BC_AUTH_TYPE": "azure_cli",
        "BC_URL_SERVER": "https://api.businesscentral.dynamics.com/v2.0/{tenant-id}/Production/api/v2.0",
        "BC_COMPANY": "My Company"
      }
    }
  }
}

Option 2: Client Credentials (Service-to-Service)

For automated systems that need to run without user interaction. This method uses OAuth 2.0 client credentials flow.

Note: This method has known configuration challenges. The Business Central "Microsoft Entra Applications" setup can be complex and the application user creation may not work as expected. See docs/TROUBLESHOOTING.adoc for detailed guidance.

Setup Overview:

Create Azure App Registration:
- Go to Azure Portal → Azure Active Directory → App registrations
- Create new registration (single tenant)
- Add API permission: Dynamics 365 Business Central → app_access (Application permission, NOT Delegated)
- Grant admin consent for the permission
- Add redirect URI: https://businesscentral.dynamics.com/OAuthLanding.htm
Generate Client Secret:
- In your app registration, go to Certificates & secrets
- Create a new client secret and save it securely
Configure Business Central:
- In Business Central, search for "Microsoft Entra Applications"
- Click + New and enter your app's Client ID
- Set a Description (this becomes the application user name)
- Set State to "Enabled" - you should see "A user named '[Description]' will be created"
- Add permission sets: D365 BUS FULL ACCESS (recommended) or D365 READ
- Leave Company field blank for all companies access
- Click "Grant Consent"
Verify Setup:
- The application user should appear in the Users list in Business Central
- If not, see docs/TROUBLESHOOTING.adoc for solutions

References:

Available Tools

1. `get_schema`

Get OData metadata for a Business Central resource.

Parameters:

resource (string, required): Resource name (e.g., customers, contacts, salesOpportunities)

Example:

{
  "resource": "customers"
}

2. `list_items`

List items with optional filtering and pagination.

Parameters:

resource (string, required): Resource name
filter (string, optional): OData filter expression
top (number, optional): Maximum number of items to return
skip (number, optional): Number of items to skip for pagination

Example:

{
  "resource": "customers",
  "filter": "displayName eq 'Contoso'",
  "top": 10
}

3. `get_items_by_field`

Get items matching a specific field value.

Parameters:

resource (string, required): Resource name
field (string, required): Field name to filter by
value (string, required): Value to match

Example:

{
  "resource": "contacts",
  "field": "companyName",
  "value": "Contoso Ltd"
}

4. `create_item`

Create a new item in Business Central.

Parameters:

resource (string, required): Resource name
item_data (object, required): Item data to create

Example:

{
  "resource": "contacts",
  "item_data": {
    "displayName": "John Doe",
    "companyName": "Contoso Ltd",
    "email": "john.doe@contoso.com"
  }
}

5. `update_item`

Update an existing item.

Parameters:

resource (string, required): Resource name
item_id (string, required): Item ID (GUID)
item_data (object, required): Fields to update

Example:

{
  "resource": "customers",
  "item_id": "1366066e-7688-f011-b9d1-6045bde9b95f",
  "item_data": {
    "displayName": "Updated Name"
  }
}

6. `delete_item`

Delete an item from Business Central.

Parameters:

resource (string, required): Resource name
item_id (string, required): Item ID (GUID)

Example:

{
  "resource": "contacts",
  "item_id": "a1b2c3d4-e5f6-g7h8-i9j0-k1l2m3n4o5p6"
}

Common Resources

companies - Company information
customers - Customer records
contacts - Contact records
salesOpportunities - Sales opportunities
salesQuotes - Sales quotes
salesOrders - Sales orders
salesInvoices - Sales invoices
items - Product/service items
vendors - Vendor records

Troubleshooting

See docs/TROUBLESHOOTING.adoc for detailed troubleshooting guides covering:

Authentication issues (401 errors, token problems)
client_credentials setup challenges and known issues
Company not found errors
Environment-specific configuration (Production vs Sandbox)

Development

# Install dependencies
npm install

# Build TypeScript
npm run build

# Watch mode for development
npm run dev

License

MIT

Contributing

Issues and pull requests welcome at https://github.com/knowall-ai/mcp-business-central

MCP Specification: modelcontextprotocol.io

Available Tools

6 tools

create_itemB

Create a new item in Business Central

ParametersJSON Schema

Name	Required	Description	Default
`resource`	Yes	The resource name (e.g., customers, contacts)
`item_data`	Yes	The item data to create

TDQS

B3.4/5.0

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 full burden of disclosing behavioral traits. It only states 'Create' with no mention of side effects, required permissions, idempotency, or return behavior. For a mutation tool, this lack of transparency is a significant gap.

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 with no filler or redundant phrasing. It is appropriately brief and front-loaded with the core action.

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 a mutation tool with a nested object parameter and no output schema, the description is insufficient. It does not explain what the tool returns, what fields are required in 'item_data', or how the resource parameter maps to actual Business Central entities. Sibling tools like get_schema may be needed to understand usage, but the description should provide more context.

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%, and both parameters have descriptions in the schema. The tool description adds no extra meaning beyond the schema, so it meets the baseline. The nested object parameter 'item_data' is unclear, but the schema already covers it.

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 uses a specific verb ('Create') and a resource ('item') with a clear scope ('in Business Central'), which clearly distinguishes it from sibling tools like update_item, delete_item, and list_items. The purpose is immediately unambiguous.

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 creating items, but it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. It is a one-line statement with no guidance on distinguishing from update/delete scenarios.

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

delete_itemB

Delete an item from Business Central

ParametersJSON Schema

Name	Required	Description	Default
`item_id`	Yes	The ID of the item to delete
`resource`	Yes	The resource name (e.g., customers, contacts)

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are present, so the description must convey behavior. It states the delete action but offers no detail about consequences (irreversibility, cascading deletions, permission requirements, or return value). This is a significant omission for a destructive operation.

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 with no filler. It is front-loaded with the action verb. While it is short, it effectively communicates the core purpose without waste.

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 simple parameters and a clear schema, but the description lacks important behavioral context for a delete operation, such as whether the delete is permanent or what the response contains. Given the absence of annotations and output schema, the description should provide more operational context, but the simplicity of the tool keeps it at an adequate level.

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 input schema fully describes both parameters (resource and item_id), achieving 100% coverage. The description adds no additional parameter semantics, but the baseline of 3 applies because the schema already carries the meaning.

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 uses a specific verb ('Delete') and names the target resource ('item from Business Central'). It clearly differentiates from sibling tools like create_item and update_item, and the schema confirms it operates on a single item by ID.

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 guidance is provided on when to use this tool instead of update_item or list_items. It doesn't mention prerequisites, such as whether the item must exist, or any exclusions. The description simply states the action without usage context.

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

get_items_by_fieldB

Get items matching a field value

ParametersJSON Schema

Name	Required	Description
`field`	Yes	The field name to filter by
`value`	Yes	The value to match
`resource`	Yes	The resource name (e.g., customers, contacts)

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description carries the burden of behavioral disclosure. It does not specify whether matching is exact, case-sensitive, or partial; nor does it describe pagination, limits, or error behavior. This leaves ambiguity about the tool's runtime behavior.

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 that wastes no words. It immediately conveys the core action and scope, earning full marks for 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?

For a tool with only three straightforward parameters and no output schema, the description is minimally sufficient. However, it lacks usage guidance and fails to clarify the ambiguity of 'matching' (e.g., exact vs. contains), leaving gaps for an agent attempting to use the tool correctly.

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?

All three parameters are fully described in the input schema (100% coverage), providing clear meaning for resource, field, and value. The description adds no extra semantics beyond the schema, so the baseline score 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 tool's function (get items) and its filtering mechanism (matching a field value). It implicitly distinguishes itself from list_items by focusing on field-based filtering, though it does not explicitly name the sibling alternative.

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 guidance is provided on when to use this tool versus alternatives like list_items. The description gives no context about typical use cases, preconditions, or exclusions.

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

get_schemaC

Get schema information for a Business Central resource

ParametersJSON Schema

Name	Required	Description	Default
`resource`	Yes	The resource name (e.g., customers, contacts, salesOpportunities)

TDQS

C2.9/5.0

Behavior2/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 behavioral disclosure. It only says 'Get schema information' but does not reveal whether this is a read-only operation, any required permissions, the return format, or error behavior. The term 'Get' implies read-only, but this is implicit, not explicit.

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, front-loaded with the verb and key object, with no extraneous information. It is efficient and immediately conveys the core purpose.

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 one parameter, no annotations, and no output schema, the description is too sparse. It fails to explain what schema information is returned, how to interpret it, or any edge cases. The description alone is insufficient for an agent to fully understand the tool's behavior.

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 input schema has 100% coverage with a clear description of the 'resource' parameter and examples. Since schema_description_coverage is high, the baseline is 3. The tool description adds no additional parameter semantics beyond what the schema already provides.

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 tool's function: 'Get schema information for a Business Central resource.' It uses a specific verb ('Get') and names the resource, distinguishing it from sibling CRUD tools like list_items and update_item. However, it lacks specific detail on what 'schema information' includes, so it's not as clear as it could be.

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, no prerequisites, and no exclusions. It merely states what the tool does without contextualizing its usage within the sibling tool set.

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

list_itemsA

Get items from Business Central with filtering and pagination

ParametersJSON Schema

Name	Required	Description
`top`	No	Maximum number of items to return (optional)
`skip`	No	Number of items to skip for pagination (optional)
`filter`	No	OData filter expression (optional)
`resource`	Yes	The resource name (e.g., customers, contacts, salesOpportunities)

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, the description bears the burden of behavioral disclosure. It conveys that this is a read operation with filtering and pagination, but omits details like default page size, response format, or error behavior. 'Get' safely implies a read-only action, so there is no contradiction.

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 filler. Every word adds meaning, making it highly concise and well-structured.

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?

For a simple list tool with good schema coverage, the description is adequate: it names the resource and mentions filtering/pagination. However, there is no output schema and no differentiation from get_items_by_field, leaving some contextual gaps.

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 input schema already describes all four parameters with 100% coverage, so the description adds little beyond restating filtering and pagination. This meets the baseline for schema-heavy parameter documentation.

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 tool gets items from Business Central and mentions filtering and pagination, giving a specific verb and resource. However, it does not differentiate from the sibling tool get_items_by_field, so it stops short of a 5.

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 when a filtered or paginated list of items is needed, but it provides no explicit exclusions or references to alternative tools. With get_items_by_field as a sibling, some guidance on when to choose one over the other would be valuable.

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

update_itemC

Update an existing item in Business Central

ParametersJSON Schema

Name	Required	Description
`item_id`	Yes	The ID of the item to update
`resource`	Yes	The resource name (e.g., customers, contacts)
`item_data`	Yes	The item data to update

TDQS

C2.9/5.0

Behavior2/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 behavioral disclosure. It only says 'update,' which implies mutation, but omits critical details such as whether it performs a partial or full replacement, error handling for non-existent items, permission requirements, or return values. This is a significant gap 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, direct sentence with no filler words. It is front-loaded with the action verb and resource, making it easy to scan. It earns its place despite being minimal.

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 a nested object parameter, three required fields, and no output schema, the one-line description is insufficient. It fails to explain update semantics (partial vs. replace), response format, or error conditions. With no annotations to fill gaps, the tool is under-specified for an agent to fully anticipate behavior.

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 input schema has 100% description coverage for all three parameters, providing basic semantics (e.g., item_id is the ID, item_data is the data to update). The tool description adds no further meaning about parameter usage, such as how item_data is structured or whether it is a partial update. Since the schema already covers baseline semantics, the description neither helps nor harms.

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 'Update an existing item in Business Central' clearly states the action (update) and the target (item), and the mention of 'existing' distinguishes it from create_item. However, it is somewhat generic, lacking specificity about what 'item' refers to beyond the schema's resource parameter, which slightly reduces clarity.

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 guidance is provided on when to use this tool versus alternatives like create_item or delete_item. The description does not mention prerequisites, such as the item needing to exist, or suggest checking get_schema for valid fields. This leaves the agent without clear context for selection.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv0.1.4Aug 7, 2026
- First observedcreate_item
- First observeddelete_item
- First observedget_items_by_field
- First observedget_schema
- First observedlist_items
- First observedupdate_item

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Disambiguation4/5

Most tools have clearly distinct purposes, but list_items and get_items_by_field both retrieve items and could be confused. The descriptions differentiate them (broad listing vs. field-specific lookup), so the overlap is minor.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern (get_schema, list_items, create_item, etc.). This makes the tool set predictable and easy to navigate.

Tool Count5/5

With 6 tools, the set is well-scoped for item management plus schema access. Each tool serves a distinct function without redundancy or excessive bloat.

Completeness4/5

The set provides full CRUD coverage for items (create, read/update/delete) and adds schema inspection. Missing a direct get_item by ID, but list_items with filtering likely covers that use case. The scope is item-focused rather than covering all Business Central resources, but that seems intentional.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Apideck MCP A
dev.apideck.mcp
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Developer Tools
42
Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
OneSchema MCP Server
co.oneschema
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
Data Platforms App Automation
1
codat A
io.usefulapi
MCP server for Codat — companies, connections, invoices, bills and financial statements.
Finance ERP Systems Data Platforms
282

Related MCP Servers

Dynamics 365 MCP Server
Databases App Automation Search
srikanth-paladugula
A
license
B
quality
D
maintenance
A Model Context Protocol server that enables interaction with Microsoft Dynamics 365 CRM from Claude Desktop, allowing users to retrieve, create, and update CRM data through natural language.
Updated a year ago (2025-04-19 18:36 UTC)
5
21
MIT
Microsoft Business Central MCP
ERP Systems CRM
MehrozeKhan73
A
license
A
quality
C
maintenance
MCP server for Microsoft Dynamics 365 Business Central that enables AI assistants to query and manage Business Central data via full CRUD operations.
Updated a month ago (2026-07-27 23:22 UTC)
6
30
MIT
Microsoft Business Central MCP
ERP Systems CRM
EdwardHayes91
A
license
B
quality
C
maintenance
MCP server for Microsoft Dynamics 365 Business Central, enabling AI assistants to perform CRUD operations, query data, and retrieve schemas via Business Central API v2.0.
Updated a month ago (2026-08-10 15:47 UTC)
6
30
MIT
business-central-mcp
ERP Systems
keithdev21
A
license
A
quality
C
maintenance
MCP server that provides AI assistants direct access to Microsoft Dynamics 365 Business Central using its native WebSocket protocol, enabling page navigation, data operations, actions, and report execution without OData or browser automation.
Updated a month ago (2026-08-10 15:06 UTC)
14
57
MIT

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/knowall-ai/mcp-business-central'

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

Microsoft Business Central MCP Server

Features

Installation

Using npx (Recommended)

Using Smithery

Local Development

Configuration

Environment Variables

Getting Your Configuration Values

Authentication

Option 1: Azure CLI (Recommended)

Option 2: Client Credentials (Service-to-Service)

Available Tools

1. get_schema

2. list_items

3. get_items_by_field

4. create_item

5. update_item

6. delete_item

Common Resources

Troubleshooting

Development

License

Contributing

Related Projects

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

1. `get_schema`

2. `list_items`

3. `get_items_by_field`

4. `create_item`

5. `update_item`

6. `delete_item`