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 List all customers with outstanding balances" 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 keithdev21

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: Dynamics 365 Business Central Admin 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_itemC

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

C2.9/5.0

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.

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.1/5.0

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.

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.2/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 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.

get_schemaB

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

B3.2/5.0

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.

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

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.

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?

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.

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 10, 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

B3.4/5.0

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.

Maintenance

ActivityMaintained

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

PlixanaOAuth
com.plixana
Operate the Plixana CRM from any AI: contacts, deals, quotes, WhatsApp and metrics.
CRM Communication
2
mcpOAuth
com.vibgrate
Query your team's drift, vulnerability, and upgrade data from any AI assistant. OAuth 2.1, 51 tools.
Security Monitoring
2
HubSpotOAuth
com.hubspot.app
The HubSpot MCP Server acts as a bridge that enables AI assistants and Large Language Models to securely interact with HubSpot CRM data through natural conversation, without requiring users to understand complex API structures. It provides read-only access to standard CRM objects (contacts, companies, deals, tickets, products, invoices, and more) and their associations, secured via OAuth 2.0, allowing AI agents to perform tasks like summarizing deals, fetching company updates, and looking up record changes.
Customer Data Platforms Databases Marketing
3
AXL MCP AOAuth
tech.axl.app
AXL MCP lets AI assistants create and manage landing pages, courses, email campaigns, CRM records, and marketing workflows inside AXL. Built for growing expert businesses, it turns chat requests into real work across sales, marketing, and course delivery. An AXL account is required. Sign in securely with OAuth 2.1. Website: https://axl.tech/developers/mcp . Setup guide: https://docs.axl.tech/mcp . Watch AXL in 77 seconds: pages, courses, CRM, and automation. Product overview: https://www.youtube.com/watch?v=jlhR9CafIww
CRM Education & Learning Tools Marketing
161

Related MCP Servers

Business Central MCP Server
ERP Systems Databases App Automation
javiarmesto
F
license
Not graded
quality
D
maintenance
Enables AI clients to interact with Microsoft Dynamics 365 Business Central through MCP, providing access to customers, items, sales orders, and allowing creation of new records via natural language.
Updated a year ago (2025-07-07 08:34 UTC)
2
-
Dynamics 365 Business Central
Cloud Platforms ERP Systems
demiliani
A
license
Not graded
quality
D
maintenance
Enables AI assistants to manage Dynamics 365 Business Central environments through natural language commands, including environment, app, session, and extension management.
Updated 6 months ago (2026-03-16 23:44 UTC)
18
9
MIT
business-central-mcp-server
ERP Systems Cloud Platforms
user-vik
A
license
Not graded
quality
B
maintenance
Exposes Dynamics 365 Business Central data to MCP clients via standard v2.0 API or custom AL APIs, supporting read, write, and destructive operations with multiple authentication modes.
Updated 3 days ago (2026-09-02 23:38 UTC)
15
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

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

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`