The MCP tools of btlabs Core combine a language model with content and limited system functions in a controlled manner: The language model can suggest a tool call, the MCP client manages permissions and access, and the MCP server executes the authorized call. Crucially, it is not only the technical availability that matters, but also which tool has been authorized for which client, role, and purpose.
The Model Context Protocol (MCP) standardizes the connection between applications with language models and external data or functions. In btlabs Core, MCP tools are designed to reduce repetitive work without unintentionally triggering releases, rights changes, or other consequential decisions.
An entry in the tool catalog is a technical offering. Only a suitable rights class, a permissible purpose, and a documented release status make the actual use of the tool operationally permissible.
MCP tools in btlabs Core: Roles and workflow
The MCP architecture distinguishes between host, client, and server. In the specification version used, dated July 28, 2026, the host coordinates the clients and security rules. Each MCP client communicates with a specific MCP server, while the server provides tools and other functions.
- Language model: The model interprets the task and can suggest a suitable tool. The language model does not provide the tool and does not grant any permissions.
- Host: The application coordinates the language model, MCP clients, user interaction, and security rules.
- MCP Client: The client connects the host to an MCP server, processes the visible tool catalog, and transmits permitted calls.
- MCP server: The server provides defined MCP tools and executes calls within the granted permissions.
- Responsible person: Humans assess sensitive or consequential actions and either approve or refuse their execution.
A controlled call proceeds in seven steps:
- A user or the language model suggests a task.
- The MCP client queries with tools/list the tools visible in the current context.
- The client checks the client, role, rights class, purpose, and release status.
- For actions requiring approval, the host requests human authorization.
- The MCP client sends the confirmed call with tools/call to the MCP server.
- The MCP server executes the tool and returns a result or an error.
- The call, result, version status and release decision are documented in the audit log.
The operational context must be established through unique identities, roles, client information, parameters, and permissions. Previous permission must not automatically be considered permission for a subsequent request.
Reference status of the btlabs MCP tool catalog
A reliable MCP tool catalog for btlabs Core must be generated directly from the deployed implementation. While the company data specifies a technical endpoint for tools, it does not contain a verified export with tool names, permissions, and version information. Therefore, this article does not provide a fixed total number or list unconfirmed names of supposedly implemented btlabs MCP tools.
- Product: btlabs Core
- Product version: not shown in the present data set
- Tool catalog version: not shown in the present data set
- Technical export deadline: not shown
- Responsible technical review: not shown
- Individually validated MCP tool names: Documentation is not possible without a verified server export.
Until such an export is available, the article describes a governance and documentation model. The functional areas mentioned do not constitute a commitment to individual MCP endpoints.
Mandatory information for each real tool
Each entry in the MCP tool catalog should contain at least the following information:
- Technical name: Unique name for tools/call
- Operational task: understandable description of the specific purpose
- Data scope: accessible content, fields, or system states
- Rights class: Reading, writing, executing, or managing
- Release status: automatically permitted, subject to consent, restricted or disabled
- External impact: possible publication, communication, data sharing or system change
- Client relationship: clearly defined data and authorization space
- Version: Product version and tool definition version
- Deadline: Date of last technical inspection
I explain the technical structure of the central content and data repository in the article about the architecture of btlabs Core . The shared database is designed to prevent the website, language versions, and machine-readable output from using different company information.
Internal functions are not automatically MCP tools.
An internal system function, a user interface, and a tool accessible via MCP are three different things. Therefore, a function may only be designated as an available MCP tool when the current server catalog lists its technical name, parameters, and release status.
Designate as an MCP tool only after technical verification.
- Reading a specific content record via a named MCP call
- Creating or updating a non-public draft
- Checking related language versions
- Performing an SEO, GEO, or completeness check
- Querying a release status or audit log
- Triggering a publishing or management process
Prepared expansion stages do not constitute a current product commitment.
- Booking AI agents
- Shop and inventory functions
- protected customer areas
- Live price calculator and appointment display
- Apps or other locations based on the same data
A technically prepared function is neither automatically activated nor released. The specific project, the implementation, and the current tool catalog remain decisive.
tools/list displays tools, but does not grant permissions
The `tools/list` command queries the tools offered by the MCP server. The MCP tool specification allows the visible scope to depend on the submitted authorization and the granted permissions.
For btlabs Core, `tools/list` should only return those MCP tools that the current tenant and role are authorized to see. Whether a specific installation already filters accordingly must be confirmed by a technical test on the documented cut-off date.
tools/list answers the question: "Which tools are offered to me?" The answer does not automatically grant permission for every possible effect of these tools.
The `tools/call` command sends the tool name and required arguments to the MCP server. Before execution, the identity, client, permission class, and release status must match the planned call.
Four MCP privilege classes for btlabs Core
The four MCP rights classes are an operational governance model for btlabs Core. The MCP specification does not define these classes as normative authorization levels.
- Read: Search, view, compare and review content without changing data or conditions.
- Write: Create drafts, update fields, or change assignments. This right does not automatically include publication or deletion.
- Carry out: to start a limited process such as an inspection or a reversible processing step.
- Administer: Change roles, rights, exports, global settings, or system-wide states.
Permissions are granted according to the principle of least privilege : A user, service, or agent receives only the rights necessary for a clearly defined task. The permission applies to a specific client, defined data areas, and, where possible, a limited time period.
My work with small businesses regularly shows that overly broad default roles create more risk than clearly defined tools. An editorial process doesn't become more secure simply by granting all participants administrative rights as a precaution.
Client separation protects data and responsibilities.
Client separation prevents a tool from mixing data from different companies, websites, or organizational units. An MCP call for Company A must not see content from Company B, nor use its shares or logs.
- Each request requires a unique client identity.
- Roles and rights are assigned on a client-specific basis.
- Data access and protocols remain separate.
- Previous approvals may not be transferred to a different client context.
- The call will be aborted if there is a conflicting client or role reference.
A common user interface must not weaken the security boundaries of individual companies.
Which MCP tools require human approval?
The MCP tool specification used does not mandate a specific interaction model. However, it recommends visible tool calls, confirmation dialogs, and a human user with the option to decline. For btlabs Core, this results in a stricter operational model for consequential actions.
Human approval is still required for:
- Publications: Content becomes publicly visible.
- Final deletions: Data can be lost and links can break.
- Rights changes: The security framework for subsequent calls is changing.
- Exports: Data may leave the intended processing area.
- External communication: Emails, offers, or bookings can have business consequences.
- System-wide interventions: Global changes can affect multiple content, languages, or websites.
The authorization must specify which tool processes which data and with what expected effect. A blanket permission without purpose, scope, and validity period is insufficient.
What an audit log should document
An audit log makes tool calls, errors, and release decisions traceable. The log should only record information necessary for security, error analysis, and accountability.
- Identity: triggering user, service or agent
- Client: affected data and area of responsibility
- Tool: Technical name and tool version
- Time: Start, end and duration of the call
- Rights class: used authorization level
- Release status: approved, confirmed, rejected, or expired
- Parameter: Required input data in a data-minimizing form
- Result: Change, return, cancellation or error
- Release decision: responsible person and time
- Version: Version of btlabs Core and tool catalog
Passwords, access tokens, security keys, and unnecessary personal data do not belong in the audit log. Traceability and data minimization must be planned together.
Practical example: Controlled updating of multilingual content
Previous: Changes were transferred multiple times
A small tourism business is updating its opening hours and service descriptions in German and Italian. An employee searches for the relevant pages, transfers each change individually, and checks metadata and language links. It's possible that outdated information may remain in one language version.
Afterwards: review, save as draft and release
- The employee selects the content and the eligible client.
- The MCP client uses tools/list to retrieve the MCP tools visible to the editorial role.
- A validated reading tool compares the German and Italian content.
- The language model highlights potential inconsistencies and suggests changes.
- A writing tool creates exclusively non-public drafts.
- A verification tool checks facts, language relationships, metadata, and mandatory fields.
- The employee receives a change list with the initial value and the proposed value.
- Only after human approval does the MCP client send the valid tools/call call to the MCP server.
- The tool, change, release and result are documented in the audit log.
Error case and reset
If the MCP server returns an error or the staff member detects an incorrect change, the publication is stopped. The draft remains separate from the last valid public version.
The responsible editor corrects the draft or reverts it to the previous version. The error status and reversion are logged. Time is saved through prepared searches, comparisons, and drafts – not through unchecked publications.
Introduce MCP tools with minimal privileges
I don't recommend immediate full access for small businesses. A limited pilot project will show whether the tool, data quality, and responsibilities are a good fit.
- Limit the task: Choose a clear use case, such as comparing two language versions.
- Start reading: Initially, only allow searching, retrieving, and comparing selected content.
- Define client area: Limit the test to one website or content area.
- Check results: Compare the tool output with the actual source data.
- Specifically add writing permissions: Only allow non-public drafts after that.
- Test release: Simulate publication, rejection, errors, and rollback.
- Check permissions: Remove any unused roles and expired access credentials.
The practical guide for AI guidelines in SMEs helps you to regulate responsibilities and permissible data beyond individual tool calls.
Status information in the MCP tool catalog
- Accessible: The tool is implemented in the documented version, activated for the client, and usable with the assigned role.
- Limited availability: The tool requires additional configuration, rights class, or human approval.
- disabled: The tool is not offered to the client or MCP client in question.
- Prepared expansion stage: The architecture can accommodate a future function; currently, the function is neither available nor promised.
A release status without a version number is incomplete. Status, tool version, and release date should always be documented together.
Selection guide for MCP tools
Before activating a tool, you should answer the following questions:
- Purpose: What specific operational bottleneck does the tool solve?
- Data: What content or personal data can the tool process?
- Client: For which defined data space does the access apply?
- Rights class: Is reading sufficient, or are further rights required?
- External impact: Can the request publish, communicate, export, or modify rights?
- Retrievability: Can a faulty action be completely undone?
- Release: Who is responsible?
- Logging: What information appears in the audit log?
- Version reference: For which product and tool version was the process tested?
If a question remains unanswered, the tool should remain deactivated or initially be used with read-only access in a test environment. Therefore, when advising on AI and digitalization, we examine not only the technical connection but also the purpose, data quality, responsibility, and reversibility.
Questions about the MCP tool catalog from btlabs Core
What are MCP tools?
MCP tools are structured functions that an MCP server offers to a compatible MCP client. A tool can read data, edit a design, or execute a limited process, provided the role and release status permit the invocation.
Who technically executes an MCP call?
The language model can suggest the use of a tool, but it does not execute the system action itself. The MCP client submits the valid call; the MCP server executes the provided tool.
Does tools/list already have a permission?
No. `tools/list` displays the tools that the server returns for the current context. Additional privileges or human approval may be required for a specific `tools/call` call.
Does tools/list always see the complete server catalog?
The MCP specification allows limiting the visible scope based on authorization. Whether a specific btlabs Core installation filters by client and role must be confirmed by a technical test on the documented cut-off date.
Which actions require human approval?
Publications, permanent deletions, rights changes, sensitive exports, external communication, and system-wide interventions remain subject to approval. The decision must be assigned to a responsible person and documented in the audit log.
How do I identify the current version?
A reliable entry specifies the product version, tool catalog version, tool version, release status, and effective date. If this information is missing, the entry is not a reliable, up-to-date product reference.
What happens if there's a mistake?
The MCP server returns an error; dependent write or publish steps are stopped. Reversible changes are rolled back to the last valid state by the responsible role and logged.
Is an agent allowed to expand their own rights?
No. An agent may neither change its privilege class nor bypass approval steps or client boundaries. Privilege changes fall under the Manage class and require a separate human decision.
Why doesn't the article specify a fixed number of MCP tools?
A reliable number must be derived from the actual, version-specific tool catalog. Without a verified server export, a static number would conflate available, disabled, and prepared functions.
Conclusion: MCP tools require verified permissions.
A good MCP tool catalog doesn't just document technical names. The catalog shows who is allowed to use a tool, for what purpose, with which data, under which permission class, and according to which release rules.
For small businesses, controlled automation makes more sense than unrestricted autonomy. btlabs Core is designed to reduce search, verification, and data transfer efforts, while ensuring that sensitive decisions remain with the responsible people within the company. You can find more information on the page about AI-ready websites with btlabs Core.
