Beglaubigt
Server Details
Incorporate a German GmbH or UG in chat, then finish and pay on a secure link.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.9/5 across 1 of 1 tools scored.
Only one tool exists, so there is no risk of selecting between overlapping tools. The tool's purpose is clearly defined.
Single tool named with clear verb_noun pattern (create_incorporation), which is consistent and conventional.
With only one tool, the server is very focused. It is borderline thin, but the tool itself is complex and handles a complete incorporation flow, so the count is appropriate for a small, single-purpose MCP server.
The tool covers the full creation of an incorporation case, including all required parameters and conditions. However, there are no tools for retrieving, updating, or listing existing cases, which is a minor gap for a complete lifecycle.
Available Tools
1 toolcreate_incorporationCreate a German GmbH/UG incorporationAInspect
Create a German GmbH/UG incorporation case and return a secure Beglaubigt link where the founder provides their remaining personal details (date of birth, nationality, home address) and pays. The agent NEVER handles payment and NEVER asks for date of birth, nationality, or a person's home address in chat — those are collected only on the returned page. Collect in chat: the company (legal_form 'gmbh'|'ug', full name INCLUDING the legal-form suffix e.g. 'Velocent UG (haftungsbeschränkt)', purpose, capital, registered address and business_address), the notarization (its type — 'online' or 'offline' — is REQUIRED and has no default; optional express boolean; optional preferred_timeframe of 7, 14 or 30), the ownership structure (each shareholder's share_percentage and whether they are a managing director), and — for the first (founder) shareholder only — their first_name and email so Beglaubigt can send the completion link (tell the founder you will share their email with Beglaubigt for this). Share capital must be a whole number of euros and meet the legal minimum: GmbH at least 25000, UG at least 1. Share percentages must total 100. At least one shareholder must be a managing director, or a separate director must be included. Musterprotokoll (the standard template) supports at most 3 shareholders and exactly one managing director. Leave documents unset: Beglaubigt derives the articles type from the structure you send — one director with 1–3 shareholders gets the Musterprotokoll, anything larger gets individual (custom) articles. A notarization preferred_timeframe, if provided, must be 7, 14, or 30. Governance terms apply only when the derived articles are individual; Beglaubigt ignores them for a Musterprotokoll. You may optionally set: shareholders_meeting_quorum, shareholders_resolution_majority, significant_transactions_majority (percentages 0–100), representation_type ('joint' | 'sole' | 'section181'), majority_type ('simple' | 'two_thirds' | 'unanimous'), and notice_period_months. The optional additional_services field just records which follow-up options the founder wants information about later. It is non-binding: including it orders nothing, enrols the founder in nothing, and adds no charge — the link covers the one-time incorporation fee only. Recognised values: 'authority-registrations', 'business-liability-insurance', 'trademark-registration', 'bookkeeping', 'tax-advisor-support', 'business-address'. package (set at incorporation.package) is REQUIRED by this tool and sets the price shown on the completion page. The tiers are 'simple' | 'standard' | 'priority'. Ask the founder which one they want and send their answer — never choose for them. There is no package step on the completion page, so if you do not ask, the founder is never asked at all. Read the packages://incorporation resource for each tier's scope and structural limits, and tell the founder that exact prices depend on the partner tenant and are shown on the completion page before they pay — do not quote a figure yourself. Omitting the package is refused before anything is created, because omission silently bills the middle tier. Calls are NOT idempotent: every successful call creates a new incorporation case. When collecting these details, gather them conversationally across turns — one field at a time for each person — instead of asking for everything in a single message; call this tool only once all details are confirmed.
| Name | Required | Description | Default |
|---|---|---|---|
| incorporation | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| status | Yes | |
| message | No | |
| incorporation_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the annotations by explicitly stating that calls are not idempotent, that omitting the package silently bills the middle tier, and that additional_services is non-binding with no charge. This provides deep insight into side effects and edge cases not captured by the structured hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very long, but every sentence carries operational significance. However, it is organized as one dense paragraph with semicolons, which can make it harder to parse quickly. Clearer formatting (bullet points or sections) would improve readability, so it loses one point for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's high complexity, the description is remarkably complete. It covers the entire collection workflow, legal prerequisites, governance terms, article derivation, payment handling, and return link. The existence of an output schema reduces the need to describe return values, and the description fills all other contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is a complex single nested object with 0% description coverage in the schema itself. The description compensates thoroughly by explaining required vs optional fields, constraints (capital minimums, share total, Musterprotokoll limits), and providing concrete examples (e.g., name suffix, package tiers). This is a strong value-add beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('create'), the resource ('German GmbH/UG incorporation case'), and the output (a secure Beglaubigt link). It also establishes the exact scope of what the tool does and differentiates itself from any possible sibling by describing the unique workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers explicit guidance on when to call the tool ('only once all details are confirmed'), what to collect in chat versus on the secure page, and what the agent must never do (handle payment, ask for sensitive personal data in chat). It also explains the package selection procedure and the consequences of omitting it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Servers
- Flicense-qualityCmaintenanceAgentBureau provides the legal and physical infrastructure for AI agents to operate within the German jurisdiction. We bridge the gap between digital intelligence and real-world action by providing "Embodiment-as-a-Service." Through our API, agents can perform legally binding actions—like sending faxes, mailing physical letters, issuing invoices, forming entire companies (GmbH/UG), ...Last updated1
- Alicense-qualityBmaintenanceEnables AI agents to accept payments in Germany through Mollie's hosted checkout, supporting cards, PayPal, Klarna, SEPA, and more.Last updatedMIT
- FlicenseBqualityDmaintenanceMCP server for DACH accounting automation. Connect AI assistants to sevDesk and Lexoffice — create invoices, manage contacts, handle bookings and vouchers for German-speaking businesses.Last updated1544
- AlicenseAqualityBmaintenanceEnables AI agents to search and retrieve structured data from the German Commercial Register, including company details, filed documents, and shareholder lists.Last updated7Apache 2.0