agentView

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

The description adds behavioral context beyond annotations: it explains the concept of a license pool, that licenses can be deallocated (set to 0), and requires admin scope. Annotations indicate destructiveHint=true, which aligns. 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?

Three sentences, front-loaded with the main action, each sentence adds value without redundancy. No 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?

The description covers the tool's purpose, prerequisites, and the concept of license pool. No output schema exists, so return values are not expected. It is sufficiently complete for a mutation tool with good annotations.

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?

Input schema has 100% coverage with descriptions for all parameters. The description does not add extra meaning beyond the schema; it repeats the concept of deallocation already in the licenses parameter description. 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 clearly states the action (allocate licenses from Premium plan to organization) and resource (premium display licenses). However, it does not explicitly differentiate from the sibling tool 'assign_license', which may cause confusion.

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 context on when to use (requires admin scope and Premium plan) but lacks guidance on when not to use or alternatives like 'assign_license'. The prerequisites are 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 discloses behavioral traits beyond annotations: it removes watermark, makes ad-free, adds 30 MB storage, requires admin scope, and lists return fields. There is 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?

The description is three sentences, each serving a purpose: main action, differentiation, and additional details. It is front-loaded with the core function and is concise without 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 tool has 2 parameters and no output schema, the description adequately covers what the tool does, side effects, prerequisites, and return fields. However, it could mention the response structure more explicitly, though the listed fields are sufficient for an agent to 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 is 3. The description adds value by explaining that the license assignment process differs for personal vs organization displays and that access_token is optional, though it does not elaborate on the access_token parameter itself.

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 'assigns' and the resource 'premium license' to a display, distinguishing it from siblings like unassign_license and allocate_licenses. It specifies the effects (removes watermark, ad-free) and differentiates between personal and organization displays.

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 context on when to use (assign license) and mentions the prerequisite allocate_licenses for organization displays. It implicitly guides against using for personal displays if no free pool, but does not explicitly state when not to use or list alternatives beyond the sibling allocate_licenses.

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?

Describes side effect of caching identity on the MCP session, returns list of fields including 'sessionBound', and is consistent with annotations (readOnlyHint=true, destructiveHint=false). Adds 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?

Three sentences, no wasted words, front-loaded with purpose, then usage guidelines, then return fields. 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?

Complete for a simple tool: covers purpose, usage context, behavioral side effects, parameter hint, and return fields. No missing information given schema, annotations, and context signals.

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?

Adds critical guidance beyond schema: 'do not add Bearer prefix, do not expand or decode the JWT claims'. Schema coverage is 100% but description still provides essential usage details.

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 validates a JWT token and caches the identity, using specific verb 'validates' and resource 'JWT agent token'. Distinguishes from siblings like get_auth_session and logout by mentioning auto-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 states when to use (if client cannot reliably send Authorization header) and when not to use (if already auto-authenticated by get_auth_session, or if modern streamable HTTP client can send header).

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 behavioral context beyond annotations: it mentions that locked displays are skipped, the tool returns sent and skipped lists with reasons, and requires content_only scope. This complements the destructiveHint=true annotation.

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 (3 sentences) and front-loaded with the main purpose. Each sentence adds useful information, though it could be more structured with bullet points for readability.

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

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

The description covers targeting options, skipped displays, return structure, and required scope. While there are 9 parameters, the explanation sufficiently guides the agent on core usage. Missing explicit handling of conflicting parameters (both display_ids and all).

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, parameters are already well-documented. The description adds limited value by clarifying mutual exclusivity between display_ids and all, but does not detail individual parameter semantics beyond what the schema provides.

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 'Sends HTML content to multiple displays at once', using a specific verb and resource. It distinguishes from siblings like send_html (single display) and broadcast_to_categories (category-based) by focusing on targeting by display_ids or all displays.

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 to use the tool: to target specific displays via display_ids or all accessible displays via the 'all' flag. It also notes that locked displays are skipped and requires content_only scope, providing clear context for usage.

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?

Discloses preview behavior via dry_run and subcategory inclusion, adding value beyond annotations. However, it does not mention potential side effects like overwriting existing content on displays.

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 concise sentences that front-load the main purpose and immediately clarify key optional parameters. 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?

Well-suited for a broadcast tool with no output schema; mentions dry_run returns matched profiles. Lacks details on limits or error handling, but adequate given the tool's simplicity.

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; the description adds meaningful context for html, dry_run, and include_descendants, linking them to the tool's primary action.

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 'Sends HTML content to every display assigned to one of the selected category IDs', providing a specific verb and resource. Distinguishes from sibling broadcast tools (e.g., broadcast_content) by focusing on category-based targeting.

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

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

Explains key options like include_descendants and dry_run, but does not explicitly contrast with sibling tools for when to use this vs. others. Context is clear but lacks exclusionary 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 destructiveHint=true and readOnlyHint=false, which the description aligns with. It adds the context of bulk operation across multiple displays, but lacks details on partial failures, error handling, or returned results beyond what annotations provide.

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 a single sentence of 14 words, efficiently conveying the core action without redundancy. It is front-loaded with the key verb and resource.

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 is destructive with no output schema, yet the description omits return value details, error handling, partial failure behavior, and authentication requirements. Given the complexity (5 params, no output schema), this is incomplete.

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 covers all 5 parameters with full descriptions (100% coverage). The description adds no additional meaning beyond the schema's parameter docs, so 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 clearly states it 'bulk adds or removes one category across multiple displays', specifying the verb and resource. However, it does not explicitly differentiate from sibling tools like set_display_categories_for_display, though 'bulk' implies multiple displays.

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 mentions 'the caller can manage', implying permission requirements, but provides no explicit guidance on when to use this tool vs alternatives (e.g., set_display_categories_for_display). No exclusion conditions or prerequisites are given.

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?

Description discloses permanent ownership transfer and quota impact, adding behavioral context beyond annotations. Annotations have destructiveHint=false, which is consistent since the tool transfers ownership rather than destroying data.

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, each serving a purpose: main action, consequences, usage guidance, and return info. No redundant phrases, front-loaded with key 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?

Covers all essential aspects: what it does, when to use (vs alternative), prerequisites (admin scope), parameter details, and what it returns. No output schema, but description adequately explains 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 coverage is 100%, but description adds context like 'short ID of the pending, guest or demo display' and 'friendly name'. Also specifies return value (profileId and name), which is not in input 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?

Description clearly states the tool converts unclaimed/guest/pending displays into managed personal displays, with specific verb and resource. Distinguishes from sibling pair_by_code by noting it's for adopting existing displays, not first-time setup.

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

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

Explicitly states when to use ('when user explicitly wants to adopt an existing display') and when not to use ('for first-time physical setup, prefer pair_by_code'). Also mentions required 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 indicate destructive hint and idempotency. The description adds value by explaining immediate viewer impact, auth scope requirement, and return format. 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 efficient sentences with no waste. First sentence states primary action, subsequent sentences add necessary context. Perfectly 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?

Despite no output schema, description specifies return fields. Covers auth, scope, behavior, and sideline sibling differentiation. Complete for a simple clear operation.

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

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

Schema covers 100% of parameters with descriptions. The description adds practical context for access_token (e.g., where to pass token), enhancing agent understanding beyond raw 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 the tool removes live content and returns display to idle state, using specific verb-resource pairing. It explicitly distinguishes from delete_display, ensuring unambiguous purpose.

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

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

Explicitly states when to use (blank/reset) and when not (use delete_display for deletion). Also mentions required authentication scope, providing clear usage direction.

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 destructive and idempotent traits. The description adds that changes are pushed immediately if the display is online and that admin scope is required. This goes beyond annotations without 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?

The description is three sentences, each serving a purpose: first defines action, second gives examples, third notes optionality and behavior. Front-loaded and efficient with 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?

Given 12 parameters and no output schema, the description covers usage, scope, and behavioral nuance (immediate push if online). It does not specify behavior when offline, which is a minor gap, but overall 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 coverage is 100%, so parameter descriptions are already complete. The description only summarizes categories but adds no new detail beyond what the schema provides, earning a baseline of 3.

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

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

The description clearly states the tool updates hardware permissions, UI settings, and connectivity overrides for a display, listing specific capabilities (camera, microphone, geolocation, cursor, badge, watermark, connectivity). This distinguishes it from sibling tools like lock_display or clear_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?

The description provides explicit when-to-use guidance by enumerating use cases (enable/disable access, toggle overlays, set connectivity). It also notes optionality and the admin scope requirement. No explicit when-not-to-use, but the context is clear enough.

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 important behavioral details beyond annotations: the key is returned only once (store securely), requires explicit user consent, and has granular scoping. Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description correctly confirms a mutation operation. It could be further enhanced by mentioning potential side effects or rate limits, but the provided info is valuable.

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 (5 sentences) and well-structured: it begins with the core purpose, follows with security warnings and prerequisites (admin scope, consent), then outlines scoping capabilities, and ends with the return value. Every sentence adds essential information 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?

The description covers the tool's purpose, security implications, requirements, scoping options, and return values. With no output schema, listing the returned fields is particularly valuable. However, it omits an explanation of how the 'permissions' parameter interacts with 'scope' and 'capabilities' (though the schema describes these). The description is largely complete for a complex tool with 9 parameters.

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 each parameter described. The description adds a high-level summary of the granular scoping options (slugs, display IDs, permissions, capabilities) and lists the return fields, which is helpful since there is no output schema. This synthesis aids understanding beyond the individual parameter 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 explicitly states it creates a long-lived API key for server-to-server integration without OAuth. This clearly differentiates it from sibling tools like list_api_keys (listing) and revoke_api_key (revocation). The verb 'creates' is specific and the resource 'API key' is 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 mentions the tool is for server-to-server integration without OAuth and requires admin scope, providing context for when to use it. However, it does not explicitly contrast with alternatives like OAuth-based authentication or short-lived tokens, nor does it mention when not to use it or point to sibling tools for related operations (e.g., list_api_keys to view existing 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?

Annotations indicate idempotentHint=true and destructiveHint=false, which the description complements by explaining that the tool returns a sessionRequestId, loginUrl, pollUrl, and expiresIn, and that the login window closes after 600 seconds. There is no contradiction with annotations, and the description adds significant behavioral context beyond structured fields.

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

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

Two sentences, front-loaded with key purpose and action. Every sentence adds value: first sentence defines what the tool does and returns, second provides usage guidance and next steps. 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?

Given there is no output schema, the description completely covers expected return fields (sessionRequestId, loginUrl, pollUrl, expiresIn) and workflow steps. It also mentions the default timeout and the need to poll get_auth_session, making it self-sufficient for the 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?

Input schema has 2 parameters with 100% description coverage, so baseline is 3. The description does not add additional meaning beyond what the schema already provides; it only mentions scope defaults and agent_identifier purpose, which are 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 clearly states it creates a browser-based login session and returns a loginUrl for authentication. It uses specific verbs ('creates', 'returns') and identifies the resource ('auth session'). Given the sibling tool 'authenticate' and 'get_auth_session', this description distinguishes the tool as the first step in an OAuth flow.

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 ('when your client cannot complete OAuth 2.1 with PKCE itself') and when not to use ('Do not use this if you already have a valid Bearer token'). It also provides actionable next steps: instruct user to open loginUrl, then poll get_auth_session until status becomes active.

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 significant context beyond annotations: display starts offline and uncoupled, not normal setup flow. Returns a pre-provisioned offline profile with specific fields. No contradictions with annotations (readOnlyHint false, destructiveHint false).

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 longer but well-structured: core purpose first, then warnings, usage guidelines, and return info. Every sentence adds value, though minor redundancy exists (e.g., multiple ways to describe what not to do). Still 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?

Given the tool's complexity and the richness of schema/annotations, the description is complete. It covers purpose, usage restrictions, return fields, and scope requirements. No gaps for an AI to misinterpret.

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 each parameter already has a description. The tool description does not add new semantic info about parameters beyond what the schema provides, meeting the baseline.

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

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

The description clearly states the specific action: creating a personal display without pairing to hardware. It distinguishes this tool from siblings like pair_by_code (physical onboarding) and get_account (capacity checks). The verb 'creates' is 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 tells when to use (pre-provisioning, virtual/headless) and when NOT to use (ambiguous requests, physical setup). Provides clear alternatives: pair_by_code for hardware and get_account for capacity checks. Also mentions required 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 indicate readOnlyHint=false (write operation) and destructiveHint=false. Description adds 'creates' but does not elaborate on behavior like whether duplicate names are allowed, if there are limits, or what the response contains. 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?

Description is two sentences, no redundant words, front-loaded with the core action. 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?

For a simple creation tool with no output schema and basic annotations, the description covers the essential purpose and key variant. It could mention that it returns the created category, but given the context signals, it is sufficiently complete.

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 4 parameters with 100% description coverage. Description adds context for parent_category_id (subcategory) and 'personal' scope but does not enrich access_token or session_request_id beyond schema. Baseline 3 is appropriate.

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

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

Description clearly states it creates a personal display category and specifies how to create a subcategory via parent_category_id. This distinguishes it from siblings like rename_display_category and list_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?

Description gives one usage hint (pass parent_category_id for subcategory) but lacks explicit guidance on when to use this tool versus alternatives like allocate_licenses or assign_license. No when-not-to-use conditions are provided.

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 non-read-only and non-destructive. The description adds that the user becomes owner, requires admin scope, and returns specific fields. This supplements the annotations well.

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 sentences) and front-loaded with the main action. No redundant phrases; 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 no output schema, the description covers return values and permission requirements. It lacks error scenarios but is sufficient for the tool's complexity. Sibling context is provided through the usage hint.

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 descriptions for all parameters. The description does not add additional details about parameters, but it does mention return values. Baseline 3 is appropriate since schema carries the 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?

The description clearly states what the tool does: 'Creates a new organization and makes the authenticated user the owner.' It also provides a specific use case ('when the user wants to set up a shared display fleet'), which helps distinguish it from siblings like delete_organization or rename_organization.

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 tells when to use the tool ('when the user wants to set up a shared display fleet') and mentions a prerequisite ('Requires admin scope'). It could be more explicit about alternatives, but the context is clear.

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

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

The description reveals that the display starts offline and uncoupled, is owned by the organization, and requires admin scope and role. These behavioral traits go beyond the annotations (readOnlyHint=false, destructiveHint=false) and provide essential context for safe usage.

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 five sentences, front-loaded with the core purpose, followed by an alternative, then usage conditions and requirements. Every sentence adds 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?

The description covers the purpose, alternative, prerequisites (role, licenses), ownership, and display state. For a pre-provisioning tool without an output schema, this is complete and sets proper expectations.

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% description coverage, so the schema already explains the parameters. The description adds no new parameter-specific details beyond usage context like the organizational ownership and license requirement.

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 creates a display without pairing it to hardware, distinguishing it from siblings like pair_by_code. It specifies the verb, resource, and a key differentiating feature.

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 prefer pair_by_code for physical screens and reserve create_org_display for administrative pre-provisioning. It also notes requirements: admin scope, manager role, and available licenses, including a pointer to allocate_licenses if needed.

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

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

The annotations already indicate destructiveHint=true, but the description adds value by warning that 'displays referencing deleted assets will show broken images.' This provides contextual insight beyond the annotation. The description does not disclose other behavioral details like irreversibility or error handling, but it adds meaningful context.

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

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

The description is two sentences long, each providing essential information: the action, a consequence, and an authentication requirement. There is no redundancy or irrelevant content.

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

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

The description covers the core action and a notable side effect, but it does not mention return value, error conditions, or that deletion is permanent. Given the absence of an output schema, this leaves some gaps in understanding the full behavior.

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

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

With 100% schema description coverage, both parameters are already documented. The description essentially repeats the schema's 'One or more asset IDs' without adding new constraints or format details. Therefore, it meets the baseline but adds no extra semantic value.

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 the tool 'Deletes one or more assets', providing a specific verb and resource. The name and title align with this purpose, and it is distinct from sibling tools like update_asset or list_assets.

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 specifies an authentication prerequisite ('requires authentication with at least content_only scope') and warns about a side effect (broken images in referencing displays). However, it does not explicitly contrast this tool with alternatives or state when not to use it.

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

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

Adds significant context beyond the destructiveHint annotation: permanent deletion, 404 after deletion, cannot be undone, and authentication needed. 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, each essential: permanent deletion, specific effect (404 on readUrl), undo info, group vs personal, authentication. 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 necessary aspects: irreversible action, effect on readUrl, parameter usage for groups, authentication. No output schema needed; return value is implied (success). Complete for a destructive action.

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%, but description enhances by explaining when to use group_id vs omit. The addition 'Supply group_id to delete a group slot; omit for personal slots' adds practical meaning 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 clearly states it permanently deletes a data slot and distinguishes between group and personal slots. It is specific about the action and resource, and differentiates from sibling tools like set_data_slot and get_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?

Provides clear guidance on when to supply group_id versus omit for personal slots, and notes authentication requirement. However, it does not explicitly mention alternatives or exclusions, which would elevate the score.

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, description clarifies 'cannot be undone' and 'requires admin scope', adding valuable behavioral context.

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

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

Three concise sentences, front-loaded with critical information about permanence and usage condition, 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?

For a simple destructive action tool with good annotations, the description adequately covers return fields and prerequisites. No output schema but return is briefly mentioned.

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 clear parameter descriptions. The description does not add extra meaning beyond the schema, so 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 'deletes' and resource 'display' and states it removes associated content, clearly distinguishing from siblings like clear_display which only clears content.

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 only when user confirms removal and mentions admin scope requirement, but does not mention when not to use or provide alternatives.

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

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

Beyond annotations (destructiveHint=true), the description details side effects: releasing displays and removing members. It also emphasizes the permanent nature, which is critical for an AI agent to understand before invocation.

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 concise sentences with no superfluous information. All details are relevant and front-loaded.

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

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

For a destructive tool with no output schema, the description fully explains the action, prerequisites, side effects, and irreversibility. It covers all context an agent needs to decide and act.

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 description adds no extra meaning beyond the input schema, which already has 100% coverage with clear descriptions for both parameters. The schema adequately explains the parameters, so baseline 3 applies.

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

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

Description clearly states the verb 'deletes', resource 'organization', and specific consequences ('releasing all its displays and removing all members'). It distinguishes well from sibling tools like create_organization or rename_organization.

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 'Only the owner can delete' and 'Cannot be undone', providing clear context for when to use. Does not explicitly mention alternatives but none are needed for this irreversible 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 declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context: authentication requirements (public vs private URIs) and the exact fields returned (uri, type, title, text, data).

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, each serving a purpose: purpose, usage, authentication, return fields. No redundant or vague wording. Front-loaded with the core 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?

Despite no output schema, the description covers all aspects an agent needs: what it does, when to use, authentication, return values. The tool is simple and the description is fully adequate.

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 detailed parameter descriptions. The description adds meaning by listing the return fields (uri, type, title, text, data) which are not in the input schema, and provides usage context for the authentication 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 verb 'retrieves' and the resource 'full details of a single agentView resource identified by its URI'. It distinguishes from sibling tools like 'search' by specifying 'use after search' and 'directly when you already know the URI'.

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: 'after search to read the complete content' or 'directly when you already know the URI'. It also explains authentication requirements for public vs private URIs, but does not explicitly state when not to use this 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?

Description adds authentication scope requirement ('Requires authentication with at least content_only scope') beyond annotations, which already declare readOnlyHint, idempotentHint, and destructiveHint. No contradictions, and the extra context is useful but not extensive.

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?

Description consists of three sentences: purpose, usage, and exclusion. It is front-loaded with the main action and uses concise language. Slightly verbose due to explicit field listing, but not wasteful; it earns its length.

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

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

Given the absence of an output schema, the description fully compensates by listing all return fields and specifying authentication requirements. It covers when and when not to use, and integrates with sibling tool differentiation. No gaps for a simple retrieval tool.

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?

Input schema has 100% description coverage for both optional parameters (access_token and session_request_id). The description does not add new parameter semantics beyond schema; it mentions authentication but does not elaborate on parameter usage. 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?

Description begins with 'Returns the authenticated user's account profile' and enumerates specific fields, clearly stating the verb and resource. It explicitly distinguishes from 'list_displays' by saying 'Do not use this to list displays — use list_displays instead.'

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 'Use this to answer questions about the user's subscription, display quota, organization memberships or plan capabilities.' Also provides a clear when-not and alternative: 'Do not use this to list displays — use list_displays instead.'

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?

Description adds authentication requirement ('requires authentication with at least content_only scope') beyond annotations (readOnlyHint, idempotentHint, destructiveHint). No contradictions; fully transparent.

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 concise sentences front-loading purpose and usage. Every sentence adds 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 simplicity (2 params, no output schema), the description covers purpose, usage, and auth. It does not detail error responses for missing assets, but annotations and schema already provide sufficient 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 description coverage is 100% with clear descriptions for both parameters. The tool description does not add additional parameter semantics beyond what the schema provides, meeting baseline.

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

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

The description clearly states verb 'Returns' and resource 'metadata for a single asset including its URL', distinguishing it from sibling tools like list_assets (plural) or update_asset/delete_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?

Provides a specific use case ('verify an asset still exists before referencing it in HTML'), giving clear context. While it does not explicitly mention when not to use or alternatives, the usage scenario is well-defined.

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 safe read/indempotent behavior. Description adds valuable context: states (pending/active/expired), polling frequency, automatic authentication on success, and retry instruction for expired. No contradictions detected.

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?

Description is somewhat lengthy but each sentence serves a purpose. Structured logically: purpose, usage pattern, state descriptions, and outcome. Could be slightly tighter but remains clear.

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 high schema coverage, supportive annotations, and no output schema, the description fully explains return states with token details, polling behavior, and post-authentication impact. No gaps remain.

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 parameter 100% with description. Description adds crucial context: the session_request_id must be passed exactly as received from create_auth_session, emphasizing precision.

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 the tool polls a login session and returns the agent token upon user completion. It identifies the resource ('auth session'), the action ('poll status'), and distinguishes itself from create_auth_session.

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

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

Explicitly instructs to use after create_auth_session, poll every 2-3 seconds until status changes, and not for any other purpose. Also provides clear branching logic for 'pending', 'active', and 'expired' states.

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 provide readOnlyHint and idempotentHint. Description adds scope requirement ('Requires content_only scope') and usage flow context, 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 sentences, front-loaded with the main action. No wasted words, covers purpose and usage efficiently.

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?

Tool complexity is low (1 optional param, no output schema). Description covers purpose, usage, scope, and post-action (present URL, offer to allocate). Complete for the tool's modest needs.

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

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

Only one optional parameter (access_token) with 100% schema coverage. Description does not add extra meaning beyond the schema's 'Optional JWT access token for authentication.' 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 it returns a URL to the billing/subscription page for purchasing/managing premium display licenses. It uses specific verb 'Returns' and resource 'URL to billing page', distinguishing it from sibling tools like get_pricing or 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?

Explicitly states when to use: 'when the user wants to buy more licenses, upgrade their plan, or manage their subscription.' Provides workflow guidance on presenting the URL and offering to allocate licenses. Lacks explicit when-not-to-use, but still clear.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by noting that the response includes a readUrl and that authentication is required, providing behavioral context beyond annotations. 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 with no fluff. Front-loaded with the main purpose and quickly covers key usage nuance and response detail. 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 retrieval tool with 3 parameters (1 required), annotations, and no output schema, the description fully covers purpose, parameter semantics, authentication, and an important response field (readUrl). No gaps identified.

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 (100%), so baseline is 3. The description adds semantic value by clarifying the group_id parameter's role in distinguishing group vs. personal slots, and reinforces the access_token's purpose for authentication.

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 the verb 'Returns' with the resource 'data slot by slug', specifies group vs. personal slots, and mentions response contents including readUrl. It clearly distinguishes from sibling tools like 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?

The description states when to supply group_id vs. omit it, and mentions authentication requirement. It implicitly guides usage for specific slug retrieval but does not explicitly contrast with alternatives like list_data_slots when the slug is unknown.

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?

Even with annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds valuable behavioral details: scope restricted to displays the caller can see, capped at 50 results with 'truncated' flag, and requires authentication. These go beyond what annotations provide.

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 with only three sentences. The first sentence defines the action, the second gives usage context, and the third adds limitations. No redundant information, and it's front-loaded with the most important 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?

The description covers purpose, usage, scope, limits, and authentication. With no output schema, it mentions the 'truncated' flag but doesn't detail the full return structure, which is acceptable given the tool's complexity. Slight room for improvement in describing the result format.

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?

Although the schema covers all parameters with 100% description coverage, the description does not add extra meaning beyond the schema. It mentions the slug but doesn't elaborate on parameter usage or constraints, 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?

The description clearly states the tool 'lists displays whose IdleHtmlContent embeds a {{slot:<slug>}} placeholder', specifying a specific verb and resource. It distinguishes itself from siblings like delete_data_slot and set_data_slot by mentioning their relationship, making 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?

The description provides explicit usage guidance: 'Use this BEFORE delete_data_slot to know which displays will start returning 404, or before set_data_slot on a structural change to know which displays will pick up the new shape.' It also mentions scope restrictions and the 50-result cap, helping the agent decide when to use this tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds detailed behavioral context about what is returned (live state, content, pairing links, etc.) and authentication scope, going beyond annotations without 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?

Two sentences, front-loaded with core purpose, no wasted words. Efficient and structured.

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

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

Description covers authentication prerequisites, usage context, and hints at output contents despite missing output schema. Fully adequate for a single-record retrieval tool.

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 with descriptions. The tool description adds no additional parameter information beyond what is in the schema; the baseline score of 3 applies.

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

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

The description clearly states it returns full details of a single display, listing specific aspects like live state, content, pairing links, etc. It explicitly distinguishes from list_displays, which is a sibling tool for discovery.

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 this when you already know the display ID and need its complete state. Do not use this to discover displays — use list_displays first.' Also mentions authentication scope requirement.

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 as read-only and idempotent. The description adds behavioral details: unresolved placeholders are kept verbatim in .content and listed in .unresolvedPlaceholders, and authorization requirements are stated. 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 sentences) with a clear structure: purpose, usage flow, requirements, and output details. 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?

Given no output schema, the description partially explains the response structure (artifact body, placeholder handling). It covers usage context, prerequisites, and typical flow, making it suitably complete for an agent to select and invoke the tool.

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, but the description adds context for the key parameter (examples and guidance to use get_store_template_details), and explains the display_id source. This adds meaningful 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 clearly states the tool returns the agent-onboarding artifact body with resolved placeholders for a specific display, and distinguishes it from related tools by highlighting the placeholder substitution. The 'killer flow' example reinforces the specific purpose.

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

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

The description provides a concrete usage flow (list_displays → get_display_agent_artifact → write to file) and mentions prerequisites (content scope, ownership). However, it does not explicitly exclude alternatives like get_store_template_agent_artifact, leaving the when-not-to-use implicit.

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 value by stating the required authentication scope ('content_only') and listing the extensive set of return fields (screen, viewport, touch hints, etc.), which helps the agent understand the behavioral completeness without 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?

The description is two sentences, highly efficient. The first sentence lists the key outputs, and the second gives usage timing and auth requirements. Every word serves a purpose, 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?

Although there is no output schema, the description enumerates nearly all return fields (effective network mode, screen, viewport, touch/input hints, browser/engine version, platform, feature support, known limitations, graphics hints, recommended delivery mode). This is sufficiently detailed for an agent to understand what to expect, though it could be slightly more structured.

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% description coverage, and the description does not add any additional meaning beyond what the schema already provides for the parameters. 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 a specific verb ('Returns resolved display capabilities') and clearly identifies the resource and scope. It lists concrete facts (network mode, browser/runtime details) and explicitly differentiates from sibling tools by stating it should be called before generating HTML, making it distinct from other get/read tools.

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 'Call this BEFORE generating or sending HTML' and specifies authentication requirements ('Requires authentication with at least content_only scope'). While it does not provide when-not-to-use or alternatives, the context is clear enough for the agent to determine this is a prerequisite read operation.

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 provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description goes beyond by listing the specific data returned (active content file, currentContentDescription, content URL, displayUrl, idle content, delivery status), noting that displayUrl shows real-time rendering, and specifying the required auth scope (content_only). 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?

The description consists of two clear, front-loaded sentences. The first sentence lists what the tool returns, and the second provides usage guidance. Every sentence adds value with no redundancy or unnecessary detail.

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 moderate complexity, good annotations, and full schema coverage, the description provides all necessary context: return fields, usage prioritization (currentContentDescription over read_display_html), real-time preview capability, and authentication scope. No output schema exists, but the return values are described sufficiently for an agent to understand the tool's output.

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 both parameters (display_id and access_token) with descriptions. The description adds value by associating the access_token parameter with the authentication requirement (content_only scope), which is not explicitly stated in the schema property description. Since schema coverage is 100% and the description complements the parameters, a score of 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 clearly states it returns the current content state of a display, lists specific fields (active content, currentContentDescription, URL, displayUrl, idle content, delivery status), and distinguishes itself from the sibling read_display_html by advising to use currentContentDescription first and only call read_display_html when raw source access is needed.

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 when to use this tool ('Use currentContentDescription first to understand intent') and when to use the alternative read_display_html ('only when raw source access is truly needed'). It also notes the authentication requirement with content_only scope. However, it does not mention other potential alternatives or contexts where this tool might not be appropriate.

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 readOnlyHint annotation, the description discloses TTL clamping based on privacy_mode, automatic expiration when owner pushes new content, and recipient limitations (cannot push or configure). 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?

The description is well-structured, starting with the primary purpose, then usage guidance, then technical details. Every sentence adds value without redundancy. Length is appropriate for the 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?

Despite having no output schema, the description enumerates all return fields (previewUrl, expiresAt, ttlSeconds, displayName, contentVersionId, privacyMode). It also covers authentication, TTL clamping, and recipient behavior, making the tool fully understandable.

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%, but the description adds significant value by explaining default TTL (3600), clamping behavior ([60, ceiling]), and per-mode caps (Private 3600s, Public 86400s). This context is not available in the schema alone.

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 generates a short-lived signed share link for the display's current content, distinguishes it from the legacy URL, and highlights it's the only supported way. It specifies the action (generate preview link) and the resource (display's current content) with explicit differentiation 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?

The description explicitly tells when to use: when the user wants to share screen content, embed it, or hand to an integration. It also notes the legacy URL is removed and that the link expires, providing clear guidance on appropriate scenarios.

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 value by listing the specific return components, but it doesn't detail response format or edge cases like no licenses.

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 that are well-structured and front-loaded with key information. No unnecessary words 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?

The description covers the main purpose and usage context. While no output schema exists, it enumerates enough components for understanding. Minor omission: doesn't clarify if the response is paginated or includes cumulative totals.

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

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

Schema coverage is 100% for the single optional parameter. The description does not add further explanation beyond the schema's own description, meeting baseline but not exceeding.

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 'complete license allocation overview' with specific components (total premium, personal usage, etc.). It distinguishes itself from siblings like allocate_licenses by focusing on reading 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?

The description explicitly says 'Use this to understand available capacity before allocating licenses,' providing clear context. It also mentions the required 'content_only' scope, setting prerequisites.

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 readOnly and idempotent behavior. The description adds useful context about the return content and required authentication scope, but does not mention other behavioral traits like rate limits or error conditions.

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, no wasted words. The first sentence states the purpose, the second provides usage guidance, and the third covers authentication. Information is front-loaded and efficient.

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

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

For a read-only tool with good annotations and full schema coverage, the description covers the output contents, usage context, and authentication requirements. No obvious gaps given the tool's simplicity.

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 already describes both parameters well. The description does not add new parameter-specific information beyond what is in the schema, so 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 states it returns full details of a specific organization including displays, members, slots, and capacity, and explicitly differentiates from sibling list_organizations by saying 'Use this after list_organizations to inspect a specific organization's state.'

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 clearly tells when to use the tool (after list_organizations) and specifies authentication requirements (content_only scope, user must be a member). It does not explicitly list alternatives or when not to use, but the context is sufficient.

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, destructiveHint), it adds that 'no authentication required' and describes return structure (array of plans with name, price, included displays, features, per-display add-on price, link). 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?

Two sentences, front-loaded with purpose, then usage, then details. Every sentence adds 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?

For a zero-parameter, read-only tool, the description covers purpose, usage, authentication, and return details comprehensively. No 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?

Zero parameters, so baseline 4 applies. Description adds no parameter info but effectively explains the return value, which compensates for lack of output 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 returns 'agentView plan pricing, features and upgrade options,' which is a specific verb and resource. It distinguishes itself from siblings by being the only pricing-related tool among many.

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

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

Explicitly states when to use: 'when the user asks about pricing, costs, plan differences or what an additional display costs.' No exclusions or alternatives needed given its unique purpose.

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 it as readOnlyHint and idempotentHint. The description adds 'No authentication required' and lists the returned fields (status, server name, version, statusUrl, instructionsUrl), which gives the agent a full picture of its behavior 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 two sentences that are concise and front-loaded: the first states what it returns, the second gives usage guidance. Every sentence adds value, with 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?

Given the tool has no parameters and no output schema, the description fully covers its purpose, return values, and usage context. It explains exactly what an agent needs to know: no auth required, returns status and URLs, and should be used before authentication.

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?

Input schema has zero parameters with 100% schema coverage, so the description need not add parameter details. The description implicitly handles this by focusing on the tool's purpose and return values, which is adequate.

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 the server's public readiness status, version string and discovery URLs,' which specifies the verb and resource clearly. Among many sibling tools, this is the only one for pre-authentication status checks, making it easily distinguishable.

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 clear context with 'Use this before authenticating to verify the server is reachable and to obtain entry-point URLs,' indicating when to use and what for. While it doesn't explicitly exclude alternatives, the guidance is sufficient for an agent to decide 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 readOnly, idempotent, non-destructive, so the description's main contribution is clarifying scope (personal vs group) and the suppression of raw numbers for narrow-scoped keys, which adds useful behavioral context.

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

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

Two sentences without unnecessary words. The key action and important usage note are front-loaded, and 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 tool's simplicity (2 optional params, no output schema), the description fully covers purpose, scope, usage timing, quota sharing, and a special behavior. No gaps for effective agent decision-making.

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 clear descriptions for both parameters. The main description adds no additional parameter detail beyond what the schema provides, 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 returns a storage pool snapshot with used/limit/remaining bytes, distinguishing it from siblings like get_data_slot_usage and set_data_slot. It specifies scope (personal or group) and the shared quota nature.

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 calling this tool BEFORE set_data_slot or upload_asset on large payloads to avoid 413 quota_exceeded errors. Also mentions suppression behavior for scoped API keys, providing clear 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 provide readOnlyHint, idempotentHint, destructiveHint. Description adds that placeholders are not substituted and no authentication is required, which is useful 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?

Two sentences that efficiently cover purpose, examples, substitution behavior, usage guidance, and how to discover keys. No 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?

Despite no output schema, description fully explains what the tool returns, when to use it, and how to find artifact keys, making it complete for the given 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% but description provides additional examples for key ('bot-system-prompt', 'agent-skill') and slug ('agent-ops-cyan-wall'), adding clarity 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?

Description clearly states it returns the raw body of an agent-onboarding artifact, lists examples (system prompt, SKILL.md, MCP-config), and distinguishes from get_display_agent_artifact by noting raw vs substituted body.

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

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

Explicitly states when to use (BEFORE install, no display to resolve slots) and when not (AFTER install, use get_display_agent_artifact). Also references get_store_template_details for discovering artifact 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by listing the exact fields returned and confirming no authentication is needed, which is not in annotations. 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 two sentences. The first sentence is somewhat long but packs all relevant return fields. The second is very concise. Overall efficient with 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?

The tool is simple (retrieve details by slug). No output schema exists, but the description enumerates all returned fields sufficiently. Combined with high annotation coverage, the description is fully complete for this 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?

Input schema has 100% coverage with descriptions for both parameters (slug and language). The description does not add further semantics beyond what the schema provides, so 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 clearly states the action ('Returns the full public details') and the resource ('single store template'), and lists the specific fields returned. It distinguishes from siblings by referencing 'search_store_templates' as the preceding step, making its role unique.

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 directs when to use this tool ('after search_store_templates picks a candidate') and provides the workflow context ('explain the template before offering to send it to a display'). It also notes 'No authentication required', clarifying a usage condition.

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

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

Annotations already declare readOnly, idempotent, non-destructive. Description adds auth scope required (content_only) and API-key whitelist behavior.

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

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

Slightly long but well-structured with numbered points; efficient for the information conveyed.

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

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

No output schema, but description fully explains return structure (displays, slots) and error case (no displays). Complete for tool 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?

Input schema has 100% coverage with descriptions. Description reinforces slug source but adds minimal extra meaning.

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 the tool returns displays and data slots for a template, distinct from sibling '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 'Call this before send_store_template_to_display' and advises on handling no displays (create/claim a display).

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 mark destructiveHint: true, and the description adds behavioral context: the invite is valid for 7 days, can be bound to an email, and returns an inviteUrl. It also discloses authorization requirements. No contradiction with annotations; the description supplements them well.

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 four efficient sentences, front-loaded with the main action. Every sentence serves a purpose: purpose, validity, options, authorization, output. No 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 the complexity (4 parameters, no output schema, but annotations present), the description covers purpose, validity, optional binding, authorization, and output. It omits error cases or duplicate invite handling, but is sufficient for an agent to decide usage.

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% description coverage, so the schema already defines parameters clearly. The description adds minimal value by reiterating optional email binding and return value, but it does not enrich parameter meaning significantly 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 clearly states the tool creates an invite link to add a new member to an organization. It specifies the verb 'creates' and the resource 'invite link,' which distinguishes it from sibling tools like remove_member or update_member_role.

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 context for when to use the tool: to add a new member. It also mentions prerequisites ('requires admin scope and the user must be an admin or owner'). However, it does not explicitly mention when not to use it or suggest alternative tools, though the sibling list implies alternatives.

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

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

Annotations indicate readOnly and idempotent. Description adds that it never returns the raw key and requires admin scope, providing useful behavioral 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?

Two concise sentences with no redundancy. Front-loaded with core purpose, immediately actionable.

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

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

No output schema, but describes return format (metadata fields). Mentions scope requirement. Adequately complete for a list operation.

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

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

Schema has 100% coverage with one optional parameter. Description does not elaborate on the parameter, meeting baseline for high coverage but not adding extra value.

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 lists all API keys for the current user, returning metadata but not the raw key. It distinguishes from sibling tools like create_api_key and revoke_api_key.

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?

Implicitly clear when to use (to list keys), and mentions prerequisite 'Requires admin scope'. No explicit 'when not to use', but adequate for a simple list operation.

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=true and destructiveHint=false. Description adds value by specifying authentication scope ('content_only') and clarifies that listing can be used to check for duplicates before uploading. 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 essential. First states purpose, second explains key parameter usage, third adds authentication requirement. No redundant 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 core functionality (filtering, scope, auth). No output schema but listing assets is straightforward. Limit and pagination details are in schema. Could mention default limit but schema covers it.

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

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

Input schema covers all 5 parameters with 100% description coverage. Description adds context for group_id, explaining its role in accessing shared vs personal assets. This enhances understanding beyond the schema. Other parameters are well-described in 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?

Clearly states 'Lists uploaded assets with optional filtering', specifying verb and resource. Differentiates from siblings like delete_asset, get_asset, upload_asset by focusing on listing with filtering and scope. Explicitly covers personal vs group assets.

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 clear when-to-use for group_id (organization displays) and when not to use it (personal assets). Includes authentication scope requirement and a tip to check before uploading. Does not explicitly mention alternatives but context is sufficient given sibling tools.

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 provide readOnlyHint and idempotentHint. The description adds value by clarifying it returns metadata without jsonContent and explains the readUrl format, which is behavioral 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: purpose, return format with URL, authentication. No wasted words, front-loaded with key information.

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

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

No output schema, so description explains return value (metadata only, no jsonContent, readUrl). Covers authentication and URL format. Pagination details are in schema. Sufficient for a list tool.

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?

Input schema has 100% coverage with descriptions for all 5 parameters. The description adds minimal additional meaning (e.g., 'optional filtering') but relies on schema for parameter details.

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 lists data slots with optional filtering and returns metadata only. It distinguishes from siblings like get_data_slot (single) and delete_data_slot (delete).

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

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

The description specifies authentication requirement and explains how to use the readUrl in fetch() calls. It implicitly differentiates from get_data_slot for single retrievals but lacks explicit when-not 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 readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds the authentication scope requirement, which is a behavioral trait beyond the annotations. 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.