Skip to main content
Glama

ontouser_scope_assign_public

Einem anderen Konto Zugriff auf einen oeffentlichen Scope geben (buchen). Schreibt eine Zuordnung und kann Credits kosten — vorher onto_credit_pricing pruefen. Nutze es, um einen fremden oeffentlichen Scope zu nutzen. Den Zugang wieder entziehen: ontouser_scope_remove_public. Verfuegbare Scopes zeigt ontouser_scope_list_public. | EN: end user, customer, portal, notification, map, scope

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
scope_idYesPublic-Scope-ID, den du als Read buchen willst. Der Scope-Owner erhält dabei eine Credit-Gutschrift (Earnings, pricing scope_earnings)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added
  2. Removed
  3. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false. Beyond that, the description discloses that the call writes an assignment and may cost credits, and that the scope owner receives an earnings credit — meaningful side-effect context the annotations do not capture. It stops short of covering permissions or failure modes, so not 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.

Conciseness4/5

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

Front-loads the core action, then the cost warning, then the alternatives — a sensible order. Slightly long with the trailing 'EN:' keyword tag that adds little invocation value, but no wasted sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter mutating tool with no output schema, the description covers purpose, cost side effect, prerequisite check, and sibling alternatives. It is nearly complete; only explicit failure/permission behavior is absent, which keeps it from a 5.

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

Parameters3/5

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

Schema coverage is 100%, so the single scope_id parameter is already documented, including the owner-credit/earnings detail. The description adds no parameter syntax or format 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.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: granting another account access to a public scope ('buchen'), and clarifies it writes an assignment. It explicitly distinguishes itself from the sibling ontouser_scope_remove_public (revoke) and ontouser_scope_list_public (discovery), so an agent can separate the three 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.

Usage Guidelines5/5

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

Gives a clear when-to-use condition ('um einen fremden oeffentlichen Scope zu nutzen'), a mandatory prerequisite ('vorher onto_credit_pricing pruefen'), and names the exact alternatives for the opposite (remove_public) and preparatory (list_public) actions. Routing is fully specified.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.