Skip to main content
Glama
Sign In

Telesherpa Ontology Platform

by com.telesherpa
OverviewDiscussionsAdmin

Save Form Definition

onto_formdef_save
Idempotent

Formular-DEFINITION speichern (der EINZIGE Schreibweg fuer formdef). Pflichtfelder: version (int>=1), title, answer_type (muss existierender Objekttyp sein, z.B. 'inspection'), fields (nicht-leer). Jedes Feld: key (Buchstabe am Anfang, a-zA-Z0-9_), widget, label; optional required, options (bei select), source (bei picker), validation. Widgets: text, textarea, int, float, select, picker, switch, slider, datepicker, file, label, subform, images, documents, signature. Reservierte Keys: formdef, usesForm, performs, udid, name, external_id. adminsql/sql/sqlparameters nur als Admin. Rechte: form_writer/admin + Schreibzugriff auf den Scope. Mit 'name'/'scope_id' werden auch die Stammdaten gesetzt. ACHTUNG: buttons/template_file/template_filename sind KEINE eigenen Parameter, sondern Felder INNERHALB des formdef-JSON (buttons/template_file/template_filename). BUTTONS: formdef.buttons=[{type,label,...}]; erlaubte type-Werte: 'save' (nur speichern), 'saveandgoto' (+url: Weiterleitung), 'send' (Mailversand mit PDF-Anhang; PFLICHT to[]; optional cc[], bcc[], subject; '$currentuseremail' wird durch die Adresse des Ausfuellenden ersetzt). Empfaenger kommen IMMER aus der formdef, nie aus dem POST. PDF-VORLAGE aus Excel: formdef.template_file = file_udid als 32-hex aus upload_file_to_object (NICHT bin2hex!) und formdef.template_filename = Dateiname — beide parallel setzen. Die Auswahl per Dateiname ueberlebt einen Neu-Upload gleichen Namens. PLATZHALTER im Excel: ##feldkey## (doppeltes Hash; ## key ## mit Leerzeichen geht auch) — {feldkey} oder %%feldkey%% funktionieren NICHT. Subform-Felder fuellen zeilenweise den naechsten freien Platzhalter (das Excel bestimmt die Maximalzahl, ueberzaehlige Zeilen werden verworfen); Bildfelder/signature werden Bildanker. | EN: form, form definition, fields, template, PDF, submission

Input Schema

NameRequiredDescriptionDefault
nameNoTechnischer Name (optional)
udidYesFormular-udid (32-hex) aus onto_formdef_list_templates oder onto_formdef_create
formdefNoDie Definition: {version, title, answer_type, fields:[...]}. Als Objekt ODER JSON-String.
scope_idNoObjekt-Scope aendern (optional)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added
  2. Removed
  3. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations declare idempotent, non-destructive, non-read-only behavior, and the description adds substantial context beyond that: permission requirements, admin-only fields (adminsql/sql/sqlparameters), reserved keys, button type semantics, and template upload identity rules.

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?

Long but information-dense and front-loaded with the core save semantics, required fields, and field schema before the advanced template/button details. The unformatted wall of text with inline caps reduces scannability slightly.

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 a tool with a nested object parameter and no output schema, the description covers nested field grammar, widget enums, reserved keys, button configurations, PDF template mechanics, and placeholder syntax — everything needed to construct a valid call.

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?

Schema coverage is 100%, so baseline is 3, but the description goes far beyond: it enumerates the required nested keys (version int>=1, title, answer_type, fields), the per-field structure (key, widget, label, options, source, validation), the full widget vocabulary, and clarifies that buttons/template_file live inside the formdef JSON rather than as top-level params.

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?

States a specific verb+resource ('Formular-DEFINITION speichern') and explicitly positions it as the only write path for formdef, distinguishing it from read/list siblings and from onto_formdef_create referenced in the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives required fields, role prerequisites (form_writer/admin plus scope write access), and notes that name/scope_id also set master data. Lacks an explicit contrast with onto_formdef_create (new vs. overwrite), which would make it a 5.

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

All Telesherpa Ontology Platform toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources