Telesherpa Ontology Platform

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

Annotations cover the safety profile (not readOnly, not idempotent, open-world, non-destructive). The description adds genuinely useful behavior beyond that: it deletes the 'notactivated' role and grants full access, and it requires the account's login credentials. These side-effect and auth disclosures are exactly the value structured data does not carry.

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 same idea — the code arrives by activation email — is restated three times across the German and English fragments, and the English is bolted on awkwardly. The mixed-language content is redundant rather than additive, so length is not earned.

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?

For a 3-param mutation with no output schema, it covers the essentials: purpose, required credentials, the code's origin and format, and the account-state side effect. An agent has enough to invoke it correctly; only the absence of explicit sibling routing keeps it from a 5.

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?

Schema coverage is 100%, so baseline is 3. The description goes beyond it by stating the voucher is a 7-digit activation code delivered by email and by identifying loginusername/loginpassword as the registered account's email + password, giving the agent the expected format and source.

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?

States a specific verb (activate) and resource (registered account) with the mechanism (voucher code). It implicitly distinguishes from register (which comes before) and renew_account, though it doesn't name those siblings explicitly. The German sentences dilute but don't obscure the purpose.

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?

It gives real workflow guidance for obtaining the code (ask the human on the standard path, otherwise pull via IMAP), which is more than the bare minimum. However, it never clarifies when to choose this over register, renew_account, or redeem_invite_code, so the routing guidance against siblings is only implied.

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

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

Annotations already declare destructiveHint=false and readOnlyHint=false. The description adds the key behavioral detail that it appends to existing entries and deletes nothing, which clarifies the additive nature beyond the binary destructive hint. It does not cover idempotency explicitly, though the annotation covers it.

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 front-loaded with the core action, then adds behavioral and usage context in short sentences. The trailing '| EN: allowlist, permission, whitelist, code' keywords are slightly extraneous for an agent but do not significantly harm readability.

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?

With full schema parameter descriptions, clear annotations, and no output schema, the description is complete enough for an agent to call the tool correctly. It covers purpose, usage conditions, alternatives, and the additive behavior.

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?

Schema description coverage is 100%, so all three parameters are fully documented in the schema itself. The description mentions email addresses and patterns but adds no syntax or format details beyond what the schema already provides, so the baseline of 3 applies.

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 states a specific verb and resource: adding a single email address or pattern to a code's allowlist. It explicitly distinguishes itself from sibling tools by naming upload_code_allowlist for bulk additions and delete_code_allowlist_entry for removal.

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?

It gives explicit when-to-use guidance ('fuer einzelne Nachzuegler') and names the alternative for bulk operations ('fuer viele Adressen ist der Excel-Upload upload_code_allowlist der richtige Weg'). It also points to the removal tool, leaving no ambiguity about tool selection.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds meaningful return-content context (it reports token validity, roles, and next steps, plus guide_repo / guide_entry / guide_version), which is valuable because no output schema exists; the only redundancy is restating 'Rein lesend'.

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 core content is front-loaded under 'WICHTIG', which is good, but the text is a dense bilingual paragraph and the trailing '| EN: auth, status, codeberg, guide, skill' keyword list is search-engine padding that does not help an agent decide or invoke. 'Rein lesend' also repeats the readOnlyHint annotation.

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?

With no output schema, the description carries the return-value burden and does so adequately: it names the auth facts reported (validity, roles, next action) and the guide_* fields returned. It stops short of describing the full response shape, but nothing an agent needs 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.

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. It correctly signals a no-argument diagnostic call rather than implying any filtering or input is needed.

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 states a specific verb+resource: it diagnoses the auth state of the current connection, naming exactly what is reported (bearer-token validity, roles) and what to do next. This clearly separates it from siblings like login, refresh_access_token, or change_password, which mutate credentials rather than report status.

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?

It gives an explicit triggering condition — call it when unexpectedly few tools are visible — and explicitly rejects the wrong behavior ('statt zu raten' / instead of guessing). It also points to the platform guide for the broader workflow, so the agent knows both when to call it and where to go afterwards.

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

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

Goes well beyond the annotations: old password is mandatory, the new password must be supplied twice identically, only the caller's own account is affected, and existing tokens stay valid so no re-login is needed. These are non-obvious behavioral consequences an agent could not derive from readOnlyHint/destructiveHint alone.

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?

Front-loads the core action and the usage rule, then adds constraints and side effects in a logical order. The trailing '| EN: password, credentials, account' keyword block is slightly SEO-like filler, but the body is otherwise efficient.

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?

For a mutation tool with no output schema and no required-parameter markers, the description covers inputs, scope, and post-change token behavior adequately. It stops short of mentioning error conditions (e.g., wrong old password), which is the only meaningful gap.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it clarifies that the old password is required and that the new password must match the confirmation field exactly. This reinforces the semantics of old_password and password_confirm beyond their terse schema text.

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?

States a specific verb+resource ('Passwort des EIGENEN Kontos aendern') with explicit scope limited to the caller's own account. It distinguishes itself from the sibling onto_user_update by noting that even administrators cannot set foreign passwords. An agent can select it without opening the schema.

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?

Gives an explicit trigger ('Nutze es, wenn der Mensch das Passwort wechseln will') and names the alternative (onto_user_update) for account administration. It also states an exclusion — foreign passwords are out of scope — leaving nothing to inference.

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

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=false). The description goes beyond them by disclosing the dual read/write mode (no fields = read, fields = write) and by scoping the mutation strictly to personal master data, excluding access rights/roles. It does not contradict the annotations; the readOnlyHint=false correctly reflects that the tool can write.

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 core is front-loaded and efficient: purpose first, then the read/write rule, then sibling routing. However, the trailing '| EN: file, upload, document, attachment' is unrelated keyword noise that does not earn its place and actively risks misleading an agent into thinking this tool touches files or documents.

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?

For a simple 5-optional-string tool with no output schema, the description covers mode semantics, scope, and sibling routing adequately, and annotations supply the safety profile. The only gap is the misleading English keyword tail, which slightly undercuts an otherwise complete definition.

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?

Schema description coverage is 100% and all 5 optional string parameters are documented in the schema itself, so the baseline is 3. The description restates the fields (Anzeigename, Telefon, Organisation, Notizen, Skills) but adds no format, constraint, or partial-update semantics beyond what the schema already conveys.

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?

States a specific verb+resource pair: reading or changing the profile of one's OWN account, and enumerates the affected fields (display name, phone, organisation, notes, skills). It explicitly distinguishes itself from the sibling operations onto_user_update (roles, admin only), onto_user_update_profile (other people's profiles), and onto_user_get (own account including roles). An agent can tell it apart from siblings without opening a schema.

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?

Gives explicit conditional behavior: called without fields it returns the current state, called with fields it mutates. It names the alternatives and the exact condition that selects them (roles require an admin via onto_user_update, foreign profiles go to onto_user_update_profile, own account plus roles go to onto_user_get). Nothing is left to inference.

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

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

Annotations already declare write/non-idempotent/non-destructive/open-world, so the description's added value is the operational context: the code governs which access rights the redeemer receives, it must be shared rather than retained, and the invitation is bidirectional. It does not restate auth requirements (those live in the schema) but adds meaningful behavioral framing beyond the annotations.

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?

Purpose is front-loaded in the first sentence, followed by usage, alternatives, and workflow context in a compact block with no redundancy. Trailing lines are short directives rather than filler.

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?

For a 7-parameter write tool with full schema coverage and no output schema, the description covers purpose, alternatives, and key behavior; the implicit return of a code is suggested by 'den Code weitergeben'. It stops short of describing the response shape or auth needs, but the schema carries those.

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?

Schema coverage is 100%, so every parameter (label, can_read, can_write, can_manage_scope, max_uses, expires_days, scope_id) is already documented in the schema, including the can_manage_scope=1 prerequisite. The description only gestures at the access-rights concept, so baseline 3 is appropriate.

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 first sentence states a specific verb (anlegen) and resource (Einladungscode) and explains the effect: new members self-register with it. It explicitly distinguishes itself from list_invite_codes (manage) and revoke_invite_code (invalidate), so an agent can route correctly without opening a schema.

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?

It states when to use it ('Anwerben von Mitgliedern/Subunternehmern') and names the two sibling alternatives with their conditions — list_invite_codes for management and revoke_invite_code for invalidation. The 'pass the code on, don't store it here' instruction is a concrete usage directive.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is covered. The description adds non-obvious impact context beyond the annotations: deletion only revokes admission and already-registered accounts remain, which clarifies the blast radius. It stops short of stating auth requirements or confirmation behavior.

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?

Front-loaded with the action, then impact, then routing, in three tight sentences. The trailing '| EN: allowlist, permission, whitelist, code' keyword block is redundant padding for an agent reader, costing it the top mark.

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?

For a one-parameter destructive tool with annotations covering safety and no output schema, the description covers action, side effects, and the alternative. Only minor gaps remain (permission prerequisites, error/return behavior).

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?

Schema description coverage is 100% and the schema itself notes the id comes from list_code_allowlist. The description adds no parameter-level detail, so the baseline of 3 applies when structured data carries the full parameter burden.

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?

States a specific verb and resource ('Einen Eintrag aus der Allowlist eines Codes entfernen') and immediately differentiates from the sibling upload_code_allowlist by scope (single entry vs. bulk list replacement). An agent can distinguish this from add_code_allowlist_entry and list_code_allowlist without opening a schema.

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?

Gives an explicit use case ('Nutze es, um einzelne Adressen zu sperren') and names the alternative for the contrasting case ('Bulk-Ersetzung der ganzen Liste: upload_code_allowlist'), so the routing decision is fully specified.

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

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint, so 'Rein lesend' is partly redundant, but the description adds non-annotation context: the response is a raw binary file (Rohdatei) rather than JSON, and the tokens must be sourced from onto_object_show. It says nothing about size limits, auth, or failure on a bad token, so it stops short of a 5.

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?

Front-loaded with the action and return form, then usage routing, all in a few tight sentences. The trailing '| EN: get, document' machine tag adds little for an agent but is not wasteful enough to drop below 4.

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?

With no output schema, the description correctly carries the burden of saying the return is a raw file, and it covers both the positive path and the two main confusions (images, uploads). Minor gaps remain around invalid/expired tokens and any size behavior.

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?

Schema coverage is 100%, so the terse schema descriptions ('URL slug for the file', 'File token') set the baseline at 3. The description goes beyond it by naming the provenance of both identifiers (the object from onto_object_show) and by confirming both are required identifiers rather than optional filters.

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?

States a specific verb (abrufen/get) and resource (Dokument als PDF/Office-Rohdatei), plus the exact two keys required to address it. It explicitly distinguishes itself from get_image and upload_file_to_object, so an agent can identify it among the ~100 siblings without opening the schema.

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?

Gives affirmative use context ('Nutze es, wenn du die beiden Kennungen hast'), an exclusion ('Nicht zum Hochladen: dafuer upload_file_to_object'), a redirect for a different media type ('Fuer Bilder gibt es get_image'), and even tells the agent where to obtain the two tokens (onto_object_show). That is explicit when/when-not/alternatives guidance.

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

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

Annotations already cover read-only, idempotent, non-destructive behavior, and the description reinforces 'Rein lesend'. It adds useful behavioral context by noting the raw file output and the hard prerequisite of having a filetoken (without it the file is inaccessible). However, it does not discuss authentication, rate limits, or error handling.

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 core instruction is front-loaded in the first sentence, and the remaining content is relevant (prerequisites, source of identifiers, negative routing). The trailing '| EN: get, image' is slightly redundant but does not obscure meaning.

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 rich annotations, full schema description coverage, and absence of an output schema, the description provides everything needed: purpose, usage conditions, identifier sources, output format ('Rohdatei'), and a clear alternative for the upload case.

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?

Schema coverage is 100% and provides basic descriptions for both parameters. The description adds semantic value by explaining that these identifiers live on objects/image repositories and how to retrieve them via sibling tools, which goes beyond the schema's minimal definitions.

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?

States a specific verb ('abrufen') and resource ('Bild') and clarifies the output form ('als Rohdatei'). It also distinguishes itself from the upload sibling, so an agent can identify it without opening the schema.

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?

Explicitly states when to use it ('wenn du die beiden Kennungen hast'), where to obtain the required identifiers (onto_object_show or onto_file_structured), and names the alternative for uploading (upload_file_to_object). This leaves no ambiguity about when and how to invoke it.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, and the description is consistent with them ('Rein lesend'). It adds useful context beyond the annotations by clarifying that the data is scoped to the authenticated account's own inbox and by pointing to the mutation counterpart, though it says nothing about volume/pagination of the result.

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?

Purpose is front-loaded, followed by the routing rules, and the trailing EN keyword line aids retrieval. It is a dense run-on with several cross-references, but every clause carries routing value, so little is wasted.

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?

For a parameterless, read-only list tool with annotations covering the safety profile and no output schema, the description supplies purpose, scope, and sibling alternatives. The only gap is return shape (count, ordering, unread flag), which is minor for this tool class.

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 tool takes zero parameters, so per the rubric the baseline is 4; there is nothing for the description to disambiguate. The description correctly gives no parameter guidance, which is appropriate here.

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?

States a specific verb+resource+scope: retrieving the logged-in account's own notifications ('Die eigenen Benachrichtigungen abrufen (Meldungen des angemeldeten Kontos)'). It also names the closely-related siblings (ontouser_notification_index, ontouser_notification_read, onto_action_logs), so an agent can separate this tool from near-identical ones without opening a schema.

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?

Explicit when-to-use routing: use this to find new notifications, switch to ontouser_notification_index when acting as a scope user, use ontouser_notification_read to mark as read, and onto_action_logs for admin system logs. Both the alternatives and the conditions that select them are stated.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the description's 'Rein lesend' is largely redundant with structured data. It does add that an empty list means anyone may redeem the code, but that semantics lives in the schema parameter description, not here. No return-shape or pagination behavior is disclosed.

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?

Front-loaded with the core action and the usage/alternative guidance, with no filler sentences. The trailing '| EN: allowlist, permission, whitelist, code' keyword line is retrieval-oriented metadata rather than instruction, a minor structural cost but a reasonable trade for discoverability.

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?

One required parameter, full schema coverage, and annotations that cover the safety profile, so the description is close to sufficient. The one gap is that with no output schema, it never indicates what the listing returns (entry objects, pattern types, ordering), which an agent would otherwise have to discover empirically.

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?

Schema description coverage is 100% for the single required code_id parameter, and the schema itself carries the important semantic (empty list = everyone may redeem). The tool description adds no parameter-level syntax, format, or constraint beyond what the schema already provides, so the baseline 3 applies.

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?

States a specific verb and resource: read the email allowlist of an invite code, with a parenthetical clarifying what the entries are (addresses/patterns). It also names the sibling tools that mutate the same resource (add/delete/upload), so an agent can place it precisely among them.

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?

Explicitly says to use it as the current-state baseline before making changes, and routes to the exact alternatives for the other operations: add_code_allowlist_entry / delete_code_allowlist_entry for single entries and upload_code_allowlist for bulk Excel upload. When-to-use and which-alternative are both spelled out.

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

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

Annotations already declare readOnly/strictly safe behavior. The description adds important context beyond annotations: visibility is fail-closed to the caller's scopes, and it enumerates the returned fields (udid, title, field count, per-field key/label/widget/required). Pagination and error behavior are not mentioned, keeping it slightly below a 5.

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 German description is reasonably front-loaded but includes redundant visibility statements ('die fuer dich sichtbar sind' then 'Sichtbar sind nur Formulare in deinen Scopes') and an unnecessary English tag '| EN: list, formdefs' that adds no value. It could be tightened without loss.

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?

For a read-only list tool with no parameters, no output schema, and rich annotations, the description covers purpose, next-step usage, visibility constraint, and returned field contents. Minor omissions like pagination or empty-result behavior prevent a 5.

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?

Zero parameters with 100% schema coverage, so the schema carries no burden. The description correctly omits any parameter discussion; baseline 4 applies with no additional semantics needed.

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?

States a specific verb and resource ('Liste aller Formulare (formdefs)') and summarizes the returned fields. It names show_formdef as the next step, but does not explicitly distinguish from the sibling onto_formdef_list_templates, so it falls short of perfect sibling differentiation.

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?

Clearly positions the tool as the 'ERSTER SCHRITT' for choosing a form and explains that the udid is used with show_formdef. No explicit when-not-to-use or alternative-listing guidance is given, but usage context is clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds return content (who was invited, whether the code is still valid) and reiterates 'rein lesend', but does not disclose output format or pagination. With annotations carrying the safety profile, the added context is useful but not exhaustive.

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?

Front-loaded with purpose and usage, followed by alternatives. The 'Rein lesend' clause duplicates the readOnlyHint annotation, and the trailing EN keywords are search aids, but overall the description is efficient and well-organized.

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?

For a simple one-parameter read tool with full schema coverage and rich annotations, the description covers purpose, usage, alternatives, and return content. No output schema exists, and the description sufficiently explains what is returned.

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?

Schema description coverage is 100%, and the schema fully documents scope_id including the can_manage_scope=1 requirement. The description adds no parameter-level meaning beyond what the schema provides, so the baseline of 3 applies.

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?

States a specific verb ('auflisten') and resource ('Einladungscodes') and explicitly distinguishes from siblings by naming create_invite_code, revoke_invite_code, and list_code_allowlist. It also clarifies that the list is scoped to the user's own codes, leaving no ambiguity.

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?

Explicitly says to use it to find a code for sharing or revoking, and names the alternative tools for creating, invalidating, and viewing allowlists. This provides clear when-to-use and alternatives without requiring inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so 'Rein lesend' largely repeats structured data. The description does add scoping context ('eigenen Bereiches') and the pre-change inspection purpose, but says nothing about pagination behavior or result limits beyond what the schema provides, so a 3 is appropriate against an annotation-covered baseline.

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?

Purpose is front-loaded and the three routing clauses are compact and useful. The trailing '| EN: member, participant, membership, team' block is keyword padding rather than operative instruction, which slightly dilutes an otherwise tight definition.

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?

For a read-only listing tool whose safety profile is fully covered by annotations, the description supplies purpose, scoping, and sibling routing. Return-value detail lives in the schema's scope_id description, and there is no output schema to account for, so the only minor gap is explicit pagination guidance.

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?

Schema description coverage is 100%, and the schema itself carries the meaningful details (20 members per page default, can_manage_scope=1 requirement, and that only email + rights + sp_id are returned). The description adds no parameter-level information beyond the schema, so the baseline 3 is correct.

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?

States a specific verb and resource ('Mitglieder ... auflisten') plus a scope qualifier ('eigenen Bereiches'), so the agent knows exactly what is returned. It also names the sibling operations it is not (toggle_member_flag, remove_member), making it distinguishable without opening a schema.

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?

Gives an explicit when-to-use ('den Ist-Stand vor Aenderungen zu sehen') and routes three adjacent operations to their correct tools: rights changes to toggle_member_flag, removal to remove_member, invitations to create_invite_code. The alternatives and the selecting condition are spelled out.

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

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

Adds substantial context beyond the readOnly/openWorld/idempotent annotations: 10-hour access token, 30-day refresh token, the response being returned only once and needing immediate storage, and the fact that unauthenticated sessions see only public tools. None of this is recoverable from the annotations.

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?

Front-loaded with the core action and dense with useful constraints, but the refresh_access_token instruction is repeated twice (once as 'don't log in again' and again as the grant_type=refresh_token note), which is avoidable redundancy in an otherwise efficient block.

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?

With no output schema, the description correctly describes the return payload (access_token + refresh_token) and their lifetimes, plus prerequisites (register first) and credentials semantics. An agent has everything needed to call and follow up correctly.

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?

Schema coverage is 100% and the schema already documents client_id as username/email and client_secret as password/secret, so the description's parenthetical glosses are pure duplication with no added syntax, format, or constraint detail. Baseline 3 applies when the schema does all the work.

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?

States a specific verb and resource ('Ein Bearer-Token holen' – exchange credentials for tokens) and immediately frames it as the entry point. It distinguishes itself from sibling auth tools by naming refresh_access_token and register explicitly, so an agent can differentiate without opening other schemas.

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?

Gives explicit when-to-use (once at the beginning), when-not (do NOT log in again; use refresh_access_token, which needs no password), and named alternatives for adjacent cases (register for no account, web UI for forgotten password). Routing is unambiguous.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description adds genuine value beyond them by naming the required authorization scope (can_manage_scope/can_write), which the annotations do not convey. It does not explain reversibility or side effects on dependent data, keeping it below a 5.

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 core sentence is compact and the permission note is useful, but the trailing "| EN: action, button, definition, gate, condition, rule" is keyword stuffing that does not earn its place. The definition is short overall but not tightly front-loaded.

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?

For a one-parameter destructive delete whose annotations already carry the safety profile, the description covers purpose and authorization adequately. It would be fully complete with a note on what happens to objects that referenced the deleted definition.

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?

Schema description coverage is 100% with a single well-described 'key' parameter, so the schema does the heavy lifting. The description adds nothing about the key's format or semantics, making the baseline 3 appropriate.

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?

"Actiondef loeschen (Button entfernen)" states a specific verb (delete) and resource (actiondef), and the parenthetical clarifies what an actiondef is for an agent unfamiliar with the domain. It does not, however, explicitly distinguish itself from its siblings onto_actiondef_list and onto_actiondef_save, so it stops short of a 5.

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 states a precondition (requires Scope-Manager/Writer, can_manage_scope/can_write), which is useful, but gives no when-to-use vs when-not guidance and never references the sibling save/list tools. Usage is only implied by the verb.

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

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint, so the safety profile is covered; "Rein lesend" merely restates it. The description does add useful context by explaining how the returned keys feed into onto_object_execute_action and what the definitions gate, which goes beyond the structured fields.

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?

Front-loads purpose, then read-only status, usage condition, and alternatives in a logical flow. The trailing EN keyword list is slightly noisy but serves discovery and does not bury the key information.

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?

For a read-only list tool with full annotation coverage and a documented schema, the description is essentially complete; it even describes the conceptual return (which buttons on which objects). No output schema exists, but none is needed for a simple list.

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?

Schema description coverage is 100% (page, limit fully documented in German), so the schema already carries parameter meaning. The description adds nothing about pagination or limits, which is acceptable given the baseline for full coverage.

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?

States a specific verb ("auflisten") and resource ("Action-Definitionen") and clarifies what they represent ("welche Buttons an welchen Objekten erscheinen"). It also distinguishes itself from the sibling onto_actiondef_save for create/modify.

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?

Gives an explicit use condition ("wenn du wissen willst, welche Aktion du auf einem Objekt ausfuehren kannst") and routes the agent to two named alternatives: onto_object_execute_action (to consume the key) and onto_actiondef_save (for create/modify).

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

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

Goes well beyond the annotations (destructiveHint/openWorld/idempotent): it discloses the 403 authorization failure mode, admin-only restrictions on public:true/PUBLIC scope/SQL conditions, the visibility-vs-execution distinction tied to body.scopes[], and the hidden_actions opt-out a scope manager can use. This is exactly the extra mutation context the annotations cannot carry.

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?

Front-loads the verb and the PFLICHT requirement well, but the paragraph is long and drifts into tangential rules (members cloning platform actions, hidden_actions suppression) that are not needed to invoke the tool, and it ends with keyword-stuffed tags ('action, button, definition, gate...'). Useful content, but not tightly scoped.

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?

For a destructive, non-open-world mutation with no output schema, the definition supplies permissions, scope semantics, an example payload and admin carve-outs — enough to call it correctly. It does not describe the success response or what happens on update versus create, a minor remaining gap.

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?

Schema coverage is already 100%, so the non-zero value comes from the description unpacking body — a JSON string whose scopes[] is mandatory, plus a worked example with object_types, roles and action.type 'form_answer' linking the answer to the object. That adds real meaning beyond the schema's terse body description.

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?

States a specific verb pair and resource: 'Actiondef anlegen/aendern (Button am Objekt)' — create/update an action definition (object button). An agent can immediately distinguish it from siblings onto_actiondef_delete and onto_actiondef_list without opening any schema.

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?

Gives strong usage conditions: body.scopes is mandatory, the caller must be Manager (can_manage_scope) or Writer (can_write) on those scopes or get 403, PUBLIC scope 15 is admin-only, and exactly one target scope is allowed at creation. It stops short of explicitly routing to sibling tools (list/delete) for other operations, so it is clear context but not full alternative coverage.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, but the description adds concrete consequences beyond them: existing type definitions can be overwritten and the previous value is unrecoverable (keine Historie, kein Undo). It doesn't cover permissions or rate limits, so it stops short of a 5.

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 destructive warning and prerequisite are front-loaded across three tight sentences. The trailing '| EN: catalog, preset, template, apply, clear' keyword block is mild clutter but arguably aids search.

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?

For a destructive mutation tool with no output schema, the description covers effect, prerequisite, reversibility and irreversibility. Return-value behavior is unaddressed, but that is a minor gap for this operation type.

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?

Schema coverage is 100% and the schema already documents both parameters, including the union/empty-array semantics. The description adds no syntax or format detail beyond that, so the baseline 3 applies.

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?

States a specific verb and resource ('Ein Preset auf einen Scope anwenden') plus the effect on the scope's object types, which cleanly distinguishes it from siblings onto_catalog_index (read), onto_catalog_presets (list) and onto_catalog_clear (undo). An agent can route to it without opening the schema.

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?

Explicitly names the prerequisite ('Pruefe vorher mit onto_catalog_index') and the rollback alternative ('Rueckgaengig: onto_catalog_clear'), so both when-to-use and how-to-recover are stated rather than inferred.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description earns credit by disclosing the downstream consequence that isn't in the annotations: objects of the removed types become unreachable, which is why the pre-check is advised. It still omits authorization/permission requirements.

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?

Front-loaded with the action, then the risk warning, then the undo use case and the alternative. Efficient and well ordered; the 'EN:' keyword tail is minor tag padding rather than prose waste.

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?

For a destructive, single-parameter mutation with no output schema, the description covers the action, its irreversible consequence, a mitigating pre-check, and the alternative tool - everything an agent needs to call it safely.

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?

Schema coverage is 100% for the single scope_id parameter ('Ziel-Scope-ID'). The description adds no syntax or constraint detail beyond the schema, so the baseline 3 is appropriate when the schema carries the parameter semantics.

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?

Specific verb (removes) applied to a precise resource: the preset-created object types of a scope. It distinguishes itself from siblings by naming onto_catalog_apply (the inverse) and onto_type_delete (the narrower alternative), so an agent can route without opening schemas.

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?

Explicit when-to-use ('zum Zuruecknehmen von onto_catalog_apply'), a concrete prerequisite step (check object existence via onto_object_index first), and a named alternative for partial removal (onto_type_delete). Nothing is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so 'Rein lesend' largely restates structured data. The description does add the content shape (type-to-preset mapping) and the safe pre-apply check framing, but says nothing about response size, pagination, or failure modes. With annotations carrying the safety profile, this is adequate but not rich.

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 operative German sentences are front-loaded and waste-free, but the appended '| EN: catalog, preset, template, apply, clear' block is keyword stuffing rather than agent-relevant guidance. That trailing barcode of terms adds no semantic value and dilutes otherwise tight prose.

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?

For a zero-parameter read tool with no output schema, the description needs to convey what comes back, and it does (which types sit in which presets) plus when to call it. Missing only minor specifics like result format/pagination, which are low-risk here.

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 tool takes no parameters and the schema coverage is 100%, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter behavior is left unexplained.

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?

States a specific verb+resource: reading the object type catalog and which types are bundled into which presets. It also distinguishes itself from siblings by name, pointing to onto_catalog_presets for the preset list and referencing the apply step. An agent can tell what this returns without opening any schema.

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?

Explicitly instructs to use it to preview what a preset would contain BEFORE applying it, which is a concrete decision rule. It also names the alternative tool (onto_catalog_presets) for the adjacent need, so routing between the three onto_catalog_* tools is unambiguous.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description repeats 'Rein lesend' and adds usage context, but does not disclose additional behavioral details such as authentication needs, rate limits, or output format. With annotations covering the safety profile, this is adequate but not rich.

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 front-loaded with the core purpose, followed by usage guidance and related tools. It is appropriately sized, though the 'Rein lesend' phrase duplicates the readOnlyHint annotation and the trailing English keyword list is a minor structural add-on.

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?

For a simple, zero-parameter listing tool with rich annotations and no output schema, the description covers purpose, usage entry point, and sibling routing. It does not describe the return shape, but the reference to onto_catalog_index for preset contents partially compensates.

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 tool has zero parameters and the schema is empty, so there is no parameter semantics to document. Per the rules, zero parameters yields a baseline of 4.

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 states a specific verb and resource ('Die verfuegbaren Objekttyp-Presets auflisten') and clarifies what presets are ('vorbereitete Typ-Buendel zur Auswahl'). It explicitly names sibling tools (onto_catalog_apply, onto_catalog_index), making it easy to distinguish from related catalog operations.

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?

It gives an explicit entry-point condition ('Nutze es als Einstieg, wenn ein Scope mit Standardtypen ausgestattet werden soll') and routes the agent to specific alternatives for applying (onto_catalog_apply) and inspecting a preset (onto_catalog_index). No inference is required.

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

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

The annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so 'Rein lesend' largely restates structured data. The description does add that this applies to a Pay-per-Use-Konto, which is useful context, but says nothing about return format, units, or freshness of the balance.

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 core action is front-loaded in the first clause, followed by usage guidance and alternatives in a compact form. The trailing keyword tag ('| EN: credit, balance, pricing, ...') is search padding rather than information, and 'Rein lesend' duplicates the annotations.

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?

For a zero-parameter, read-only, annotation-covered tool with no output schema, the description covers what it returns (current credit balance) and when to call it. Only the shape/units of the returned balance and any caching or rate-limit behavior are unstated.

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 tool takes zero parameters, so the baseline is 4 and there is no parameter semantics for the description to add. It correctly does not invent or imply inputs.

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?

States a specific verb and resource ('Das aktuelle Credit-Guthaben abrufen') and scopes it to a pay-per-use account. It is clearly distinguishable from the sibling credit tools (pricing, chargeup, checkout) without opening any schema.

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?

Gives an explicit when-to-use condition ('vor kostspieligen Aktionen pruefen, ob Guthaben vorhanden ist') and routes the agent to the correct alternatives: onto_credit_pricing for costs, onto_credit_chargeup / onto_credit_checkout for topping up. Nothing about sibling selection is left to inference.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true and idempotentHint=false, so the bar is lower. The description still adds valuable context beyond them: it moves real money / triggers a payment, requires explicit instruction, and clarifies the amount is a payment not a refund. It does not describe failure/retry behavior, which keeps it from a 5.

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 warning about real-money movement and the sibling alternatives are front-loaded and each sentence earns its place. The trailing keyword block ('| EN: credit, balance, pricing, billing, top-up, checkout') is search fodder rather than agent-facing content and slightly dilutes the otherwise tight 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?

For a money-moving tool with no output schema, the description covers the critical dimensions: what it does, the danger profile, the required precondition, the alternatives, and the follow-up tool for verifying the new balance. 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.

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

Schema coverage is 100%, so the schema already documents both parameters (credits = admin manual top-up, prepaid_code = agent self-service), making 3 the baseline. The description adds directional meaning not in the schema by clarifying the amount is an outbound payment rather than a refund, and by flagging that prepaid/checkout are alternative paths.

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 states a specific verb and resource ('Credits aufladen / Guthaben erhoehen') and explicitly names the sibling alternatives (onto_credit_checkout, onto_credit_create_prepaid). An agent can distinguish this from other credit tools without opening any schema.

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?

It gives an explicit when-to-use constraint ('nutze es nur auf ausdrueckliche Ansage') and names two alternative payment routes by tool name, plus the follow-up state check (onto_credit_balance). This is exactly the routing guidance an agent needs.

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

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

Annotations already cover the safety profile (readOnlyHint=false, idempotentHint=false, openWorldHint=true), so the bar is lower, but the description still adds genuinely new behavioral context: this triggers a real external payment flow and must only be invoked on explicit user instruction, and success is verified via onto_credit_balance. It stops short of stating cost implications, failure/rollback behavior, or auth requirements.

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?

Front-loaded with the action and the safety constraint, then routing, then verification. The trailing EN keyword list is retrieval padding rather than agent-facing prose, which is a minor blemish on an otherwise tight two-to-three sentence block.

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?

For a one-parameter, non-idempotent payment trigger with no output schema, the description covers the important gaps: that it is a real payment, that it needs explicit consent, and where to check the outcome (onto_credit_balance). Only deeper failure/permission semantics are absent.

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?

Schema description coverage is 100% and the single parameter already documents 'Anzahl Credits (1 Credit = 0,01 EUR)'. The description adds no format, range, or unit detail beyond the schema, so the baseline 3 applies.

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?

States a specific verb+resource ('Credits per Checkout erwerben', i.e. start a payment/checkout) and explicitly contrasts itself with two named siblings (onto_credit_chargeup for direct top-up, onto_credit_create_prepaid for prepaid contingents). An agent can distinguish this from the other credit tools without opening any schema.

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?

Gives an explicit when ('start a payment transaction'), an explicit when-not/guard ('nur auf ausdrueckliche Ansage ausfuehren' – only run on explicit user instruction), and names the alternative tools for adjacent needs. Routing and the confirmation prerequisite are both stated.

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

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

Annotations already establish readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful semantics beyond that: flat-model users incur no credits and 1 credit = 0.01 EUR, which helps the agent interpret results. It does not describe return format or scope of the pricing table, so it stays at an adequate 3.

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 core two sentences are tight and front-loaded, but the appended 'EN: ...' keyword list is SEO-style filler that repeats concepts already present and names terms belonging to sibling tools, adding noise rather than clarity.

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?

For a read-only, parameterless pricing lookup with no output schema, the description conveys what the agent will learn (per-operation credit costs, currency conversion, flat-user exemption). Enough to call and interpret it correctly, though it never states the shape or granularity of the returned pricing listing.

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?

There are zero parameters and the schema is an empty object, so there is nothing for the description to document; the baseline for a parameterless tool is 4.

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?

States a specific resource (credit costs per action, pay-per-use) and verb-like function (show how many credits each operation consumes). It is distinguishable from onto_credit_balance, onto_credit_chargeup, and onto_credit_checkout, but the trailing 'EN: credit, balance, pricing, billing, top-up, checkout' keyword blob overlaps with those siblings' domains and muddies differentiation.

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?

No explicit when-to-use or when-not-to-use guidance, and no sibling alternatives named. The only conditional signal is the informal note that flat-billing users pay nothing, which is context rather than routing advice.

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

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

Beyond the annotations (which already declare read-only/idempotent/non-destructive), the description adds real behavioral detail: foreign and non-existent order numbers return the same 404 (anti-enumeration), and card token and BIN are withheld from output. This is substantive context an agent could not infer from structured fields.

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?

Purpose and return fields are front-loaded, followed by the safety/redaction notes, so the important content comes first. The trailing EN keyword list adds search noise but is a consistent convention; overall it is dense and mostly earns its length.

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?

With no output schema, the description compensates by listing the returned fields (order number, date, amount, credits, status, transaction, payment data) and noting the redactions. An agent has enough to invoke it and interpret the result correctly.

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?

Schema description coverage is 100% and the single order_id parameter is already documented in the schema, including its origin at the chargeup:sumup line of onto_credit_balance. The description largely restates this, so the baseline of 3 is appropriate.

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?

States a specific verb and resource ('Beleg zu einer SumUp-Aufladung lesen') and enumerates the returned fields, so an agent knows exactly what the tool fetches. It is clearly distinguishable from sibling credit tools like onto_credit_balance and onto_credit_chargeup.

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?

Gives clear operating context: it is read-only, only returns the caller's own receipt, and explicitly points to onto_credit_balance as the source of the order number. It stops short of an explicit 'use this instead of X when Y' routing statement, but the prerequisite is well covered.

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

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

Annotations only flag non-destructive and non-idempotent; the description explains WHY: every call creates a NEW entry even for the same URL because the current filter is stored alongside, so repeated calls with identical arguments produce duplicates. It also discloses the account scoping and that object data is untouched — context annotations cannot express.

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 action is front-loaded, followed by scope, then the duplicate-creation caveat, then the alternatives — a sensible ordering with no filler. The trailing bilingual keyword tag ('| EN: favorite, bookmark, quick access') is minor search metadata rather than content, so not a full 5.

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?

For a two-parameter mutation with no output schema, the description supplies everything needed to call it safely: scope, required input role, the non-idempotency trap, and the sibling to check first or use to undo.

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?

Schema coverage is 100% and both fields (url required, title optional with default) are already documented in the schema. The description only implies that url is the identity key ('auch bei gleicher URL') without adding format or validation detail, so the baseline 3 applies.

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?

States a specific verb+resource ('Ein Objekt zu den eigenen Favoriten hinzufuegen') and constrains the effect to the caller's own account. It explicitly names the retrieval sibling (onto_favorite_index) and the inverse operation (onto_favorite_delete), so an agent can place it among the favorite_* family without opening a schema.

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?

Gives an explicit use case ('fuer haeufig gebrauchte Objekte'), a pre-check workflow ('vorher mit onto_favorite_index pruefen') and a removal alternative (onto_favorite_delete). It does not mention onto_favorite_toggle, the closest sibling, so the agent is left to infer when to use additive add versus toggle.

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

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

Adds real value beyond the annotations: destructiveHint=true could easily be read as deleting the object, and the description explicitly corrects that ('Loescht NUR die Merkung, nicht das Objekt selbst'). It also discloses the account scoping constraint, which no annotation conveys.

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?

Front-loaded with the action and the key non-obvious caveat; roughly three short sentences with no filler. The trailing 'EN: favorite, bookmark, quick access' tag block is search-oriented cruft rather than instruction.

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?

For a one-parameter, non-read-only, idempotent mutation with no output schema, the description covers the risky ambiguity (bookmark vs object) and the routing alternative. Return/deleted-state confirmation is not described, but that is a minor gap at this complexity.

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?

Schema description coverage is 100% and the single parameter already documents its origin (Favoriten-ID aus onto_favorite_index). The description adds nothing about the id beyond the schema, so the baseline 3 applies.

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?

Specific verb + resource (remove an object from one's own favorites) with explicit scope. It distinguishes itself from onto_favorite_add, onto_favorite_toggle, onto_favorite_index and onto_object_delete by name.

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?

States the condition that switches to another tool ('Das Objekt selbst loeschst du mit onto_object_delete') and restricts scope to the caller's own account. It does not, however, contrast itself with onto_favorite_toggle, the closest behavioural sibling, leaving that choice to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description's "Rein lesend" is redundant with the annotations; its only added context is the account-scoping (only the logged-in user's favorites are returned). No pagination or result-shape detail is given, so a 3 is appropriate.

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?

Front-loaded with the core action, then alternatives, then a short English keyword tail ("favorite, bookmark, quick access") that aids discovery. Slightly dense with three sibling references, but every sentence carries routing value.

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?

For a zero-param, read-only list tool with no output schema, the description covers purpose, scope, safety, and alternatives adequately. It could say a bit more about what a favorite entry contains, but nothing needed for correct invocation is missing.

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 tool takes zero parameters, so there is no parameter semantics to explain and the baseline is 4. The description correctly implies no filtering arguments are required.

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?

States a specific verb and resource ("Die eigenen Favoriten auflisten") plus scope (gemerkte Objekte des angemeldeten Kontos), and explicitly names the adjacent siblings onto_favorite_add, onto_favorite_delete, and onto_object_index. An agent can distinguish this from the toggle/add/delete/index siblings without opening any schema.

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?

Gives explicit routing: use onto_favorite_add to bookmark, onto_favorite_delete to remove, and onto_object_index for all objects rather than favorites. The when-to-use intent ("schnell auf haeufig gebrauchte Objekte zuzugreifen") is also stated, leaving nothing to inference.

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

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

Goes well beyond the annotations by disclosing the toggle side-effect (existing entry is DELETED, otherwise created) and that a second call reverses the first — crucial for a tool annotated idempotentHint=false, destructiveHint=false. It does not state permission/auth requirements, but the annotations already rule out open-world reads. The deletion of a bookmark entry is arguably at odds with destructiveHint=false, though it is self-reversing, so this is a tension rather than a flat contradiction.

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?

Front-loaded with the action, then the critical warning, then routing to siblings. Slightly long and mixes German with a trailing EN keyword line, but every sentence carries actionable information.

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?

No output schema exists, yet the description covers the mutation semantics, reversibility, account scoping, and sibling alternatives — everything an agent needs to invoke it correctly without a pre-read.

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?

Schema description coverage is 100% and both parameters are documented in the schema, so the baseline is 3. The description adds only implicit context (same URL toggles back) rather than new parameter-level semantics.

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?

States a specific verb and resource ('Favoriten-Status eines Objekts umschalten') with the toggle direction spelled out (merken <-> nicht gemerkt) and the account scope. It is immediately distinguishable from the sibling onto_favorite_add / onto_favorite_delete, which are named.

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?

Explicitly states when to prefer this tool ('Nutze es, wenn du den Ausgangszustand nicht kennst — du brauchst dann kein Vorab-Lesen') and names both alternatives for the directed cases (onto_favorite_add, onto_favorite_delete). When/when-not/alternatives are all covered.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds genuinely new behavior: the deletion is irreversible, dangling references should be checked first, the parent object record survives, and re-uploading restores a file. That is real context beyond the annotation flags, though permissions/auth requirements and any post-delete response are unstated.

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?

Four short, front-loaded sentences with the irreversibility warning placed high, and no filler. The trailing keyword block ("| EN: file, image, document, attachment, upload") is a discoverability artifact rather than agent-facing instruction, which keeps it just short of a 5.

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?

For a single-purpose deletion tool with full annotation coverage and no output schema, the description covers the essentials: what is destroyed, what survives, the referential pre-check, and the recovery path. Only the auth/permission requirement and any error-on-referenced-file behavior are left implicit.

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?

Schema description coverage is 100%, so both file_id and file_udid are already documented in the schema and the description adds nothing about them. Baseline 3 applies when the schema carries the parameter semantics.

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?

States a specific verb + resource ("Eine Datei aus der strukturierten Ablage loeschen") and immediately scopes it: the object record persists and only the file is removed. That scope sentence is what separates it from the similarly-named sibling onto_object_delete, so an agent can pick correctly without opening a schema.

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?

Gives a concrete pre-condition ("pruefe vorher, ob Objekte darauf verweisen") and points at the replacement path via the named sibling upload_file_to_object. It does not, however, state when NOT to use this tool (e.g. use onto_object_delete to remove the record itself), so the routing guidance is good but not exhaustive.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, and the description merely restates 'Rein lesend'. It adds no new behavioral context such as auth/permission needs, error cases, or response shape — contextual details that exist only in the schema, not here.

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?

Front-loads the purpose and keeps the operational guidance tight in one flowing passage. The trailing 'EN: file, image, document, attachment, upload' is retrieval-oriented keyword padding rather than useful prose, but it is short enough not to obscure the core content.

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?

For a single-parameter, annotation-covered read tool with no output schema, the description covers retrieval scope, the routing alternative, and the related category tool. Nothing critical for correct invocation is missing, though return/pagination behavior is left unstated.

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?

Schema description coverage is 100% and the single object_id parameter is richly documented in the schema itself (32-hex format, what it returns, and how it relates to scope category definitions). The description adds no parameter-level detail beyond what the schema already provides, so the baseline 3 applies.

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?

States a specific verb and resource ('Eine Datei aus der strukturierten Ablage abrufen') plus the scope of what is returned (Metadaten und/oder Inhalt). It differentiates from the write sibling upload_file_to_object, though it does not distinguish itself from other read siblings like get_document or get_image.

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?

Gives an explicit usage condition ('Nutze es, wenn du die Datei ueber ihre Kennung kennst') and names the alternative for the opposite operation ('Einen Upload machst du mit upload_file_to_object'), plus a pointer to onto_scope_structuredimage_categories for categories. No explicit when-not guidance, but the routing is clear.

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

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

Goes well beyond the annotations: it discloses required rights (form_writer/admin + scope write access, else 403) and details copy side effects (fields transferred, visibility reset to target scope, adminsql stripped if not admin, buttons/template_file carried over). These are non-obvious behavioral traits an agent must know before invoking.

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?

Front-loaded with the core action, then progressively adds copy semantics and permission notes; each sentence carries information. It is somewhat long and mixes German with an English keyword tail, but nothing is truly redundant.

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?

Covers permissions, copy behavior, and the follow-up step, which is substantial for a mutation tool with no output schema. It does not state what the call returns (e.g. the new form's id/udid needed by onto_formdef_save), which is the one remaining gap.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning to the copy parameter by explaining its side effects (field transfer, visibility, adminsql removal). Minor inconsistency: the text calls it 'from_udid' while the schema parameter is 'from'.

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?

States a specific verb and resource up front ('NEUES Formular anlegen'), then clarifies it creates the form object plus a minimal valid 1-field definition. It explicitly distinguishes itself from onto_formdef_save, which extends the definition, so the agent can tell the two apart without opening either schema.

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?

Gives an explicit workflow: create here, then build out with onto_formdef_save. It names the alternative (onto_formdef_list_templates) for sourcing a template and states the condition for the from_udid copy mode and the required follow-up check after copying.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so 'rein lesend' is largely redundant. The description does add usable behavioral context beyond the structured data: what a template result contains (buttons/template_file) and the correct next-tool workflow. No pagination or return-format disclosure keeps it from a 5.

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?

Front-loaded with the core listing statement and the alternatives, and the English keyword tail aids search. The full German text is duplicated in intent by the bilingual tail and 'rein lesend' repeats the annotations, adding some length without new meaning.

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?

No output schema exists, yet the description covers scope, next-step workflow, and result content, which is sufficient for a simple read-only list tool. It stops short of describing ordering, limits, or result shape, so not quite a 5.

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?

Only one optional param (q) and schema description coverage is 100%, so the schema fully documents it. The description adds no syntax or matching semantics for q, so the baseline 3 applies.

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?

Specific verb+resource+scope: 'list templates: visible forms in PUBLIC scope'. The PUBLIC-scope qualifier and the explicit mentions of onto_formdef_show and onto_formdef_create distinguish it from siblings an agent might otherwise confuse it with.

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?

Explicit when/how-to-use: take the udid to onto_formdef_create + from_udid to build a company-specific copy, or use onto_formdef_show for the full view. It also asserts templates are the easiest route to a functioning template with buttons/template_file — clear routing with named alternatives.

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

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

Annotations cover only readOnly/idempotent/destructive flags, but the description adds substantial behavior: the admin-only adminsql/sql/sqlparameters fields, that name/scope_id also write Stammdaten, that recipients always come from the formdef and never the POST, and that buttons/template_file/template_filename live inside the formdef JSON rather than being top-level params. These are exactly the non-obvious traits an agent needs and none are recoverable from annotations.

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?

Content is relevant and the core purpose is front-loaded, but it is a dense unbroken block that mixes field schema, permissions, buttons, Excel/PDF templating and placeholder syntax into one paragraph. It is appropriately sized for the tool's complexity yet poorly structured for scanning.

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?

For a complex, nested-object, no-output-schema tool, the description covers field structure, permissions, button types, PDF template wiring and placeholder syntax thoroughly. It stops short of describing the response or error behavior, which is a minor residual gap given no output schema is declared.

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?

Schema description coverage is 100% at the top level, so the baseline is 3, but the description goes well beyond it for the nested formdef object: per-field requirements (key regex, widget, label, optional required/options/source/validation), the full widget enum, and the reserved-key list. This meaningfully compensates for the fact that the nested structure cannot be fully expressed in 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?

States a specific verb+resource ('Formular-DEFINITION speichern') and immediately scopes it as 'der EINZIGE Schreibweg fuer formdef', which tells an agent how it relates to siblings like onto_formdef_create and onto_formdef_list_templates. The purpose is unambiguous even without opening the schema.

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?

Gives concrete preconditions: required fields (version>=1, title, answer_type as existing object type, non-empty fields) and permission requirements (form_writer/admin + scope write access). It does not explicitly state when to prefer this over onto_formdef_create or show_formdef, so the alternative-routing guidance is implicit rather than explicit.

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

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

Annotations declare the basic safety profile (not read-only, not destructive, not idempotent). The description adds meaningful behavioral context beyond that: the permission requirement (scope_id must be a managed scope), the optional effects that can mutate data, and the security constraint that no eval is used and only listed operators are available. It does not cover rate limits or error behavior, but the additions are substantive.

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 front-loaded with purpose and then moves through inputs, body format, operators, effects, and permissions. However, it duplicates a large portion of the body format and operator details that already appear in the schema description, making it longer than necessary for a 1-sentence tool purpose.

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?

For a complex mutation tool with nested objects and no output schema, the description covers everything an agent needs: creation semantics, permission prerequisites, the full expression AST format, allowed operators, optional effects, and how the result is consumed. Nothing critical is missing.

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?

Schema coverage is 100%, so the schema already documents most parameters, including the body format and operator list. The description adds an explicit enumeration of allowed input types (object, string, int, float, bool, datetime, list) that is not in the schema, which is useful extra meaning for the complex nested 'body' parameter.

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?

States a specific verb and resource ('RECHENREGEL anlegen: eine Function') and explicitly distinguishes it from a trigger by noting it has inputs and an expression. An agent can identify the tool's role without opening other schemas.

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?

Clearly frames the tool as creating a calculation rule rather than a trigger, and notes that the result is used in rules via run_function. However, it gives no explicit guidance on when to use this versus onto_function_update or onto_function_run, so the alternative routing is only implied.

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

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

Goes well beyond the annotations: it reveals the deletion is a reversible soft-delete (status=deleted), warns that dependent rules invoked via run_function will break, and names the authorization scope. This is exactly the kind of impact/auth context the destructiveHint annotation alone cannot convey.

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?

Front-loads the action and the most surprising fact (soft-delete, reversible), then the warning, then permissions. Slightly cluttered by the trailing EN keyword list for retrieval, but the prose sentences are dense and waste-free.

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?

For a single-param mutation with annotations and no output schema, the description covers reversibility, side effects, and authorization — everything needed to call it safely. Minor gap: no note on how to undo the soft-delete or which tool restores it.

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?

Schema coverage is 100% and there is a single required param (udid) whose format is already documented in the schema. The description adds no parameter-level detail, so the baseline 3 applies.

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?

States a specific verb+resource ("RECHENREGEL loeschen" = delete the function/computational rule) and immediately qualifies it as a soft-delete via status=deleted. Names sibling tools (run_function, onto_trigger_index) in a way that distinguishes this operation from executing or inspecting functions.

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?

Gives concrete pre-flight guidance (check onto_trigger_index to see who consumes the rule) and states the required permission (can_manage_scope). It doesn't contrast delete against sibling operations like onto_function_update (e.g., when to disable vs delete), so it stops short of full alternative routing.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and closed-world, so the safety profile is fully covered. 'Rein lesend' merely restates the readOnly annotation, and the description adds the useful framing that these are server-side automations but no pagination or return-shape context.

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?

Purpose is front-loaded followed by routing guidance, and most sentences earn their place. The trailing keyword tag '| EN: function, automation, expression, script, effect' is search-oriented padding rather than functional information.

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?

For a read-only list tool with full annotation coverage and a fully documented schema, the description covers purpose, usage and alternatives adequately. Since no output schema exists, return format/pagination behavior is left implicit, a minor omission.

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?

Schema description coverage is 100% (both page and limit documented with defaults and range), so the schema does the heavy lifting. The description adds nothing about the two parameters, warranting the baseline 3.

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?

States a specific verb ('auflisten') and resource ('Funktionen'), clarifies they are server-side automations, and explicitly distinguishes itself from onto_function_create/update and onto_trigger_index. An agent can identify the tool's role without opening the schema.

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?

Explicit routing: use it to find the name/udid for onto_function_run, use create/update for mutations, use onto_trigger_index for scheduled runs. This names both the purpose and the alternative tools for adjacent operations.

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

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

Annotations declare readOnlyHint=false and destructiveHint=false, but the description adds genuinely new context: the effect depends on the function itself and may write data, so it is 'nicht rein lesend'. This warns the agent that behavior is dynamic and cannot be inferred from the annotation alone. It stops short of describing permissions, side-effect scope, or return shape.

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?

Core purpose and the routing hint are front-loaded and the body is tight. The trailing bilingual keyword block ('| EN: function, automation, expression, script, effect') is redundant padding for an agent that already has the name, but the substantive sentences earn their place.

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?

For a mutation tool with no output schema, the description covers the critical uncertainty (side effects vary per function, not read-only) and points to the discovery sibling. It would be stronger with a note on required permissions or how errors/return values surface, but nothing essential for calling it is missing.

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?

Schema coverage is 100%, so both parameters (function, inputs) are already documented, including the 'objekt' = target-UDID convention. The description only restates that inputs are passed as an inputs-object, adding no syntax or format detail beyond the schema. Baseline 3 is correct.

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?

States a specific verb and resource ('Eine hinterlegte Funktion ausfuehren') and immediately scopes what it is — a server-side automation/script. It is clearly distinguishable from the surrounding onto_function_* siblings (create/update/delete/index) because it names the run vs. manage split.

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?

Gives an explicit when-to-use condition ('Nutze es, wenn die Funktion bekannt ist') and routes the agent to the alternative for discovery ('die verfuegbaren zeigt onto_function_index'). This is exactly the when/when-not/alternative guidance the dimension asks for.

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

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

Annotations already flag destructiveHint=true and idempotentHint=true, so the safety profile is known; the description still adds two things annotations cannot: the authorization requirement (can_manage_scope in the target scope) and the fact that 'body ersetzt die Definition vollstaendig', i.e. no partial merge. It does not say what happens to omitted label/description or whether a scope change moves the function.

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?

Short and front-loaded: action, then the full-replacement warning, then format pointer and permission. The trailing '| EN: function, automation, expression, script, effect' keyword block is search scaffolding rather than instruction, but it is compact and clearly demarcated.

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?

For a destructive mutation with rich annotations but no output schema, the description covers the essentials: what to pass, that the definition is wholly replaced, and the permission needed. Remaining gaps (fate of omitted optional fields, error behavior on a bad udid) are minor given annotation coverage.

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?

Schema description coverage is 100%, so every parameter (body, udid, label, scope_id, description) is already documented in the schema itself; the description's only added nuance is that body is a full replacement. Baseline 3 for a schema that carries the load.

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?

States a concrete verb and resource ('RECHENREGEL aendern: bestehende Function ueberschreiben') and makes the update-vs-create boundary explicit by pointing at onto_function_create for the body format. An agent can tell this apart from onto_function_create/delete/index without opening a schema.

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?

It supplies a real prerequisite ('Rechte: can_manage_scope im Ziel-Scope') and routes the body format to onto_function_create, but it never states when to prefer this over onto_function_create (new function) or onto_function_delete. Usage is implied by the name 'update' more than explained.

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

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

With annotations already declaring readOnlyHint, idempotentHint, non-destructive, and openWorldHint=false, the description reinforces and sharpens this by stating it is purely read-only and does not fetch external map data. It also discloses that ontouser_interface_map_markers returns an identical response, which is useful behavioral context not present in the annotations.

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 core purpose is front-loaded and most sentences earn their place by covering read-only behavior, usage, and the geocode alternative. The trailing '| EN: onto, interface, map, markers' keyword padding is dead weight, and the identical-response sentence could arguably be tighter, but overall it is well structured.

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?

For a two-optional-parameter read tool with full schema coverage and rich annotations, the description covers what is returned (marker objects with coordinates), when to use it, and a fallback for missing coordinates. No output schema exists, and the description adequately describes the return content, leaving only minor gaps about response shape.

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?

Schema coverage is 100% with both parameters documented, so the schema already carries the parameter burden. The description implies the 'interface' parameter through its phrasing but adds no syntax, format, or filtering details beyond what the schema provides, so the baseline 3 applies.

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?

States a specific verb and resource ('Die Kartenmarker eines Interfaces abrufen') and clarifies what the returned markers are (objects with coordinates for map display). It also names related siblings, but since it says ontouser_interface_map_markers provides the identical response, it does not actually help an agent distinguish when to prefer this tool over that one.

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?

Explicitly says to use it for map views ('Nutze es fuer Karten-/Karten-Ansichten') and provides an alternative workflow for missing coordinates via onto_object_geocode. This gives clear positive guidance, though it stops short of stating when not to use the tool or how it differs from its identical-response sibling.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is well covered; 'Rein lesend' merely reinforces it. The description adds genuine value by describing the payload (fields, grouping, visibility) and disclosing that ontouser_interface_show produces the same answer, though it says nothing about auth or rate limits.

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?

Front-loaded with the core action and scoping, and each sentence carries routing information. The trailing '| EN: onto, interface, show' keyword block is search boilerplate rather than prose but is short and harmless.

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?

For a single-parameter read tool with no output schema, the description tells the agent both what is fetched and which sibling to fall back on. The absence of any return-shape detail beyond the listed sub-fields is a minor gap given annotations already carry the safety profile.

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?

Schema coverage is 100% for the single 'name' parameter, so the schema already defines its meaning ('Interface-Name'). The description only indirectly signals the name dependency via 'wenn der Name bekannt ist' and adds no format or syntax detail, making the baseline 3 appropriate.

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?

States a specific verb+resource ('Ein einzelnes Interface vollstaendig lesen') and even enumerates the returned content (enthaltene Felder, Gruppierung, Sichtbarkeit). It explicitly distinguishes itself from the sibling onto_interface_index (no-name case) and notes ontouser_interface_show returns an identical response.

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?

Gives an explicit when-to-use condition ('Nutze es, wenn der Name bekannt ist') and names the alternative for the opposite case ('Ohne Namen: onto_interface_index'). It even resolves the redundancy with ontouser_interface_show by stating the responses are identical.

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

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

Beyond the annotations, it discloses append-only semantics ('bestehende Kommentare bleiben'), that a comment is its own object of type comment linked via hascomment, and the delete path (status becomes deleted, disappears from panel). This is exactly the extra context annotations cannot carry.

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?

Front-loads the action and keeps behavior, usage, and alternatives in tight sentences with no filler. The trailing '| EN: ...' keyword block is extraneous but minor.

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?

For an append-only mutation tool with no output schema, it covers behavior, alternatives, the deletion workflow, and the immutability constraint. Nothing an agent needs 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.

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

Schema coverage is 100%, so the schema already documents all three parameters. The description reinforces that parent is the target object and text is the comment, but adds no format or syntax detail and never mentions scope_id. Baseline 3 is appropriate when the schema does the heavy lifting.

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?

States a specific verb and resource ('Einen Kommentar an ein Objekt anhaengen') plus the resulting artifact ('Verlaufseintrag mit Autor und Zeitstempel'). It clearly distinguishes itself from siblings like onto_object_set_property and onto_object_delete.

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?

Explicitly names the use case ('fuer Notizen und Rueckfragen am Datensatz') and the alternative for a different need ('Es aendert KEINE Properties; dafuer onto_object_set_property'). It also routes the agent to onto_object_delete for removal and states that editing is impossible, so the when/when-not is fully covered.

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

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

The description warns that effects 'koennen nicht zurueckgenommen werden' and that side effects are those of the underlying action (which the schema defines as delete | update), yet the annotations declare destructiveHint=false and readOnlyHint=false. An irreversible bulk delete is materially destructive, so the description contradicts the annotation and an agent relying on the hint could delete far more than intended.

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 two operational sentences are compact and front-loaded: purpose, then usage, then the irreversibility warning and prerequisite. The trailing '| EN: object, record, entry, property, link, search' keyword tail is search-engine padding that earns no place for an agent, which keeps this out of the top band.

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?

For a multi-object mutation with 6 parameters and no output schema, the description covers purpose, usage, irreversibility and the narrowing prerequisite, but says nothing about the return shape (per-object success/failure?), partial-failure semantics, batch size limits, or permission requirements. Those gaps matter for a bulk destructive operation.

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?

Schema description coverage is 100% — every parameter, including the action=update-only conditionals for name, status, scope_id and external_id, is documented inline. The description adds no syntax, format, or value guidance beyond what the schema already states, so the baseline of 3 applies.

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?

States a specific verb and resource with its scope: 'Dieselbe Aktion auf viele Objekte in einem Aufruf anwenden (Massenbearbeitung)'. It implicitly distinguishes itself from the single-object siblings (onto_object_update, onto_object_delete, onto_object_execute_action) by framing itself as the batch alternative to 'einer Schleife aus Einzelaufrufen'.

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?

Gives an explicit trigger ('ab mehreren Datensaetzen statt einer Schleife aus Einzelaufrufen'), names the alternative practice it replaces (looping single calls), and specifies a prerequisite step with a named sibling ('vorher mit onto_object_index die Zielmenge eingrenzen'). Nothing about when to reach for this tool is left to inference.

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

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

Annotations already declare the mutation profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the safety burden is partly covered. The description adds real value beyond that: 'kein Trockenlauf' (no dry run) and the important caveat that links are NOT created automatically, redirecting to onto_object_create_link. It does not describe error behavior or whether partial writes roll back.

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?

Core sentences are front-loaded and information-dense, but the trailing '| EN: object, record, entry, property, link, search' keyword block is pure search-index filler that adds length without meaning. The substantive content itself is tight.

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?

For a mutation tool with no output schema and full schema coverage, the description covers the important gaps: it confirms a real write, warns of no dry run, and pre-empts the most likely wrong sibling (link creation). Only rollback/permission behavior is unaddressed.

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?

Schema coverage is 100%, so the schema documents all six parameters and the baseline is 3. The description restates properties/interfaces semantics and adds a required-field note, but that note says 'mindestens type' while the schema actually requires both type AND name, which risks an agent treating name as optional.

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?

States a specific verb and resource ('Ein neues Objekt anlegen') and immediately distinguishes itself from the sibling read/update/link tools. An agent can separate it from onto_object_update, onto_object_set_property, and onto_object_create_link without opening a schema.

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?

Explicit when-to-use ('fuer neue Datensaetze') plus named alternatives for the adjacent cases ('zum Aendern ... nimm onto_object_update oder onto_object_set_property', and onto_object_create_link for links). Nothing about routing is left to inference.

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

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

The description states repeated calls do not create duplicates but update the edge, which implies idempotent behavior. Annotations set idempotentHint=false, directly contradicting this claim. Per the scoring rule, a contradiction caps this dimension at 1.

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 front-loaded with purpose, then behavior, then alternatives. It is concise overall, though the trailing '| EN: object, record, entry...' synonym list is search-oriented noise rather than useful agent guidance.

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?

For a 6-parameter mutation with no output schema, the description covers creation, duplicate handling, link-type discovery, and the update alternative. Annotations carry the safety profile, though the idempotency conflict is a notable caveat.

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?

Schema description coverage is 100%, so the baseline is 3. The description references link type and objects but adds no syntax, allowed values, or guidance for scope_id, linkvalue, or linkvalue_free 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?

States a specific verb and resource: connect two objects via a link type. Explicitly names the sibling tools onto_link_index and onto_object_update_link, distinguishing creation from link-type lookup and edge update.

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?

Explains when to use this tool (connecting two objects), where to discover available link types (onto_link_index), and which alternative handles existing edges (onto_object_update_link). The when-not case is covered by naming the update tool.

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

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

Annotations already declare destructiveHint=true, so the safety profile is known; the description still adds real value by naming the cascade ('samt seiner Properties') and emphasizing irreversibility with no undo. It does not say whether links or comments attached to the object are also removed, which is the remaining gap for a destructive operation.

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 operational content is front-loaded in three tight sentences with the destructive warning first. The trailing '| EN: object, record, entry, property, link, search' keyword block is search-oriented filler that slightly dilutes an otherwise efficient definition.

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?

For a one-parameter destructive tool with no output schema and full annotation coverage, the description supplies the essential context: irreversibility, cascading deletion of properties, and escape hatches. Only the treatment of dependent links/comments is left unspecified.

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?

Schema coverage is 100% and the single parameter 'udid' is documented there as 'Objekt-udid', so the schema carries the semantics. The description adds no format, scope, or validation detail beyond it — the baseline 3 applies.

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?

States a specific verb and resource ('Ein Objekt unwiderruflich loeschen') and adds scope: the object's properties are removed with it. An agent can distinguish this from onto_object_update or onto_object_bulk_action without opening any schema.

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?

Explicitly bounds usage ('nur, wenn der Datensatz wirklich entfallen soll — es gibt kein Undo') and routes to two named alternatives: onto_object_set_property for deactivate/archive and onto_object_bulk_action for multiple objects. This is a textbook when/when-not/alternative statement.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=true, so the safety profile is partly covered. The description still adds genuinely useful context beyond them: exactly what is destroyed (only the edge, not the objects) and that the operation is irreversible. It says nothing about permissions or auth requirements, so it is not fully rich.

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 core content is front-loaded and tight: removal, scope of deletion, irreversibility, inverse tool. The trailing '| EN: object, record, entry, property, link, search' keyword block adds little selection value for an agent and slightly dilutes an otherwise efficient definition.

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?

For a one-parameter destructive operation whose annotations already carry the safety profile, the description covers everything an agent needs: what is deleted, what survives, irreversibility, and the inverse operation. No output schema is needed for a deletion result.

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?

There is a single required parameter with 100% schema description coverage, so the baseline is 3. The description adds no meaning about link_udid itself, and the schema's own label ('Link-udid') is essentially tautological, leaving the identifier format undocumented in both places.

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?

States a specific verb and resource ('Eine Verknuepfung zwischen zwei Objekten entfernen') and immediately delimits scope by clarifying that only the edge is removed, not the participating objects. That scope distinction cleanly separates it from the many sibling delete tools (onto_object_delete, onto_object_delete_property, onto_file_delete).

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?

Gives clear context (removing an edge) and routes to the inverse operation onto_object_create_link when the goal is creation. It does not mention onto_object_update_link as the alternative for modifying rather than removing a link, so the when-not guidance is incomplete but the primary routing is explicit.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is partly carried structurally. The description still adds real context beyond them: the operation is irreversible ('Unwiderruflich') and, crucially, that only the value is removed while the object itself survives — a non-obvious behavioral distinction from the sibling delete tool.

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 core action, its irreversibility, and both alternatives are front-loaded and waste-free. The trailing English keyword tail ('object, record, entry, property, link, search') is search-oriented padding rather than agent-facing instruction, which slightly dilutes an otherwise tight two-sentence description.

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?

With no output schema, the description carries the return-behavior burden and does so adequately by stating the value vanishes and the object remains. Parameters are fully covered by the schema and safety is covered by annotations, leaving only minor gaps such as no-op behavior for a missing key.

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?

Schema coverage is 100% with two required params (udid, key), so the schema already documents both fully. The description's mention of 'Property' and 'Objekt' maps to those params but adds no format, syntax, or edge-case detail (e.g. what happens if the key does not exist). Baseline 3 is appropriate.

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?

States a specific verb and resource ('Ein einzelnes Property von einem Objekt entfernen') and immediately scopes it with the parenthetical that the value disappears but the object remains. It explicitly differentiates from two siblings by name (onto_object_set_property for clearing a value, onto_object_delete for the whole object), so an agent can route correctly without opening any schema.

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?

Gives an explicit use case ('zum Aufraeumen fehlerhafter Felder') and names both alternatives with the condition that selects each: set_property with an empty value to clear a value, onto_object_delete to remove the whole object. This is the when/when-not/alternative pattern done fully.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is covered. The description adds genuine value beyond that: the effect is contingent on the action definition and may mutate properties, create links, or launch follow-up processes — important context for an agent that cannot predict the outcome from the call signature.

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 two German sentences are front-loaded and information-dense, but the trailing '| EN: object, record, entry, property, link, search' keyword list is SEO-style padding that adds no invocation value for an agent. Removing it would leave a tight, well-ordered definition.

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?

For a mutation tool with no output schema, the description covers the essentials: it is a write operation, the outcome is action-dependent, and discovery happens via onto_actiondef_list. It stops short of saying what is returned on success/failure or whether prompts is conditionally required, but nothing critical for correct invocation is missing.

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?

Schema description coverage is 100%, so udid, action_key and the prompts object are already documented in the schema, establishing a baseline of 3. The description adds no syntax or format guidance for 'prompts' ({key: value}) or for how action_key relates to the action definitions, so it does not rise above baseline.

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?

States a specific verb and resource ('eine hinterlegte Action (Button/Automatik) auf einem Objekt ausfuehren') and explicitly distinguishes itself from read-only siblings by noting the effect is 'nicht rein lesend'. An agent can tell it apart from onto_object_set_property or onto_function_run without opening any schema.

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?

Gives an explicit trigger ('Nutze es, wenn am Objekt eine Action angeboten wird') and routes the agent to the discovery tool 'onto_actiondef_list' for available actions. It lacks a when-not-to-use clause (e.g. use set_property for direct edits), but the positive routing is clear.

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

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

Annotations already declare readOnlyHint=false and openWorldHint=true, covering the write and external-service profile. The description confirms it writes into the object and calls an external map service, but adds little beyond what the annotations and the apply parameter already convey. No disclosure of rate limits, failure behavior, or reversibility.

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?

Purpose, behavior, and the sibling alternative are front-loaded and readable. The trailing 'EN: object, record, entry, property, link, search' keyword list is SEO-style filler that does not earn its place, slightly weakening an otherwise tight definition.

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?

For a mutation tool that calls an external service with no output schema, the description plus annotations cover the essentials: what it does, when to use it, the write target, and the display alternative. Only error/return behavior is unaddressed, which is minor given annotations carry the safety profile.

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?

Schema coverage is 100%, so udid, apply, and direction are all documented in the schema itself. The description's 'Adresse -> Lat/Lon' merely echoes the default geocode direction and adds no syntax or format detail beyond the schema. Baseline 3 is appropriate.

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?

States a specific verb and resource (coordinates for an object, address -> Lat/Lon) and explicitly notes it writes into the object. It also differentiates from the sibling onto_interface_map_markers, so an agent can distinguish it without opening any schema.

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?

Gives a clear when-to-use rule ('nach dem Anlegen eines Objekts mit Adresse, wenn Kartenmarker gebraucht werden') and routes display needs to onto_interface_map_markers. It lacks an explicit when-not condition, but the alternative is named and the trigger context is concrete.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so 'Rein lesend' largely restates structured data. The description does add the return shape (nodes + edges), which matters because there is no output schema, but it omits traversal depth, size limits, and pagination behavior for what is effectively a graph read.

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?

Two short, front-loaded sentences with the core purpose first and routing second; no wasted clauses. The trailing '| EN: object, record, entry, property, link, search' keyword line is retrieval padding rather than agent-facing guidance, which slightly dilutes the 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?

For a single-param, read-only tool with no output schema, the description covers purpose, return shape (Knoten + Kanten), and sibling routing, which is enough to call it correctly. The only gap is traversal scope (depth or result caps), a minor omission given the annotation-declared safe read profile.

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?

Only one parameter (id) with 100% schema description coverage ('Objekt-udid (32-hex)'), so the schema already carries the semantics. The description adds nothing about id format or what happens on an unknown id, leaving the baseline of 3 appropriate.

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?

States a specific verb and resource ('Ein Objekt samt seinen Verknuepfungen als Graph lesen (Knoten + Kanten)') and immediately differentiates itself from the two nearest siblings, onto_object_show and onto_link_index. An agent can pick this tool without opening any schema.

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?

Explicit when-to-use ('fuer Beziehungsfragen') plus explicit alternatives with their selecting conditions: onto_object_show for a pure field view, onto_link_index for all link definitions. Nothing is left to inference.

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

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, and 'Rein lesend' merely restates that. The description does add some behavioral context (result sets are paginated, useful for overviews and counts), but discloses nothing about return shape, total counts, or limits beyond what the schema states. Adequate but thin against an annotation set that already covers safety.

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?

Front-loaded with the core action, then the routing advice, so the most important content comes first. The trailing '| EN: object, record, entry, property, link, search' keyword block is noise rather than definition and slightly bloats an otherwise tight entry.

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?

For a two-parameter read-only list tool with no output schema, the description covers purpose, safety, and routing well enough to invoke it. The gap is the phantom 'Filter' mention, which is unresolved by schema or annotations, and no hint about result shape or pagination limits beyond the schema's default.

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?

Schema description coverage is 100%, so page/limit are fully documented in the schema and the description needn't repeat them. However, the description advertises 'nach optionalem Filter', a filtering capability that no parameter in the schema exposes, which can send the agent hunting for a filter argument that does not exist. Slightly below the coverage-based baseline because of this inaccurate hint.

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?

States a specific verb and resource ('Alle Objekte auflisten') plus scope modifiers (paginated, optional filter), so the agent immediately knows this is a list/overview endpoint. It explicitly differentiates itself by naming the two closest siblings, onto_object_show and onto_object_search, and the condition that picks each.

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?

Gives explicit when-to-use ('fuer Uebersichten und Zaehlungen') and when-not-to-use routing: use onto_object_show when you already know a udid (and notes it is cheaper), and onto_object_search for full-text search across multiple fields. This is exactly the when/when-not/alternatives guidance that makes sibling selection unambiguous.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so 'Rein lesend' merely restates structured data. The description adds the useful ordering context (entry before onto_object_show), but says nothing about result format, pagination behavior, or match semantics beyond what the schema fields imply.

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?

Front-loaded with the core action and usage guidance, and every core sentence earns its place. The trailing '| EN: object, record, entry, property, link, search' keyword block is SEO filler that adds little for an agent, keeping it from a perfect score.

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?

For a read-only, fully-documented search tool with safety annotations and no output schema, the description covers purpose, usage routing, and read-only nature adequately. Minor gaps around pagination/result behavior are already handled by the documented page/per_page fields.

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?

Schema description coverage is 100%, so all six parameters are already documented in the schema. The description's 'Filter/Textsuche ueber Properties' loosely implies the q/type/linktype filtering intent but adds no syntax, format, or edge-case detail. Baseline 3 is appropriate when the schema does the heavy lifting.

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?

States a specific verb+resource ('Objekte ueber ihre Feldwerte suchen' / filter/text search over properties) and explicitly differentiates from siblings onto_object_show and onto_object_search_scopes. An agent can identify this as the entry-point search tool without opening any schema.

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?

Gives an explicit when-to-use condition ('wenn du Objekte NICHT ueber die udid kennst') plus two named alternatives with their selecting conditions (onto_object_show for known udids, onto_object_search_scopes for pure scope selection). Routing is unambiguous.

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

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

Annotations already flag destructiveHint=true and idempotentHint=true, and the description adds context beyond them: the previous value is irretrievably lost (no history, no undo). It also discloses non-obvious timezone semantics for temporal properties, including that stored/output values are UTC and that sending UTC produces an offset. That is unusually rich behavioral disclosure.

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?

Front-loads the core action, then routing, then irreversible-loss warning, then timezone caveat — a sensible priority order with little waste. The mixed German/English and the trailing 'EN: object, record, entry, property, link, search' keyword tag are mildly noisy but conventional and do not obscure the payload.

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?

For a destructive mutation tool with no output schema and full schema coverage, the description covers everything an agent needs: what it mutates, irreversibility, alternatives for other intents, and value-format/timezone behavior. No material gap remains.

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?

Schema coverage is 100%, so key, udid, and value are already documented and the baseline would be 3. The description adds genuine meaning for the value parameter by explaining timezone interpretation and storage format for date properties, though scope_id is never mentioned and no added syntax is given for the core fields.

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?

States a specific verb and resource with exact scope: set or overwrite exactly one property of an object. It explicitly differentiates itself from siblings onto_object_update (multiple fields) and onto_object_delete_property (removal), so an agent can select it without opening any schema.

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?

Gives explicit when-to-use ('gezielte Einzelkorrekturen') and names two alternatives with the conditions that select them: onto_object_update for several fields at once and onto_object_delete_property for removal. Nothing about routing is left to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so 'Rein lesend' is largely redundant. However, the description adds real behavioral value beyond the annotations: the read is complete (all properties and interfaces, not a summary), and a functionally identical sibling tool exists. It does not describe failure behavior for an unknown udid.

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?

Front-loaded with the core purpose and constraint, and each sentence carries routing value. The trailing '| EN: object, record, entry, property, link, search' keyword tag is padding that does not help an agent decide or invoke, which keeps it out of the top score.

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?

For a single-parameter read tool with full annotation coverage and no output schema, the description covers purpose, precondition, alternatives and an equivalent tool, so an agent has what it needs. The only unaddressed area is error behavior when the udid does not resolve, which is minor here.

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?

Schema description coverage is 100% and the schema already documents udid as a 32-hex object identifier. The description only repeats that the lookup is by udid and that the udid must already be known, adding no format or constraint detail beyond the schema. Baseline 3 applies when the schema carries the parameter burden.

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?

States a specific verb and resource: fully reading a single object by its udid, including all properties and interfaces. It explicitly names the sibling it is not (onto_object_search/onto_object_index for finding udids) and the near-duplicate (ontouser_object_show), so an agent can distinguish it without opening any schema.

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?

Gives an explicit precondition (use it when you already have the udid) and routes the agent to alternatives when the precondition fails (without udid, use onto_object_search or onto_object_index first). It also tells the agent that ontouser_object_show returns an identical answer, which is exactly the routing information needed.

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

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

Annotations already cover the safety profile (destructiveHint=true, idempotentHint=true, readOnly=false), but the description adds real substance: passed properties are overwritten, unmentioned fields are left untouched, and the previous value is gone with no history and no undo. That spells out precisely what the destructive flag means in practice, which the annotation alone does not.

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 front-loaded with purpose, then behavior, alternative, and exclusion in tight sentences. The trailing '| EN: object, record, entry, property, link, search' keyword block is search-oriented filler that adds no invocation value, so it falls just short of a 5.

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?

For a mutation tool with no output schema and full schema coverage, the description supplies everything an agent needs: what is updated, what is preserved, the alternative for single edits, and the irreversibility of the change. Nothing material is missing.

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?

Schema description coverage is 100% and each of the six fields (name, status, pin_url, scope_id, external_id, object_udid) is already documented in the schema. The description adds no per-parameter syntax or format detail beyond the partial-update semantics, so the baseline 3 applies.

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 opens with a precise verb+resource+scope: it changes multiple fields of an existing object in a single call. It explicitly distinguishes itself from onto_object_set_property (single-field alternative) and clarifies that deletion is out of scope, so an agent can separate it from onto_object_delete and onto_object_set_property without opening schemas.

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?

It gives an explicit when-to-use rule ('fuer mehrere Aenderungen gleichzeitig') and names the alternative for the single-field case ('fuer ein einzelnes Feld ist onto_object_set_property schlanker'). It also states an exclusion (deletion is not part of this tool), which is exactly the routing guidance needed among the many onto_object_* siblings.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is partly covered. The description still adds real value by specifying exactly what is destroyed — the previous value is gone with no history and no undo — which annotations alone do not convey. It does not address permissions or which fields are optional.

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 three operative sentences are front-loaded and each earns its place: scope, exclusion, irreversibility. The trailing '| EN: object, record, entry, property, link, search' keyword blob adds no instruction and dilutes the otherwise tight 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?

For a 4-parameter mutation tool with no output schema, the description covers purpose, alternatives, and the destructive consequence. Combined with destructiveHint/idempotentHint annotations, an agent has enough to call it correctly; only permission requirements are unstated.

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?

Schema description coverage is 100%, so the schema already documents all four parameters; baseline 3 applies. The mention of roles/weighting hints at what linkvalue carries, but no syntax, format, or interplay between linkvalue and linkvalue_free is explained.

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?

States a specific verb+resource ('Eigenschaften einer BESTEHENDEN Verknuepfung aendern') with a concrete example (Rollen, Gewichtung der Kante). It explicitly separates itself from onto_object_create_link and onto_object_delete_link, so an agent can distinguish it from its closest siblings without opening a schema.

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?

Names the two adjacent tools an agent might confuse this with and the condition selecting each: not for creating (use onto_object_create_link), and for removal use onto_object_delete_link. The 'existing link' constraint is stated up front as a precondition.

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

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

Annotations already declare the safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false). The description adds genuinely non-obvious context beyond them: it mutates the schema and 'bestehende Objekte haben das Feld danach leer', i.e. a real side effect on existing data. It does not discuss permissions, though the schema's scope_id description carries that detail.

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 useful content (purpose, side effect, routing) is front-loaded and terse. The trailing '| EN: property, field, schema...' keyword dump is a minor structural wart that pads the definition without adding invocation guidance.

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?

For a 10-parameter mutation tool with full schema coverage and annotations present, the description covers purpose, side effects, and sibling routing. Nothing critical is missing; only permission/authorization nuance and return behavior are absent, and those are handled elsewhere or not applicable (no output schema).

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?

Schema description coverage is 100% and the parameter descriptions are detailed (scope_id even documents can_manage_scope/admin requirements), so the schema does the heavy lifting. The description adds no parameter-level meaning of its own; baseline 3 applies.

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?

States a specific verb and resource ('Eine neue Property-Definition anlegen') and glosses it concretely as 'neues Feld im Objektmodell'. It also explicitly distinguishes itself from onto_object_set_property, so an agent can tell it apart from the value-setting sibling without opening either schema.

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?

'Nutze es beim Modellaufbau' gives the positive context (schema/model construction phase), and the sentence naming onto_object_set_property as the tool for setting VALUES gives the explicit exclusion. Both when-to-use and when-not-to-use are stated.

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

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

The annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false and openWorldHint=false, so the safety profile is carried by structured data, not the prose. The description adds no behavioral context (what an 'override definition' is, what gets destroyed, whether it cascades), so it neither helps nor contradicts the annotations.

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?

It is short, but it is a tag dump rather than front-loaded prose. Length is not the problem; there is no informational payload for an agent to act on.

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?

For a destructive, non-idempotent delete of a schema override with no output schema, the description should at minimum state the effect on the underlying property definition. It conveys nothing beyond the tool name, leaving the agent to infer everything from annotations and the schema.

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?

Schema description coverage is 100%: def_id and scope_id are both documented in-schema, and def_id’s description even cross-references 'die Zeile mit scope_id'. The description contributes no additional parameter meaning, which is the baseline-3 situation when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.