agentView

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

Annotations already flag destructiveHint=true and idempotentHint=true, but the description adds the crucial behavioral nuance of what actually gets destroyed: replace 'sets the full category list' (overwrites all assignments), while add/remove does so 'without touching other assignments.' This is exactly the 'what gets destroyed' context the rubric credits, and it is consistent with 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?

Two dense sentences with no filler. The core action is front-loaded, mode semantics follow in order of importance, and the sibling-tool routing is one tight clause at the end. Every sentence earns its 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 destructive, multi-mode tool, the description covers modes, defaults, scoping behavior, and ID discovery/creation routing. With annotations covering the safety profile, a 100%-covered schema, and an output schema present, the only notable gap is failure/partial-failure semantics (e.g., behavior when a display_id is invalid), which is minor.

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 cross-parameter semantics the schema's individual field descriptions don't fully convey: how display_ids and category_ids interact differently per mode, that replace sets the full list per display, and that add/remove applies one category across many displays. This goes beyond merely restating 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?

Opens with a specific verb+resource: 'Assigns displays to categories.' The three modes (replace/add/remove) are each defined with precise semantics, and the description names the two most confusable siblings (list_display_categories, manage_display_category) and what each is for, so an agent can tell assignment apart from discovery and creation without opening their 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?

Provides explicit when-to-use guidance per mode: replace for setting the exact category list, add/remove for surgically mutating one category across many displays. It also names alternatives for adjacent operations ('Discover IDs with list_display_categories; create categories with manage_display_category'), which is clear routing against the sibling set.

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 adds a valuable behavioral trait beyond the annotations: 'It caches NOTHING: no server-side state remembers this call, so the credential still travels on every protected call afterwards.' This explains the statelessness and its practical consequence. Annotations already provide idempotentHint and destructiveHint, so the description's extra context earns a 4 rather than 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?

Three sentences, each with a distinct purpose: purpose, behavioral caveat, and usage routing. No filler words, and the most important information is 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?

The description covers what the tool does, when it should and shouldn't be used, and the crucial consequence of its statelessness. With an output schema available to describe return values, nothing essential 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%, with all three parameters (jwt, token, access_token) fully described, including aliases and usage warnings. The description does not add parameter-level detail, 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 first sentence states a specific verb and resource: 'Validates a JWT agent token and reports the identity and scope it carries.' It clearly distinguishes this tool from create_auth_session (session_request_id-based auth) and get_auth_session (active status) in the same description.

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 explicitly states when to use it ('Use only when your client cannot send an Authorization: Bearer header'), names the preferred alternative (create_auth_session), and gives a negative condition ('Not needed after get_auth_session returned active'). This is complete routing 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 signal destructive mutation, read/write behavior, and non-idempotence. The description adds behavioral disclosures beyond the annotations: locked displays are skipped with reasons, all=true means 'every accessible display', and dry_run previews without sending. It also states the auth requirement 'Requires content scope'.

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?

Three compact sentences front-load the core purpose and then layer targeting, preview, and constraints. No filler or redundant restatement of the schema.

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 11-parameter broadcast tool with an output schema present, the description covers auth scope, targeting modes, locked-display failure behavior, and alternative routing. It stops short of stating explicit conflict rules between targeting parameters, but the 'or' phrasing and full schema coverage make the remaining ambiguity minor.

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?

While the schema covers 100% of parameters, the description adds grouping semantics: it identifies the three mutually exclusive targeting strategies ('explicit display_ids, all=true... or include_category_ids'), explains include_descendants as subcategory expansion, and positions dry_run as a preview option across all modes. This synthesis is value beyond the per-parameter 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?

The opening sentence 'Sends HTML to many displays at once' states a specific verb plus resource and scope. It distinguishes itself from send_html with 'For a single display use send_html', and names the three targeting modes. This leaves no ambiguity about what the tool is for.

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 explicitly tells the agent when to prefer the sibling send_html ('For a single display') and when broadcast_content is appropriate (explicit display_ids, all=true, or include_category_ids). It also covers preview with dry_run and subcategory expansion with include_descendants, giving concrete selection context.

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 provide generic false hints, so the description carries the burden. It discloses permanence ('permanent ownership transfer'), quota impact, and admin scope requirement. It does not contradict annotations; no conflict with destructiveHint=false since a transfer is not necessarily destructive.

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 sentences, front-loaded with action and consequences, then usage guidance and auth requirement. No filler or repetition of schema text.

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 an output schema present and all parameters documented, the description covers the essential behavioral, usage, and auth context. It even names the alternative tool to keep the agent on the right path. No critical gap for invoking 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 each parameter already has a descriptive schema comment, so the baseline is 3. The description reaffirms that display_id refers to an unclaimed/pending display and profile_name is the new friendly name but adds little 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 ('Adopts') and resource ('unclaimed guest or pending display'), and clarifies the result ('permanent ownership transfer, counts against quota'). It is clearly distinguishable from the sibling pair_by_code, which is called out 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?

Explicitly instructs when to use ('only when the user explicitly wants to take over hardware already running') and when not to ('for first-time setup prefer pair_by_code'). Also states required permission (admin scope).

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 destructive/idempotent/readOnly hints. The description adds the authentication scope requirement ('Requires authentication with at least content_only scope') and the immediate viewer effect ('Viewers will immediately see the change'), which go beyond annotations. No 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?

Six short sentences, each adding distinct value: action, effect, usage, alternative, auth, return. Front-loaded with the core operation and effect, minimal fluff.

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 that an output schema exists, the description still covers effects, auth scope, and sibling distinction. Nothing an agent needs to decide and invoke 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 covers 100% of parameters including descriptions for display_id, access_token, and session_request_id. The description adds no new parameter-specific meaning beyond the schema, 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?

Clear verb+resource: 'Removes the current live content from a display and returns it to its idle/default state.' Differentiates from delete_display by explicitly stating 'This does not delete the display itself.'

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 ('when the user wants to blank or reset a display'), names the alternative ('use delete_display for that'), and provides the auth prerequisite. Clear routing among 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 indicate destructiveHint=true and readOnlyHint=false. The description adds meaningful behavioral context beyond annotations: partial updates, immediate effect for online displays, and the admin scope requirement. It doesn't contradict annotations and provides extra operational 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 description is compact and well-ordered: a list of settings up front, then behavior/constraints, then usage guidance. Every sentence contributes value without redundancy.

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 tool's complexity (17 parameters, many boolean toggles), the description covers the essential behavior, scope, and known caveats. The output schema exists, so return format is not needed. The main missing details are some parameter descriptions, but those are already in the input schema, so the description is sufficiently complete for an agent to use 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 59%, so the description should compensate for undocumented parameters. It does explain many: rename, lock/unlock, privacy mode, origins, hardware permissions, language, cursor, badge, watermark. However, several parameters (whitelist, strict_whitelist, connectivity_mode, access_token, session_request_id) are not described, leaving some ambiguity that the schema partially offsets.

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 clearly states the verb ('Updates'), the resource ('display settings'), and enumerates the specific settings. It explicitly distinguishes itself from sibling operations by naming what it is not for ('Not for sending content (send_html, send_url) or deleting (delete_display)').

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 'Use for any display setting change' and provides exclusions with alternative tool names. Also clarifies partial-update semantics ('Only the fields you pass are changed') and immediacy for online displays, which guides call timing.

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, destructiveHint=true, and idempotentHint=true, so the mutation and idempotency are known. The description adds value by noting 'Only provided fields change' (partial update behavior) and requiring 'admin scope and org-admin role', which are not in annotations. No contradiction with annotations exists.

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 sentences with no fluff. The action and fields are front-loaded, followed by usage guidance and auth. Every sentence contributes essential information, and the structure is clean and scannable.

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?

The tool has 6 parameters and an output schema (not shown), so return values are covered elsewhere. The description includes the action, scope, partial-update behavior, use case, and required permissions. It lacks any mention of side effects beyond mutation (which destructiveHint covers) but is otherwise complete for an agent to use 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%, so all parameters are already documented. The description adds only a general note that only provided fields change, which applies to all parameters rather than individual semantics. It does not explain enum values or parameter relationships beyond the schema, 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 description clearly states the tool 'Updates organization settings' and enumerates the specific fields (name, default_connectivity_mode, global_whitelist), distinguishing it from create/delete/configure_display tools. The scope 'for all its displays' clarifies it operates at the org level, separating it from per-display configuration.

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 provides an explicit 'Use when an org admin renames the organization or declares network topology' condition, which is direct guidance. It does not explicitly mention alternatives (e.g., configure_display for per-display settings), but the scope statement 'for all its displays' implies the distinction, making the usage context 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?

Beyond the minimal annotations, the description discloses high-value behavioral traits: the raw key appears only once and must be stored securely, creation requires explicit user consent, and admin scope is required. This is exactly the kind of operational context an agent needs and cannot infer from the schema 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?

Three tight sentences front-load the purpose, then the critical security/authorization facts, then the scoping options. There is no filler and every sentence contributes meaning an agent needs before calling the tool.

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 tool with a full output schema and minimal annotations, this description covers the non-obvious constraints: one-time secret, consent, admin scope, and the four scoping dimensions. The remaining details are safely carried by the 100%-covered schema and the 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%, so each of the 10 parameters is already well documented. The description summarizes the granular scoping model (data-slot slugs, display IDs, read/write flag, capability flags) and maps cleanly to the relevant parameters, but it does not add per-parameter semantics 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?

The description states a specific verb and resource ('Creates a long-lived API key') and immediately distinguishes the tool from session-based alternatives by noting 'server-to-server integration without OAuth'. It also clarifies what kind of key is created and adds the meaningful constraint that the raw key is returned only once.

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 gives clear usage context: use this for server-to-server integration without OAuth, with explicit user consent and admin scope required. It does not explicitly name alternatives like create_auth_session or say 'use X instead', but the context strongly implies the session-based sibling is not the right choice for long-lived integration keys.

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 discloses key behavioral traits: it starts a login process, returns a sessionRequestId and loginUrl, and requires polling. It does not contradict annotations, and since annotations provide no safety hints, the description carries the full burden effectively.

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 three concise sentences. Front-loaded with the main action, followed by immediate usage guidelines, then additional steps. No unnecessary words.

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 complexity of an authentication flow, the description provides a complete step-by-step guide: start session, present loginUrl, poll for active status, and pass session_request_id everywhere. The existence of an output schema covers return values.

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 baseline is 3. The description adds value by explaining the scope enum values (content_only vs admin) and providing an example for agent_identifier, though it doesn't describe each parameter in detail.

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 exactly what the tool does: 'Starts a browser login and returns a loginUrl plus sessionRequestId.' It uses specific verbs and resources, and distinguishes itself from siblings by being the first step in authentication.

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 'Use as STEP 0 in a fresh conversation before any protected tool.' It provides clear instructions on showing the loginUrl to the user, polling get_auth_session, and passing session_request_id on later calls.

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 annotations, the description discloses that the new display starts offline, requires admin scope, and returns setup and pairing URLs. This adds meaningful behavioral context. It doesn't describe all edge cases, but the annotations already cover read-only, destructive, open-world, and idempotency traits.

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 compact and well-structured: it states the core purpose first, then usage guidance, then access requirements and return value. Every sentence earns its place with no redundancy.

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 tool with this complexity, the description covers purpose, when to use, auth requirement, initial state, and return payload. Combined with the fully documented schema and output schema, nothing essential is missing for an agent to invoke it 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%, so the parameters are fully documented in the schema. The description adds some semantic value by mentioning org_id and the pairing URL return, but it does not need to explain each parameter further.

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 uses a specific verb–resource pair ('Pre-provisions a display') and clarifies that the display is created without hardware, either personally or in an organization. It explicitly distinguishes itself from pair_by_code, so the agent can confidently differentiate it from the closest sibling.

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 gives explicit guidance: for physical screens ALWAYS prefer pair_by_code, and create_display should only be used to prepare a display before hardware exists or for virtual/API-only displays. This clearly states when to use and when not to use the tool, naming the alternative.

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, the description discloses that the user becomes owner, that admin scope is required, and what fields are returned. This materially helps an agent anticipate side effects and the shape of a successful response, which is valuable for a mutation 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?

Three concise sentences cover action, use case, return values, and scope requirement. It is front-loaded with the core purpose and contains no redundant 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 straightforward create tool with full schema coverage and an output schema, the description is complete enough: it states the operation, the use case, the ownership side effect, returned values, and required scope. Nothing essential for calling 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 description coverage is 100%, so the schema already explains all four parameters, including the enum and auth fields. The description adds no parameter-specific detail beyond mentioning the returned fields and admin scope, so it meets the baseline without over-delivering.

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 uses a specific verb and resource ('Creates a new organization') and adds the key detail that the authenticated user becomes owner, which differentiates it from configure_organization and delete_organization. It also ties the tool to a concrete context, setting up a shared display fleet, which makes the purpose unambiguous.

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 provides an explicit usage condition ('Use this when the user wants to set up a shared display fleet') and notes the admin scope requirement. However, it doesn't mention when not to use it or how it compares to related tools like configure_organization, list_organizations, or delete_organization, leaving some routing 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 destructiveHint=true and idempotentHint=false, and the description does not contradict them. It adds useful behavioral context beyond the annotations by warning that displays referencing deleted assets will show broken images and by specifying the required auth scope.

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 only two sentences, front-loads the core action, and each remaining sentence adds a distinct, valuable detail (side effect and auth requirement). There is no redundancy or 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 simple destructive tool with an output schema and annotations covering destructiveness/idempotence, the description provides the essential selection and invocation context: action, plural scope, consequence, and authentication. It does not discuss partial failure behavior or ID provenance, but those are not necessary for correct basic use.

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 already documented. The description adds no meaningful parameter-level semantics beyond repeating that multiple assets can be deleted; this matches the baseline 3 for high schema 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?

The description states a specific action ('Deletes') on a specific resource ('one or more assets'), and the scope ('one or more') adds precision. It is immediately distinguishable from sibling delete_* tools and from update_asset/upload_asset/get_asset by the verb+resource combination.

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 provides clear usage context: this tool is for deleting assets, with a prerequisite ('Requires authentication with at least content_only scope') and a material consequence (broken images on referencing displays). It does not explicitly name alternatives or exclusions, so it stops short of a 5.

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 destructiveHint annotation, the description discloses key behavioral consequences: deletion is permanent, cannot be undone, and any HTML fetching the readUrl will receive a 404. It also states the authentication requirement. These are concrete operational details that materially affect how an agent should invoke and reason about the 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?

Four short sentences, each adding distinct value: the core action, the downstream 404 effect, irreversibility, and the group/personal/auth usage rule. The most important fact is front-loaded, and there is no filler or repetition of the schema.

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 operation with a full input schema, output schema, and annotations, the description supplies all essential behavioral context: permanence, side effect on readUrl, auth requirement, and the group-vs-personal selection logic. An agent has enough information to invoke the tool correctly and understand the consequences.

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 schema already covers all four parameters with descriptions at 100% coverage, so the baseline is 3. The description repeats the group_id semantics but does not add meaningful parameter details beyond what the schema already states. No additional syntax, format, or relationship guidance is provided.

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 specific verb and resource: 'Permanently deletes a data slot.' It clearly differentiates from sibling tools like set_data_slot, get_data_slot, list_data_slots, and other delete_* tools by immediately identifying the target resource and the destructive nature of the operation.

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 provides clear usage context: group slots require group_id, personal slots omit it, and authentication is required. It does not explicitly name alternatives or exclusion conditions, but the group-vs-personal distinction and auth prerequisite give an agent enough situational 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 flag destructiveHint=true, but the description adds critical context: permanence ('cannot be undone'), cascading deletion ('all its associated content'), admin scope requirement, and the return shape. This goes beyond what annotations alone communicate, with no 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?

Three concise sentences front-load the most critical information: permanence, irreversibility, and the explicit confirmation requirement. Every sentence contributes value with no redundancy or 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 destructive mutation, the description covers the essential operational details: irreversibility, cascading content deletion, admin auth requirement, user confirmation gate, and return values. Combined with the rich input schema and output schema, nothing necessary 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 input schema has 100% coverage, with detailed descriptions for display_id, access_token, and session_request_id. The tool description adds no parameter-specific meaning, 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?

The description uses a specific verb and resource: 'Permanently deletes a display and all its associated content.' It clearly identifies the action and scope. It does not explicitly distinguish itself from siblings like clear_display or remove_display_from_org, so it falls 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 provides clear usage context: 'Use this only when the user explicitly confirms they want to remove the display,' plus the admin scope requirement. It does not enumerate alternatives or explicitly state when not to use it, but the confirmation gate is strong enough guidance for a destructive action.

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, but the description adds crucial details beyond that: side effects (releasing displays, removing members) and authentication/permission requirements (owner-only, admin scope). It also emphasizes irreversibility, providing context not captured in annotations. No contradiction exists.

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 two tight sentences with zero redundancy. The first sentence front-loads the core action and its immediate consequences; the second packs permissions and irreversibility into three short clauses. Every word earns its 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 destructive tool with an output schema and well-documented params, the description covers the essential information: what happens (permanent deletion), side effects, and access requirements. It omits nothing critical an agent would need to invoke it correctly, though it could theoretically mention the return value, which is presumably handled by the 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?

With 100% schema coverage, all three parameters (org_id, access_token, session_request_id) are already described in the input schema. The tool description adds no additional parameter-specific meaning, so a baseline score of 3 is appropriate given the schema already 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?

The description clearly states the verb 'deletes' with the resource 'organization' and specifies concrete effects: releasing all displays and removing all members. This distinguishes it from sibling tools like delete_display or delete_asset, which target different resources. The irreversible nature is also made explicit.

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 provides explicit prerequisites: only the owner can delete, and admin scope is required. While it doesn't name alternative tools or explicitly state when not to use it, the context is clear enough for an agent to infer that this is the correct choice for deleting an entire organization, not individual displays or assets.

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 mark this as read-only, idempotent, and non-destructive. The description adds behavioral context beyond that: public URIs require no auth while account and display URIs require a session, and it summarizes the return shape. No contradictions with 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?

Three sentences, with the core operation front-loaded, followed by usage direction, auth note, and return summary. Every sentence carries information without padding.

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 fetch tool with an output schema and read-only/idempotent annotations, the description covers when to use it, authentication requirements, and what is returned. Nothing essential is missing for an agent to invoke it 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%, so the baseline is 3; the description mostly restates the uri examples already in the schema. It adds only mild context that account/display URIs need a session, linking session_request_id to authenticated calls.

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 clearly identifies a specific verb ('Fetches'), a resource class ('agentView resource'), and the URI scheme with concrete examples. It does not explicitly distinguish this generic fetch from sibling get_* tools, so it misses full 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?

States when to use it ('Use after search or with a known URI') and gives auth preconditions by URI category. It does not name excluded alternatives or say when to prefer the sibling get_* tools, stopping short of a 5.

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 non-destructive behavior. The description adds a useful extra behavioral constraint: 'Requires content scope,' which is authentication/permission context not present in the annotations. No contradiction with 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?

Three sentences, each earning its place: what it returns, when to use it, and the explicit exclusion. The description is front-loaded with the resource and output content, and has no 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?

With annotations covering the safety profile, an output schema covering return structure, and the description covering scope, usage context, and sibling differentiation, nothing an agent needs to invoke 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 description coverage is 100% for both parameters, so the schema already fully documents them. The description adds no parameter-specific meaning beyond noting an auth scope requirement, which is not tied to a specific 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?

The description names a specific verb ('Returns'), a clear resource ('the user's account profile'), and enumerates the data returned (plan, quota, memberships, points). It also explicitly distinguishes itself from list_displays, so an agent can disambiguate among siblings.

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 exactly when to use it ('for subscription, quota and membership questions') and when not to ('Not for listing displays'), naming the alternative tool. This is explicit, actionable routing 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 indicate read-only, idempotent, non-destructive behavior. The description adds valuable context: template mode needs no authentication, display mode requires specific auth scopes, and placeholder resolution behavior. No contradictions.

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 concise (three well-structured sentences), front-loaded with the core purpose, and every sentence adds value. No redundancy or 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?

Given the complexity (5 params, output schema exists), the description covers all critical aspects: what the tool returns, the two modes, authentication requirements, and how to discover valid keys. Complete enough for correct agent invocation.

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%, baseline 3. The description adds meaning by explaining the precedence of display_id over slug, the auth context for access_token vs session_request_id, and the purpose of each parameter beyond schema descriptions.

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 clearly states the tool returns an agent-onboarding artifact (system prompt, SKILL.md, or MCP-config snippet). It distinguishes between two modes: raw template (slug) and placeholder-resolved (display_id), and explains how to discover artifact keys via get_store_template_details.

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 provides explicit guidance on when to use slug (template mode, no auth) versus display_id (display mode, requires auth and ownership). It also mentions the sibling get_store_template_details for key discovery. However, it does not explicitly exclude use cases.

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. The description adds an actionable auth requirement ('at least content_only scope') and mentions the URL in the response. No contradiction with 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?

Three short sentences, each earning its place: what the tool returns, when to use it, and what authentication is needed. No fluff or repetition.

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 read-only lookup tool, the description covers purpose, usage, auth, and return content. An output schema exists, so return-value details are already available to the agent.

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 asset_id, access_token, and session_request_id all documented in the schema. The description itself does not add param-level detail, so a 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: 'Returns metadata for a single asset including its URL.' This clearly differentiates it from sibling tools like list_assets, update_asset, delete_asset, and upload_asset.

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 use case: 'Use this to verify an asset still exists before referencing it in HTML.' It does not explicitly name alternatives or exclusion conditions, but the context is clear for a single-asset lookup.

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 signaling readOnlyHint=false and idempotentHint=true, the description adds substantial behavioral context: the raw token is intentionally not returned over MCP, completing login does NOT authenticate the MCP session, status 'active' reports the GRANTED scope read back from the token, and the fallback credential behavior with scope differences between content and admin tools. No contradiction with annotations — it enriches them.

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 dense (~120 words) but every sentence carries distinct, high-value information: purpose, polling cadence, status semantics, auth caveat, fallback behavior, security disclosure, and lifecycle handling. There is no filler, redundancy, or restatement of the schema. The length is fully justified by the tool's behavioral complexity.

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?

The tool has an output schema, so return values need no description-level coverage. The description covers all the remaining contextual needs: the orchestration relationship with create_auth_session, polling cadence, all three status outcomes (pending/active/expired) with appropriate actions, security constraints, and the critical downstream requirement to pass session_request_id on protected calls. Nothing an agent needs to invoke this 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% and the schema description already says 'Must be passed exactly as received.' The tool description adds value beyond that by explaining where the ID comes from (create_auth_session), how it must be reused on every protected call, and what happens if omitted. This is genuine complementary information, not schema repetition.

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 specific verb and resource: "Polls a login session created by create_auth_session until the user completes the browser login." This clearly distinguishes the tool from its siblings (create_auth_session creates, this polls; authenticate is a different auth path) and states the terminal condition precisely.

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 operational guidance is given: poll every 2-3 seconds while status is 'pending', start over with create_auth_session on 'expired', and pass session_request_id on every protected call afterwards. It also explains the consequence of omitting the parameter (fallback to the connector's bearer token) and which tool category that breaks (admin tools like pair_by_code). This is exemplary when-to-use-and-how 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 declare readOnlyHint and idempotentHint, so no contradiction. The description adds useful behavioral context beyond annotations: authentication is required, and the response exposes a readUrl that is a public anonymous URL for fetching display HTML. This helps the agent understand auth expectations and how to use 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?

Three sentences with no filler. The primary behavior is front-loaded, followed by the group/personal distinction, the readUrl note, and the auth requirement. Every sentence earns its 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 simple read-only retrieval tool, the description covers target selection, authentication, and a notable response field. The output schema covers return structure, and the annotations cover safety/idempotency, so nothing an agent needs to call this 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 four parameters adequately. The description's group_id guidance mostly repeats the schema description, and it does not add material meaning about slug, access_token, or session_request_id beyond what is already 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?

The description states a specific verb and resource: 'Returns the current JSON content and metadata of a data slot by slug.' It also distinguishes personal vs group slots, which clarifies how this getter differs from list_data_slots, set_data_slot, and delete_data_slot.

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 clear usage context: supply group_id for group slots, omit for personal slots. It also notes authentication is required. It does not explicitly name alternative tools or exclusions, but 'by slug' sufficiently implies this is for retrieving a known slot rather than enumerating slots.

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. Description adds that it returns state and content summary, and details browser/runtime facts for 'detailed'. Also mentions 'Requires content scope' – a permission hint – which adds value beyond 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?

Two sentences plus a note on detailed usage and list_displays. Front-loaded with purpose. Could be slightly more concise, but overall 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?

Output schema exists, so no need to describe return values. Description covers two response formats and their use cases, scope requirement. Complete for a read-only tool with good schema 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 coverage is 100%, so baseline 3. Description adds minor guidance (use list_displays for IDs) but does not explain parameter behavior beyond schema. Adequate but not extra helpful.

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?

Description states specific verb 'returns' and resource 'one display's state', listing key fields (status, lock, URLs, settings, language, content summary). Distinguishes from sibling list_displays by telling agent to use list_displays first.

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 list_displays first to discover IDs and suggests using 'detailed' before generating complex HTML. Lacks explicit 'when not to use' or alternatives beyond list_displays.

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 signal read-only and non-destructive behavior; the description adds meaningful context beyond that: short-lived signed link, inline preview rendering, lifetime coupling to privacy mode, and the content-scope requirement. No contradiction with readOnlyHint is present because creating a signed link does not imply mutating persistent state.

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?

Packs the key decision trigger, behavior, and a security requirement into four short sentences. The most actionable guidance ('ALWAYS call this when...') is front-loaded, with no redundant 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 tool with one required parameter, full schema documentation, read-only annotations, and an output schema, the description supplies everything the agent needs to select and invoke it correctly: what it returns, when to use it, lifetime behavior, and required scope.

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 every parameter thoroughly. The description adds contextual value like privacy-mode-based linking and content scope, but does not need to restate per-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?

Uses a specific verb and resource: 'Creates a short-lived signed link' showing current display content. The 'RIGHT NOW' and 'rendered inline as a preview widget' wording clearly differentiates it from broader display or read 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?

Provides explicit trigger guidance: 'ALWAYS call this when the user wants to SEE their display or screen content (preview, zeig mir das Display).' It does not name specific alternative tools or state when not to use it, but the usage context 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations: it returns data for the authenticated user and requires the content_only scope, which is an auth prerequisite an agent needs to know.

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 compact sentences with zero filler. The core return value and included fields are front-loaded, followed by the use case and the scope requirement. Every sentence earns its 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 read-only info tool with an output schema, complete parameter documentation, and annotations covering safety, the description is sufficient. It explains what the user gets, why they would use it, and what access is required.

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 already explained in the input schema. The description does not add parameter-specific meaning, but it also does not need to because the schema carries the full 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?

Description states specific verb 'Returns' and resource 'complete license allocation overview' with an explicit list of what is included. It clearly reads as a read-only counterpart to allocation actions, distinguishing it from siblings like manage_licenses.

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 'Use this to understand available capacity before allocating licenses,' which tells the agent when to invoke it. It does not describe exclusions or mention alternative sibling tools, but the guidance is clear enough for correct 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?

Beyond annotations (readOnlyHint, idempotentHint), the description adds behavioral detail on what fields are returned and how response_format alters the output. It does not contradict annotations and provides new context about membership 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?

The description is two sentences with no wasted words. The first sentence front-loads the main purpose and key fields; the second adds format options and usage prerequisites. Every sentence earns its 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?

Given the four parameters and presence of an output schema, the description covers the essential points: returned data, format options, prerequisite, and requirement. It does not detail return structure (handled by output schema) but is sufficient for agent invocation. Minor gap: no mention of rate limits or scope specifics.

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?

With 100% schema coverage, baseline is 3. The description adds meaning to response_format by explaining the difference between 'concise' and 'detailed', and notes that org_id comes from list_organizations or get_account, supplementing the schema's basic descriptions.

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 clearly states the tool returns organization details including specific fields (plan, role, display count, allocated/remaining license slots) and distinguishes between 'concise' and 'detailed' response formats. It differentiates from siblings like list_organizations by focusing on a single organization and listing specific data.

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 explicitly advises 'Use after list_organizations' and 'Requires content scope and membership,' giving clear context for when to invoke. It does not exclude other scenarios or mention alternatives, but the guidance is sufficient for most use cases.

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, covering the safety profile. The description adds useful behavioral context by specifying it is a public, unauthenticated endpoint and listing the returned fields, which goes beyond the annotations without contradicting them.

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 two sentences with no filler. It front-loads the primary result, then provides usage guidance and authentication context, making every sentence valuable.

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 tool has no parameters, an output schema, and clear annotations, the description fully covers when to use it, what it returns, and the authentication requirement. 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 has zero parameters, so the schema fully covers the input surface. The description correctly adds no parameter information, and the baseline for a no-parameter tool 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 clearly states the tool returns the server's public readiness status, version string, and discovery URLs. It uses a specific verb and resource, and it distinguishes itself from authenticated siblings by emphasizing it is called before authenticating and requires no authentication.

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 explicitly says to use this tool before authenticating to verify server reachability and obtain entry-point URLs. It also notes no authentication is required, giving clear context, though it does not explicitly name exclusion cases or alternatives among 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?

Disclosures beyond annotations: quota sharing between data slots and assets, return fields, optional slug behavior for display references, and suppressed=true for narrow API keys. All consistent with readOnlyHint and idempotentHint 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?

Three sentences, front-loaded with main purpose, no redundancy. Each sentence provides distinct, valuable information without wasted words.

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 4 parameters, no required params, and an output schema (implied), the description covers returns, use cases, side conditions, and prerequisites (content scope). Complete for an agent to select and invoke 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%, so baseline 3. Description adds meaning: slug also returns which displays reference it (slotUsage) and advises using it before deletions; group_id indicates group vs. personal pool. Adds value beyond schema for key parameters.

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 clearly states the tool returns a storage pool snapshot (used, limit, remaining bytes) for personal or group scope, and distinguishes from siblings by specifying its role before large writes or deletions. The verb 'Returns' and resource 'storage pool snapshot' are specific.

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 advises when to use: 'check before large set_data_slot or upload_asset writes' and 'do this before delete_data_slot to know which displays would break'. It also notes conditions like suppressed results for narrow API keys and required content scope.

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. Description adds details on HTML windowing (max_bytes, offset, totalBytes, truncated) and placeholder resolution, going beyond 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?

Three sentences, front-loaded with purpose, then behavior, then windowing and alternative. No wasted words.

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 all needed context: template slug source, placeholders, windowing, alternative tool. Output schema exists so return values not needed.

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%. Description adds context: placeholders resolve to public URLs, slots stay intact, windowing relates to totalBytes/truncated.

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?

Description clearly states it returns raw display HTML, slot definitions, and allowed origins. It specifies the resource and distinguishes from send_store_template_to_display.

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 when to use (editing/embedding) and when not (pushing to display via alternative). Provides context on placeholders and windowing.

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 readOnlyHint, idempotentHint, destructiveHint, so the bar is lower. The description adds 'No authentication required', which is valuable behavioral context not in 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?

Two efficient sentences: first succinctly lists return fields, second provides usage sequence. No extraneous information, front-loaded with key details.

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 tool's low complexity and presence of output schema, the description adequately covers purpose, usage context, behavioral traits, and parameter guidance without gaps.

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 parameters have detailed descriptions), so baseline is 3. The description reinforces the slug's origin and language default, adding minimal extra value. However, it doesn't introduce new parameter constraints, so 4 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 description explicitly states 'Returns full details of one store template' and lists specific fields (localized title, description, markdown, etc.), making the verb and resource clear. It also distinguishes from siblings by referencing search_store_templates and get_agent_artifact.

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?

Provides explicit guidance: 'Use after search_store_templates before recommending or installing; when agentArtifacts is non-empty, fetch bodies via get_agent_artifact.' This clearly states when to use and suggests a follow-up action.

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 indicate readOnlyHint, idempotentHint, destructiveHint. Description adds 'Requires content scope' authorization context. No contradictions; adds value beyond 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?

Three sentences, all essential: purpose, prerequisite, edge case. No redundant words, front-loaded with key action.

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?

Has output schema for return values, annotations for safety, parameters fully documented, and description covers usage order and edge case. Complete for this tool's 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 coverage is 100%, baseline 3. Description enhances slug with 'returned by search_store_templates', language as 'preferred UI language', and clarifies access_token vs session_request_id usage.

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 clearly states it returns displays and data slots for a store template, with specific fields like key, label, type, required. It distinguishes from sibling tools like send_store_template_to_display and search_store_templates.

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 'Call before send_store_template_to_display', providing clear sequential usage. Also notes the empty displays list implies setup with pair_by_code, but does not exhaustively list when not to use.

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 mark the tool read-only, idempotent, and non-destructive. The description adds meaningful behavior beyond those hints: it returns only metadata (prefix, name, scope, dates), never the raw key, and requires admin scope. This is useful context for an agent deciding whether the call satisfies a request.

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 three short sentences with no filler. It front-loads the core action, then supplies the key behavioral caveat and the admin-scope requirement. Every sentence earns its 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?

Given that an output schema exists (so return value details are handled elsewhere) and annotations cover safety, the description provides the remaining necessary context: current-user scope, admin requirement, and the fact that raw keys are never exposed. Nothing essential is missing for an agent to invoke this tool 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%, so both parameters (access_token and session_request_id) are already well-documented in the input schema. The description does not add parameter-specific semantics, but with full schema coverage the baseline score 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: 'Lists all API keys for the current user.' It also clarifies that raw keys are never returned, which distinguishes it from key-creation or key-revocation siblings. The scope (current user) and metadata-only behavior make the tool's purpose unambiguous.

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 implies usage when you need to enumerate API keys, but it does not explicitly name alternatives like create_api_key or revoke_api_key, nor does it state when not to use this tool. The admin-scope requirement and current-user context provide some guidance, but 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false; description aligns and adds behavior about response_format 'detailed' providing extra fields. No contradictions.

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 sentences, front-loaded with main purpose. No extraneous words. Each sentence adds distinct value: purpose then usage and features.

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 an output schema present, the description appropriately focuses on list behavior, filtering, and response format options. It mentions public URLs for display HTML, covering typical use cases. No missing essential context.

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 has 100% description coverage. Description adds meaning by explaining response_format behavior and that filtering can be by type, search, group. This adds value over the bare schema descriptions.

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 clearly states the tool lists user's uploaded assets, specifies types (images, videos, fonts, documents) and mentions public URLs for display HTML. It distinguishes from sibling tools like upload_asset, delete_asset, update_asset.

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 advises to check before upload_asset to avoid duplicates. Mentions filter options. Does not explicitly state when not to use, but the advice on duplicate checking provides clear usage context.

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, establishing the safety profile. The description adds meaningful behavioral details beyond annotations: it returns metadata only (no jsonContent), each item includes readUrl, and authentication is required. It also explains the intended downstream use of readUrl, giving the agent important context for interpreting results.

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 three sentences with zero redundancy: purpose + filtering, return shape, and a directive on using readUrl. The most important scoping constraint (metadata only, no jsonContent) is front-loaded, and every sentence earns its place without repeating schema or annotation 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?

With an output schema present, the description does not need to explain return values in depth. It covers the core purpose, filtering capability, a key behavioral caveat (no jsonContent), the readUrl field, and authentication. Since all parameters are optional and fully described in the schema, the description provides enough context for correct invocation.

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 six parameters. The description mentions 'optional filtering' generically but does not add detail about specific parameters like limit, offset, search, or group_id. Per calibration, a baseline of 3 is appropriate when the schema fully covers 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?

The description states a specific verb ('Lists') and resource ('data slots') with optional filtering, which clearly defines the operation. It distinguishes itself from sibling tools like get_data_slot (single retrieval) and set_data_slot (write) by explicitly focusing on listing and noting it returns metadata only, not jsonContent. The resource and scope are unmistakable.

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 gives clear context on when to use this tool — for listing data slots with filtering — and provides a practical instruction on using the returned readUrl in display HTML fetch() calls. It does not explicitly name alternatives or exclusion conditions (e.g., use get_data_slot for a single slot), but the context is sufficient for an agent to select it appropriately.

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. The description adds authentication requirements (scope and capability) which is useful context beyond annotations. No contradiction, but behavioral traits are well-covered by annotations, so description adds moderate value.

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 two sentences: first states the action and output, second provides usage guidance. No redundant words, front-loaded with purpose, and structured for quick 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?

Given the tool's simplicity (list operation, two optional params, output schema present), the description covers purpose, usage context, and auth requirements completely. The presence of output schema obviates need for return value details.

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 schema already documents both parameters. The description adds a preference hint ('prefer session_request_id') but does not substantially augment parameter meaning. Baseline score 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?

The description uses specific verb 'lists' and resource 'personal display categories' with details (stable IDs, paths, assignment counts). It clearly distinguishes from sibling tools like assign_display_categories and manage_display_category by noting it is for discovery before assignment/replacement.

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 explicitly states when to use the tool: 'before assigning or replacing categories on a display.' It also lists required authentication scope and capability. While it doesn't mention alternative tools or when not to use it, the usage context is clear and actionable.

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 indicate read-only, non-destructive, idempotent. Description adds context on scope (user's displays), output fields, and requirement (content scope), enhancing transparency beyond 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?

Two clear sentences; front-loaded with purpose, then logically flows to options and alternatives. No redundant 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?

Covers output fields, prerequisites, and related tools. For a listing tool with output schema and good annotations, this is complete and sufficient.

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 covers all parameters with descriptions. Description adds no new parameter details beyond reaffirming org_id use and response_format behavior, so baseline score 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?

Clearly states the tool lists all accessible displays with specific fields, and positions it as the starting point for display-specific tools, distinguishing it from siblings.

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?

Provides when to use (before get_display etc.), how to use org_id and response_format, and points to an alternative (get_display_preview_url). Lacks explicit when-not-to-use, but sufficient for a listing 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 convey read-only, idempotent, non-destructive behavior. The description adds meaningful context beyond annotations by specifying the required authentication scope ('content_only') and the exact shape of the result set. This helps the agent understand prerequisites and output contents without over-explaining.

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 two sentences with no filler: the primary behavior is front-loaded, followed by concrete use cases and the authentication requirement. Every sentence earns its 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 read-only listing tool with a rich output schema and complete parameter descriptions, the description provides the essential missing context: what the tool returns, when to use it, and what auth is required. Nothing critical 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%, so both parameters are already well documented in the input schema. The description does not add extra parameter-level detail, but it doesn't need to; the baseline of 3 applies because the schema carries the semantic weight.

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 ('Returns all organizations the authenticated user belongs to') and enumerates the returned fields (role, display count, member count, allocated slots). This clearly distinguishes it from singular-fetch tools like get_organization and from other list tools focused on different resources.

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 explicitly names concrete use cases: answering questions about the user's organizations, display counts, and team membership. It does not provide explicit when-not-to-use guidance or name alternative tools, but the intended context is clear enough for an agent to route correctly.

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 and idempotentHint=true. The description adds that no authentication is needed, returns count/language/categories array with specific fields, and implies use for published categories. No contradictions found.

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?

Three sentences, each serving a distinct purpose: announcement, usage guidance, return structure. No fluff or repetition. Front-loaded with the core 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?

Given only one simple parameter and an output schema that exists (with described fields), the description is complete. It covers purpose, usage, auth, and return structure effectively.

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 one parameter 'language' fully described via enum and default. The description does not add additional meaning beyond the schema, which is acceptable; 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 description states 'Lists all published agentView store categories' with concrete examples (e.g. Gastronomie, Wartezimmer) and details what each entry contains. It clearly distinguishes from siblings like search_store_templates, which is referenced as a follow-up use.

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 to use this tool to narrow a subsequent search_store_templates call for user queries like 'templates for a waiting room'. Mentions no authentication required. Could be improved by also stating when not to use it, but the guidance 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?

The description goes into useful detail beyond the annotations: it clarifies there is no identity cache, no token revocation, no state reset, and that a failing auth state won't be affected. This prevents the agent from assuming real logout behavior. No contradiction with idempotentHint or destructiveHint.

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?

Three tight sentences, with the core 'acknowledgement only' statement front-loaded. Each sentence earns its place by adding essential context about limitations and the correct alternative.

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 zero parameters, a present output schema, and supporting annotations, the description fully covers what the tool is, what it lacks in effect, and how to achieve a true logout. Nothing essential 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?

With zero parameters and 100% schema coverage, there is nothing to document. The description properly emphasizes that the operation is an acknowledgement, which is all that is relevant. Baseline 4 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 clearly states that this is an acknowledgement-only operation with no identity cache to clear. It explicitly differentiates itself from a real logout by listing what it does NOT do, so an agent can precisely understand the tool's role despite the generic 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?

The description gives explicit when-not-to-use guidance: it does not end a login, revoke a token, or invalidate a session_request_id. It also provides the correct alternative — 'stop sending the credential' — making the usage context unmistakable.

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 communicate mutation and destructive potential, so the description adds useful context by stating that assignments and grants stay intact on rename. This explains a behavioral consequence beyond what the schema or annotations alone convey, though it doesn't elaborate on all potential side effects.

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 sentences carry substantial, well-organized information: action options, parameter requirements, behavioral note, and pointers to sibling tools. There is no filler and the key distinctions are 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?

Given the 100% schema coverage, output schema availability, and annotations, the description is complete enough for an agent to call the tool correctly. It covers the action-dependent requirements and points to the sibling tools for ID discovery and assignment, leaving no significant functional 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 description coverage is 100%, so each parameter is already documented individually. The description adds action-conditional meaning, specifying which parameters apply to create versus rename and that parent_category_id is create-only, which helps the agent assemble the correct call.

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 uses a specific verb phrase, 'Creates or renames a display category,' and defines the domain concept by noting categories group displays for broadcast_content include_category_ids. This clearly differentiates it from sibling tools like list_display_categories and assign_display_categories.

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 explicitly maps each action to its required parameters ('create' needs name; 'rename' needs category_id and new_name), and directs the agent to sibling tools for related tasks: list_display_categories for discovering IDs and assign_display_categories for assigning displays. This is strong when-to-use 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 mark this destructive, but the description adds meaningful behavior: 0 deallocates all slots, unassign returns a license to the pool, and admin scope is required. No contradiction exists between description and 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?

Three sentences with no filler; the action list is front-loaded and the prerequisite/scope warning is compact. The first sentence is long, but its colon-separated structure keeps it readable.

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-action, destructive license tool, it covers all action semantics, the prerequisite lookup, and permission requirement. It does not discuss edge cases or failure states, but the output schema and full parameter schema cover the remaining invocation details.

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 bar for adding value is higher. The description does clarify 'free license' and the allocation/deallocation behavior, but most parameter mappings are already present in the schema, and token/session parameters are left to 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?

The description names a specific resource ('premium display licenses') and enumerates each action with its exact effect: allocate sets slot counts, assign binds a free license, unassign releases it. This goes beyond mere title repetition and clearly differentiates the tool from read-only license info via get_license_info.

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 concrete usage context: check availability first with get_license_info and requires admin scope. It does not explicitly spell out when not to use each action, but the action semantics plus prerequisite make the intended flow 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 destructiveHint=true and readOnlyHint=false, so the description's mutation nature is consistent. It adds the admin scope requirement and clarifies role semantics, which is useful beyond annotations. However, it does not disclose potential side effects (e.g., notification emails, irreversible removal) or what happens on invalid input. Given annotation coverage, this is a moderate contribution.

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 sentences cover the core actions, roles, and admin requirement without redundancy. The front-loaded action list immediately orients the agent, and no filler exists.

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 a 100% schema coverage and an output schema present, the description covers the necessary invocation logic: actions, roles, and authentication scope. It doesn't explain error handling or edge cases, but for a mutation tool with clear schema documentation, this is adequate. Slightly more on expected outcomes would push it to 5, but it's already strong.

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 all parameters are documented. The description adds value by linking parameters to actions (email for invite, target_user_id for set_role/remove) and defining role values, which the schema lists but does not explain in context. This goes beyond simple repetition of 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?

The description clearly identifies the tool as managing org membership with three specific actions (invite, set_role, remove) and defines the role options. This distinguishes it from other org-related tools like configure_organization or list_organizations, making its purpose unambiguous.

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 explains when each action is appropriate (invite adds a member, set_role changes, remove removes) and lists the valid roles for organizations and families. It also notes the admin scope requirement, giving the agent context for invocation. It could be more explicit about when not to use this tool in favor of siblings, but the action-oriented guidance is strong.

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?

It discloses that the call both creates and pairs in one step and that rebinding keeps name, settings, and content. It further reveals the admin requirement and the auth-scope failure mode, adding valuable context beyond 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 description is dense but front-loaded, opening with the core pair action before moving to rebinding and the auth edge case. Each sentence adds distinct procedural or prerequisite value; no 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?

It covers the happy path, the rebind variant, admin requirements, an authentication recovery flow, and when to poll get_auth_session. Since output schema exists, return values are already covered; nothing needed to call the tool 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?

Despite 100% schema coverage, the description adds decision rules: profile_name is required for new pairing but ignored on rebind; target_display_id is the switch for rebinding; session_request_id comes from create_auth_session. This materially enriches parameter understanding.

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 specific action — pairing a physical screen with a 6-character code — and immediately distinguishes first-time pairing from rebinding an existing display profile via target_display_id. This makes it distinct from broader siblings like create_display or claim_display.

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 explicitly presents itself as the recommended first-time setup with step-by-step user instructions, and gives the alternative rebind path with target_display_id. It also details when to use create_auth_session/get_auth_session first and explicitly says re-authorization is not needed, providing strong decision 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?

Beyond annotations (readOnly, idempotent, not destructive), the description adds key behaviors: windowed reading with max_bytes and offset, reporting totalBytes and truncated. No 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?

Four sentences front-load purpose, then add paging details, then exclusion. No wasted words; every sentence adds 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?

Given 6 parameters, 1 required, and an output schema (not shown but acknowledged), the description covers purpose, windowing, alternatives, and prerequisite (content scope). Complete for agent invocation.

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%, baseline 3. Description adds context on paging behavior (max_bytes default, offset) and content_type explanation beyond enum values, but mostly reinforces 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?

The description clearly states it reads raw HTML source shown on a display, distinguishes from get_display_preview_url for visual previews, and explains the content_type parameter for idle vs live content. The verb 'reads' and resource 'HTML source' are specific.

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