Beglaubigt

Create a German GmbH/UG incorporation

create_incorporation

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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`incorporation`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`url`	Yes
`status`	Yes
`message`	No
`incorporation_id`	Yes

TDQS

A4.9/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All Beglaubigt tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0

Disambiguation5/5

Only one tool exists, so there is no risk of selecting between overlapping tools. The tool's purpose is clearly defined.

Naming Consistency5/5

Single tool named with clear verb_noun pattern (create_incorporation), which is consistent and conventional.

Tool Count3/5

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.

Completeness4/5

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.

Resources

Need Help?