Skip to main content
Glama

Register Account

register

Konto anlegen — zwei Wege. WEG 1, AGENT (kein Postfach, kein Mensch noetig): register mit agent=true + accept_terms=true. Adresse und Passwort erzeugt die Plattform; beide kommen EINMALIG in der Antwort (username, password), damit meldest du dich per login an. Die Rolle 'member' ist sofort aktiv, keine Mail, kein activate. Ein optionaler invite_code wird sofort uebernommen (gilt die Drossel: 10 Fehlversuche je IP und Stunde, dann 429); ohne Code bist du voellig isoliert (keine Mitgliedschaft, keine fremden Scopes) — Zugang spaeter per redeem_invite_code oder Service Request. KEIN Startguthaben: das Konto startet mit 0 Credits und bezahlt sich selbst — onto_credit_checkout (Karte) oder onto_credit_chargeup (prepaid_code). WEG 2, MENSCH: register mit username (E-Mail), password, password_confirm; dann Aktivierungscode per Mail, danach activate. WICHTIG: mit accept_terms=true bestaetigst du die Nutzungsbedingungen (https://www.telesherpa.com/agb). Nach der Registrierung hast du zwei Wege: (a) einem fremden Scope beitreten (invite_code an redeem_invite_code) oder (b) selbst etwas bauen (ontouser_scope_create) und danach mit create_invite_code Einladungscodes erzeugen, um Menschen und andere Agenten in deinen Scope zu holen. Zugangsdaten kommen NUR EINMAL: username/password sofort dauerhaft speichern (Datei chmod 600 oder Secret-Store) — wer sie nur im Kontext behaelt, steht beim naechsten Start ohne Konto da, und eine Neuregistrierung ist ein neues, leeres Konto. Nach dem login zusaetzlich den refresh_token (30 Tage) ablegen: der holt neue Access-Tokens (10 h) ohne Passwort. Vier Wege zu Guthaben oder Zugang, je mit Werkzeugnamen: (a) EINLADUNG — invite_code bei register oder spaeter redeem_invite_code (Zugang zu einem fremden Scope, kein Guthaben); (b) SELBST ZAHLEN — onto_credit_checkout (gehostete Zahlseite, Karte); (c) PREPAID — onto_credit_chargeup mit prepaid_code; (d) IDEE — ontouser_service_request (kostenlos): beschreibe, was du bauen willst, die Administratoren pruefen es und schicken bei Gefallen einen Prepaid-Code — dieser Weg haengt an der Idee, nicht am Zugang zu einer Kreditkarte. | EN: account, signup, onboarding, self-registration, agent, register

Input Schema

NameRequiredDescriptionDefault
agentNoWEG 1 ohne Einladungscode: true = sofort selbst registrieren (kein Postfach, kein Mensch). Das Konto ist danach isoliert — keine Mitgliedschaft, keine fremden Scopes. Nicht mit username/password kombinieren.
notesNoOPTIONAL, BEST EFFORT: ein Satz zum Zweck ('Belege lesen fuer Steuerkanzlei'). Das ist die normale Notiz, NICHT die interne Admin-Notiz. Spaeter aenderbar mit change_profile.
phoneNoOPTIONAL, BEST EFFORT: Telefon des verantwortlichen Menschen (Freitext, keine Normalisierung) — der Kontaktweg im Zweifel. Nur eintragen, wenn du sie kennst; niemals ausdenken.
passwordNoWEG 2: Passwort
usernameNoWEG 2 (Mensch): E-Mail-Adresse fuer die Registrierung (Aktivierungscode kommt dorthin — der Mensch kann ihn vorlesen, IMAP nicht noetig)
displaynameNoOPTIONAL, BEST EFFORT (Selbstauskunft, ungeprueft): Anzeigename des Kontos, z. B. 'Buchhaltungs-Agent Mueller GmbH'. Erscheint in Mitgliederlisten und Logs. Nimm, was du wirklich weisst — erfinde nichts, unbekannt darf leer bleiben. Blockiert nie.
invite_codeNoWEG 1 (Agent), optional: Einladungscode von deinem Auftraggeber. Adresse und Passwort erzeugt die Plattform, sie kommen einmalig in der Antwort zurueck. Kein Postfach, keine Mail, kein activate. Die Scope-Rechte des Codes werden sofort uebernommen; ohne Code bleibt das Konto isoliert. Nicht mit username/password kombinieren.
accept_termsYesPflicht in beiden Wegen. Mit true bestaetigst du die Nutzungsbedingungen (https://www.telesherpa.com/agb). Ohne Zustimmung wird kein Konto angelegt. Lies sie, bevor du zustimmst.
organisationNoOPTIONAL, BEST EFFORT: Firma/Organisation deines Auftraggebers oder Betreibers. Nicht raten; leer lassen, wenn unbekannt.
password_confirmNoWEG 2: Passwort-Wiederholung (muss identisch sein)
accept_managementNoNur in WEG 1 mit einem Verwaltungs-Code (kind=management): true = ausdrueckliche Zustimmung, dass dieses Konto kuenftig von dem Unternehmen verwaltet wird (Profilfelder, Rechte, Schreibziel, Guthaben, Sperre, Offboarding; das Passwort ausdruecklich NICHT). Ohne diesen Wert antwortet der Server mit 400 und einer Warnung, die die Rechte auflistet — so bleibt die Zustimmung eine bewusste Entscheidung.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / accept_management
      Added value: +{
      +  "description": "Nur in WEG 1 mit einem Verwaltungs-Code (kind=management): true = ausdrueckliche Zustimmung, dass dieses Konto kuenftig von dem Unternehmen verwaltet wird (Profilfelder, Rechte, Schreibziel, Guthaben, Sperre, Offboarding; das Passwort ausdruecklich NICHT). Ohne diesen Wert antwortet der Server mit 400 und einer Warnung, die die Rechte auflistet — so bleibt die Zustimmung eine bewusste Entscheidung.",
      +  "type": "boolean"
      +}
  2. Changed4 schema fields changed
    • addedInput schema / properties / displayname
      Added value: +{
      +  "description": "OPTIONAL, BEST EFFORT (Selbstauskunft, ungeprueft): Anzeigename des Kontos, z. B. 'Buchhaltungs-Agent Mueller GmbH'. Erscheint in Mitgliederlisten und Logs. Nimm, was du wirklich weisst — erfinde nichts, unbekannt darf leer bleiben. Blockiert nie.",
      +  "type": "string"
      +}
    • addedInput schema / properties / notes
      Added value: +{
      +  "description": "OPTIONAL, BEST EFFORT: ein Satz zum Zweck ('Belege lesen fuer Steuerkanzlei'). Das ist die normale Notiz, NICHT die interne Admin-Notiz. Spaeter aenderbar mit change_profile.",
      +  "type": "string"
      +}
    • addedInput schema / properties / organisation
      Added value: +{
      +  "description": "OPTIONAL, BEST EFFORT: Firma/Organisation deines Auftraggebers oder Betreibers. Nicht raten; leer lassen, wenn unbekannt.",
      +  "type": "string"
      +}
    • addedInput schema / properties / phone
      Added value: +{
      +  "description": "OPTIONAL, BEST EFFORT: Telefon des verantwortlichen Menschen (Freitext, keine Normalisierung) — der Kontaktweg im Zweifel. Nur eintragen, wenn du sie kennst; niemals ausdenken.",
      +  "type": "string"
      +}
  3. Changed2 schema fields changed
    • addedInput schema / properties / agent
      Added value: +{
      +  "description": "WEG 1 ohne Einladungscode: true = sofort selbst registrieren (kein Postfach, kein Mensch). Das Konto ist danach isoliert — keine Mitgliedschaft, keine fremden Scopes. Nicht mit username/password kombinieren.",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / invite_code / description
      Previous value: -"WEG 1 (Agent): Einladungscode von deinem Auftraggeber. Adresse und Passwort erzeugt die Plattform, sie kommen einmalig in der Antwort zurueck. Kein Postfach, keine Mail, kein activate. Zugang und Startguthaben kommen mit dem Code. Nicht mit username/password kombinieren."New value: +"WEG 1 (Agent), optional: Einladungscode von deinem Auftraggeber. Adresse und Passwort erzeugt die Plattform, sie kommen einmalig in der Antwort zurueck. Kein Postfach, keine Mail, kein activate. Die Scope-Rechte des Codes werden sofort uebernommen; ohne Code bleibt das Konto isoliert. Nicht mit username/password kombinieren."
  4. Changed1 schema field changed
    • changedInput schema / properties / invite_code / description
      Previous value: -"WEG 1 (Agent): Einladungscode von deinem Auftraggeber. Adresse und Passwort erzeugt die Plattform, sie kommen einmalig in der Antwort zurueck. Kein Postfach, keine Mail, kein activate. Nicht mit username/password kombinieren."New value: +"WEG 1 (Agent): Einladungscode von deinem Auftraggeber. Adresse und Passwort erzeugt die Plattform, sie kommen einmalig in der Antwort zurueck. Kein Postfach, keine Mail, kein activate. Zugang und Startguthaben kommen mit dem Code. Nicht mit username/password kombinieren."
  5. Changed6 schema fields changed
    • changedInput schema / properties / accept_terms / description
      Previous value: -"Pflicht. Mit true bestaetigst du die Nutzungsbedingungen (https://www.telesherpa.com/agb). Ohne Zustimmung wird kein Konto angelegt. Lies sie, bevor du zustimmst."New value: +"Pflicht in beiden Wegen. Mit true bestaetigst du die Nutzungsbedingungen (https://www.telesherpa.com/agb). Ohne Zustimmung wird kein Konto angelegt. Lies sie, bevor du zustimmst."
    • addedInput schema / properties / invite_code
      Added value: +{
      +  "description": "WEG 1 (Agent): Einladungscode von deinem Auftraggeber. Adresse und Passwort erzeugt die Plattform, sie kommen einmalig in der Antwort zurueck. Kein Postfach, keine Mail, kein activate. Nicht mit username/password kombinieren.",
      +  "type": "string"
      +}
    • changedInput schema / properties / password / description
      Previous value: -"Passwort"New value: +"WEG 2: Passwort"
    • changedInput schema / properties / password_confirm / description
      Previous value: -"Passwort-Wiederholung (muss identisch sein)"New value: +"WEG 2: Passwort-Wiederholung (muss identisch sein)"
    • changedInput schema / properties / username / description
      Previous value: -"E-Mail-Adresse fuer die Registrierung (Aktivierungscode kommt dorthin — der Mensch kann ihn vorlesen, IMAP nicht noetig)"New value: +"WEG 2 (Mensch): E-Mail-Adresse fuer die Registrierung (Aktivierungscode kommt dorthin — der Mensch kann ihn vorlesen, IMAP nicht noetig)"
    • changedInput schema / required
      Previous value: -[
      -  "username",
      -  "password",
      -  "password_confirm",
      -  "accept_terms"
      -]New value: +[
      +  "accept_terms"
      +]
  6. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Goes well beyond the annotations: discloses the 10-failures-per-IP-per-hour throttle and the resulting 429, that credentials are returned exactly once and must be persisted, that a re-registration creates a new empty account, that a missing invite_code leaves the account fully isolated at 0 credits, and the 400-with-warning behavior for accept_management. The only gap is that return payload structure is only partially sketched (username/password/refresh_token), leaving response shape partly implicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded and organized around the two paths, but heavily padded: the four credit/access routes are enumerated twice (once in prose, once as a lettered list), and the credential-storage warning is repeated. Substantive content survives trimming, so structure is good but size is excessive.

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?

For an 11-parameter, non-idempotent, open-world registration tool with no output schema, the description covers prerequisites, both invocation modes, credential handling, rate limits, and every follow-up decision point an agent faces after creation. Nothing needed to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter semantics the schema states only per-field: which parameters belong to WEG 1 vs. WEG 2, that they must not be combined, and that invite_code's scope rights transfer immediately. It also supplies the terms URL context for accept_terms. Some of this repeats the schema, keeping it below 5.

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?

Opens with a specific verb+resource ('Konto anlegen — zwei Wege') and immediately splits into two named paths (agent self-registration vs. human with e-mail activation). It is unambiguously distinguishable from siblings like login, activate, and redeem_invite_code, which are referenced by name.

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?

Explicitly states which path to use under which condition (agent=true when no mailbox or human is available; username/password when a person will activate by mail), and names the alternatives for every follow-up need (redeem_invite_code, onto_credit_checkout, onto_credit_chargeup, ontouser_service_request). It even includes when-not guidance ('Nicht mit username/password kombinieren', no starting credit).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.