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

With no annotations, the description must disclose behavioral traits. It describes the return envelope (success/error, data structure) but omits information about authentication, rate limits, or side effects. Since it is a read operation, the risk is low, but more detail would be beneficial.

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 and well-structured with Args, Returns, and Examples sections. It is front-loaded with the main purpose and uses clear formatting, earning its sentences 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, simple output), the description is thorough. It covers the return envelope and provides an example. An output schema exists, so repeating return fields is unnecessary. Could mention prerequisites or error conditions, but overall 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 coverage is 0%, so the description must add meaning. It explains both parameters (profile_id and configuration_id) with example UUIDs and includes an example call. This adds value beyond the raw schema, though constraints like format or required patterns are not explicitly stated.

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 'Get' and the resource 'build configuration', and specifies that it retrieves a single configuration by profile ID and configuration ID. This is specific and sufficiently distinct from sibling tools, even without explicit differentiation.

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

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

The description provides no guidance on when to use this tool versus siblings like get_build_profile_details or get_workflow_detail. There are no use-case scenarios or exclusions, leaving the agent to infer context.

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

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

With no annotations, the description fully discloses behavioral traits: pagination (default page size 50), the effect of omitting date filters, and the reason for pagination (token limit issues). It does not mention rate limits or security, but these are not critical for this read operation.

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

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

The description is well-structured with sections for overview, important notes, args, returns, and examples. It is detailed but not overly verbose; every sentence is informative. Slightly lengthy but justified by the number of parameters.

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 6 optional parameters and the existence of an output schema, the description is comprehensive. It covers all parameter details, behavior, pagination, return structure, and provides multiple examples. It is complete enough for an AI 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 0%, but the description thoroughly explains each parameter's purpose, format (date format 'YYYY-MM-DD'), constraints (page starts at 1, size 1-100, defaults), and provides examples. This adds significant value beyond the bare 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's action ('Get build history report'), the resource ('build history'), and its optional filtering by date range. It distinguishes itself from sibling tools that focus on other entities like bundle identifiers or build profiles.

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 context on when to use the tool (retrieving build history) and explains default behavior (returns all items without date filters). It also warns about pagination to avoid token limits. However, it does not explicitly mention when not to use it or compare to 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?

With no annotations provided, the description carries full burden and excels. It discloses internal fetching, computation, best-effort behavior for fetches that fail due to permissions, omission of unresolvable sections rather than fabrication, cross-org scoping nuances, and detailed meta fields for omissions and failures. This level of transparency is exemplary.

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 with a summary, contrast, behavioral notes, Args, Returns, and Examples. It is front-loaded with purpose. However, it is somewhat verbose and could be tightened while retaining completeness.

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 is exceptionally complete for a complex tool, covering input parameters, behavioral nuances (permissions, cross-org, best-effort), output structure with meta fields, and examples. With no output schema provided, the Returns section sufficiently describes 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?

Given that the input schema has 0% description coverage, the description fully compensates with a detailed Args block explaining each parameter's format, defaults, behavior, and valid enum values (for sections). This adds complete meaning beyond the schema's type information.

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 'Get a computed Build Insights Report over build history' and enumerates the sections computed. It explicitly distinguishes itself from the sibling 'get_build_history_report' which returns raw paginated records, providing clear differentiation.

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

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

The description explains when to use this tool versus alternatives, specifically contrasting with get_build_history_report. It also provides detailed guidance on the include_sub_orgs flag, default date ranges, and how sections are handled, giving the agent clear decision criteria.

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?

No annotations provided, so description fully covers behavior: it optionally calls another endpoint for configurations, and explicitly states excluded fields (connectionEnvironmentKey, webhookSecret). Return format and error pattern are documented.

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 well-organized with Args, Returns, and Examples sections. No redundant information; 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 the output schema exists, description still provides useful context on return structure and excluded fields. It is complete enough for an agent to use the tool correctly.

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

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

Schema coverage is 0%, but the description explains both parameters in detail: profile_id as UUID, configurations as boolean with default False and the effect of including configurations in the response.

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 single build profile by ID, optionally including configurations. It distinguishes from sibling tools like get_build_profiles (list) and get_build_configuration_details (specific configuration).

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

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

The description implies usage for fetching a specific profile, with examples showing typical calls. However, it does not explicitly state when not to use this tool or compare to 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?

With no annotations provided, the description carries full burden and thoroughly discloses behavior: pagination details, search capabilities, return fields (with exclusions), and error handling. It is transparent about being a read-only listing with no side effects.

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

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

The description is well-structured with a summary, parameter details (Args block), return info, and examples. It is appropriately detailed given the lack of schema coverage, though slightly verbose with redundant list-style parameter descriptions.

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 output schema exists, the description complements it well by mentioning excluded fields, pagination metadata, and error envelope. It covers all aspects needed for an agent to use the tool correctly.

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

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

Schema coverage is 0%, so description compensates fully. It explains page (1-based, default 1), size (default 25, capped at 100), and search (case-insensitive partial match with examples), adding significant meaning beyond the schema's type/default info.

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 'Get build profiles for the current organization (paginated)', using a specific verb and resource. It distinguishes itself from siblings like get_build_profile_details by focusing on listing with pagination and optional search.

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

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

The description implies usage through examples and parameter descriptions, but does not explicitly state when to use this tool vs alternatives like get_build_profile_details or get_distribution_profiles. The context is clear but lacks exclusion 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?

No annotations are provided, so the description carries the full burden. It fully discloses the read-only behavior, parameter requirements, return structure (standard envelope with success/error), and even includes an example. No side effects or hidden traits.

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

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

The description is concise and well-structured: first sentence states purpose, then separate sections for args, returns, and examples. Every sentence adds value, and it is front-loaded with the key action.

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

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

Given the tool has one parameter and an output schema (mentioned in context), the description covers usage, parameter semantics, return format, error handling, and an example. It is fully complete for a 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 coverage is 0%, but the description explicitly explains the profile_id parameter as 'The build profile ID (e.g. UUID)', adding meaning beyond the schema's type and title. This compensates well for the lack of schema descriptions.

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

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

The description explicitly states 'Get workflows for a build profile by profile ID', a specific verb+resource. It lists the returned fields (id, name, last used time), clearly distinguishing it from siblings like get_build_profile_details or get_workflow_detail.

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 context (by profile ID) and an example usage. However, it does not explicitly mention when not to use or suggest alternatives among the many sibling tools, so it stops short of a 5.

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

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

No annotations are provided, so the description carries the full burden. It details the return structure, includes an example, and describes the data fields. It is transparent about being a read-only operation.

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

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

The description is concise, well-structured with a summary, return details, and an example. Every sentence is informative and 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 no parameters and an output schema (referenced via standard envelope), the description is complete. It sufficiently explains the tool's behavior and return 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?

The description explicitly states no parameters are needed, which adds meaning since the schema is empty. For a parameterless tool, this is excellent clarity.

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 retrieves all bundle identifiers for the organization and lists the returned fields. It distinguishes itself from sibling tools by being a simple, parameterless list operation.

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

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

The description states it takes no parameters and returns all bundle identifiers, but does not explicitly guide when to use this tool versus siblings. However, the context of 'all' versus filtered tools is implied.

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

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

With no annotations, the description fully discloses behavior: it takes no parameters, omits sensitive fields (p12Password, etc.), and returns a standard envelope with success/error formats.

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 (two short paragraphs), front-loaded with the main purpose, and uses clear structure including examples.

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 with an existing output schema, the description covers all necessary context: authentication, return structure, and omission of sensitive fields.

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

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

No parameters exist, so baseline 4. Description correctly states 'Takes no parameters.' This 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 clearly states 'Get all signing certificates for the organization.' and specifies it returns a list of signing certificates, distinguishing it from siblings that deal with bundle identifiers, build profiles, etc.

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

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

The description implies when to use (to retrieve signing certificates) but does not explicitly state when not to use or provide alternatives. Given the sibling context, it's clear but not explicitly guided.

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?

No annotations provided, so the description carries the full burden. It details the return structure (standard envelope with success/error, commit fields) and implies read-only behavior. It does not disclose authentication or rate limit details, but these are acceptable for a simple retrieval tool.

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

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

Well-structured with a clear one-line purpose, parameter descriptions, return explanation, and examples. Slightly verbose with the 'Args' and 'Returns' sections, but every part contributes 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?

Despite lacking output schema details in the structured data, the description manually enumerates return fields and provides examples. It covers the essential behavioral and semantic aspects for an agent to use the tool correctly.

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

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

Schema coverage is 0%, so description must compensate. It adds concrete meaning: commit_id is a UUID, commit_hash is a 40-character git SHA. It also states the usage context for each parameter, significantly aiding schema understanding.

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

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

Clearly states the tool retrieves a single commit by either commit ID (UUID) or commit hash (git SHA). This specific verb-resource combination distinguishes it from siblings like get_commits_by_branch.

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 provide only one of commit_id or commit_hash, not both, and explains when to use each. However, it does not mention scenarios where the tool should not be used or suggest alternatives beyond the sibling list.

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

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

With no annotations, the description fully discloses behavior: pagination metadata in meta, default values, value cap at 100, standard return envelope format. 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?

Well-structured with summary, Args, Returns, and Examples sections. Comprehensive but slightly lengthy; could be trimmed slightly while retaining all 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?

Complete for a paginated list tool with output schema. Covers all parameters, return format, and examples. No gaps for agent 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?

Adds significant meaning beyond bare schema: branch_id as UUID, page as 1-based with default and pagination behavior, size with default and cap. Schema coverage was 0%, so description compensates fully.

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 'Get commits for a build branch' and specifies return fields (hash, message, author, etc.). Distinguishes from sibling tools like get_commit_details which likely returns a single commit.

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 detailed usage context: pagination is enabled when both page and size are provided, default values, and value caps. Includes examples. However, it does not explicitly mention when to use this tool over alternatives like get_commit_details.

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?

No annotations provided, so description carries full burden. Describes pagination behavior, default page size, token limit concerns, and return format (standard envelope). Does not mention any destructive actions or side effects, which is appropriate for a read-only report tool. Some additional details like date format examples enhance transparency.

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?

Well-structured with summary, details, args, returns, and examples. Every section adds value. A bit verbose, but clarity outweighs conciseness. Could potentially shorten the examples, but overall efficient.

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

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

Given 7 parameters, pagination, and multiple filters, the description covers all necessary aspects: default behavior, pagination mechanics, parameter details, return format reference. Existence of an output schema (standard envelope) means return values are handled separately. Agent has full context 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 has 0% description coverage, so description must compensate. It includes an 'Args:' section with descriptions, types, formats, defaults, and examples for all 7 parameters. This adds substantial meaning beyond schema, such as date format, default page size, and filter semantics.

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

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

Starts with a clear verb+resource: 'Get daily usage report for distributed app versions.' The description further specifies it retrieves paginated daily usage data, making the purpose unambiguous. It does not explicitly distinguish from siblings, but the resource is unique enough among sibling 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?

Provides usage context: behavior without start/end dates returns all items, supports filtering by profile, OS, organization. However, it lacks explicit when-to-use vs. alternatives or when-not-to-use. The sibling list contains many 'get_*' tools, but no clear differentiation is stated.

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

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

With no annotations, the description carries the full burden. It accurately discloses that the return excludes settings.password, includes pagination for app versions, and provides error envelope structure. However, it does not explicitly state read-only nature (though implied) or authorization needs.

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-organized into sections: purpose, returns, args, examples. Every sentence provides necessary information without verbosity. It is appropriately sized for the tool's complexity.

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

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

The description covers purpose, parameters, return format including pagination, and provides usage examples. Given the presence of an output schema, it does not need to explain return fields in detail. It is complete for a detail 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?

The description fully explains each parameter: profile_id as a UUID, page as 1-based integer defaulting to 1, size as 1-100 capped at 100 with default 25. This adds significant value beyond the schema, which had 0% description coverage.

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

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

The description clearly states it gets a single testing distribution profile by ID with optional app versions pagination. The verb 'Get' and resource 'distribution profile' are specific, and it distinguishes from sibling list tool 'get_distribution_profiles' by focusing on a single profile with details.

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

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

The description implies usage via the 'Get a single ...' phrasing, but it does not explicitly state when to use this tool over alternatives like 'get_distribution_profiles'. No when-not or alternative guidance is 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?

With no annotations, description carries full burden. It discloses pagination, search filtering, default values, capping behavior, exclusion of sensitive data (password), and return envelope structure. Does not mention authorization or rate limits, but is transparent for a read-only tool.

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

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

Description is well-structured: summary, return content, parameter details, return envelope, and examples. Every sentence adds value, though could be slightly more concise. Front-loaded purpose helps quick understanding.

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 (3 optional parameters, no enums, output schema exists), description covers all aspects: parameter explanations, behavior constraints, return format, and examples. Includes privacy note about password exclusion. Complete for a paginated 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?

Schema has no descriptions (0% coverage), but description explains each parameter: page (1-based, default 1), size (range 1-100, capped), search (case-insensitive partial match with example). These details add critical 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?

Description clearly states the verb 'Get' and resource 'testing distribution profiles for the current organization (paginated)'. It specifies the returned fields (IDs, names, versions, etc.) and the optional filter, distinguishing it from sibling tools like 'get_build_profiles' or 'get_store_profiles'.

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 explains the purpose and optional search parameter, but does not explicitly state when to use this tool versus alternatives or provide 'when not to use' guidance. Examples show typical usage, but no sibling comparison.

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?

Since no annotations are provided, the description carries full burden. It discloses that results are paginated by default with a default size of 50, and explains how to navigate pagination. It also specifies the return envelope structure. This is thorough for a read-only report retrieval tool.

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

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

The description is well-structured with a brief intro, an Args section, a Returns section, and Examples. It is slightly long but every section adds value. The most important information (purpose and pagination) is front-loaded.

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

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

Given the tool has 7 parameters, no annotations, and an output schema exists, the description covers all necessary aspects: purpose, all parameters with formats and defaults, pagination behavior, return structure, and usage examples. It is fully complete for effective tool selection and invocation.

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

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

With 0% schema coverage, the description adds extensive meaning: it provides formats, examples, defaults, and explanations for all 7 parameters. It clarifies that start_date/end_date are optional and how they affect results, and explains filtering options like profile_name, os, and organization_id.

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 retrieves a 'daily usage report for distributed app sharing', with a clear verb ('Get') and resource ('daily usage report'). It distinguishes itself from sibling tools like get_build_history_report by focusing on app sharing distribution data.

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

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

The description explains when to use the tool (to get paginated daily usage data) and provides multiple examples showing different call patterns. It does not explicitly state when not to use it or mention alternatives, but the examples and parameter descriptions give clear 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?

With no annotations, the description carries full burden. It discloses pagination behavior: 'Results are paginated by default to prevent token limit issues. Default page size is 50 items. Use page parameter to retrieve additional results.' It also details the return structure (Standard envelope with success/data/meta/error). This provides good transparency beyond basic read-only implied by 'get'.

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 with a brief opening line, a second line summarizing function, then bullet-like list of parameters, returns, and examples. It is appropriately sized for the complexity and front-loads the purpose. The examples add clarity without excessive verbosity.

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 5 parameters (2 required), pagination, and reference to external output schema, the description covers all essential aspects: date format, pagination mechanism, optional filter, return structure, and examples. It is complete for an agent to correctly 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?

Schema coverage is 0%, so description must explain all 5 parameters. It does: start_date/end_date with format and examples, page/size with defaults and ranges, organization_id as optional filter. Examples demonstrate usage. This fully compensates for lack of schema descriptions.

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

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

The description clearly states the verb 'Get' and resource 'app usage report for enterprise app store' in the first sentence, then elaborates 'Retrieves paginated daily app usage data for the enterprise app store.' This distinguishes it from sibling tools like get_build_history_report by specifying the enterprise app store context.

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 does not explicitly state when to use this tool versus alternatives. It mentions required parameters (start_date, end_date) and optional organization filter, but lacks guidance on situations where this tool is preferred over others. No exclusions or when-not-to-use 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?

No annotations provided, so the description carries the full burden. It discloses that sensitive fields are omitted and describes the return envelope. It is a read-only operation, which is implicit.

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 brief, front-loaded with the purpose, and includes the return format and an example. 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 no parameters and the presence of an output schema, the description is adequately complete. It explains what is returned and omitted. A mention of read-only nature would improve 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?

No parameters exist (schema has 0 properties). The description correctly states 'Takes no parameters.' The baseline is 4 for zero-parameter tools.

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 ('Get all keystores') and the resource ('for the organization'). It distinguishes from sibling tools by naming the specific resource (keystores).

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 lacks explicit guidance on when to use this tool versus alternatives. It only describes what it does, without stating when not to use it or suggesting other 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly mentions that sensitive/large fields (binary, metaData, certificateThumbPrints, provisionedDevices, connectApiKeyId) are omitted from the response, and describes the return format. This adds significant transparency beyond basic read operation knowledge.

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 with sections for Args, Returns, and Examples. It is concise yet informative, front-loading the main purpose and then providing details. 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 the single optional parameter, the lack of annotations, and the presence of an output schema, the description is comprehensive. It covers purpose, filtering, omitted fields, return format, and provides examples, leaving no significant 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?

The input schema has 0% description coverage, so the description compensates by explaining the app_id parameter: 'Optional app (bundle) ID to filter provisioning profiles (e.g., com.example.app).' This adds meaning beyond the type definition.

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's purpose: to get provisioning profiles for the organization, with optional filtering by app ID. It uses specific verb+resource and distinguishes from siblings which target other entities like bundle identifiers, build profiles, etc.

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 retrieve provisioning profiles) and provides filtering guidance via the app_id parameter. It doesn't explicitly state when not to use it, but sibling tool names imply different resource types, making usage context clear.

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

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

No annotations provided, but the description fully discloses behavior: it is a read operation, returns profile data excluding signedCertThumbPrint, and details error response format. 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?

Well-structured with first sentence giving purpose, followed by structured Args, Returns, and Examples. Slightly redundant (mentions signedCertThumbPrint exclusion twice), but overall clear 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?

Given the tool's complexity (4 params, pagination, output schema exists), the description covers all necessary aspects: parameter details, return envelope, error handling, and examples. References external docs for standard envelope.

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 0%, but the description provides comprehensive meanings for all 4 parameters: platform_type (enum), profile_id (UUID), page and size with defaults and capping. This adds significant value 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?

Clearly states it gets a single publish profile by platform type and ID, with optional app versions pagination. Distinguishes from sibling get_publish_profiles (which would list all).

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

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

Explains when to use (get specific profile by ID and platform) and includes pagination guidance. However, it does not explicitly state when not to use or list 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?

No annotations are provided, so the description carries full burden. It discloses behavioral traits like pagination, filtering, default parameter values, and capping. It does not mention side effects or authorization, but as a read-only tool, this is acceptable. A score of 5 would require explicit statements about non-destructiveness or rate limits.

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

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

The description is well-structured with Args, Returns, and Examples sections, making it easy to parse. It is comprehensive but slightly verbose; some information (e.g., full list of return fields) could be shortened given the output schema. Still, 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 presence of an output schema, the description need not fully explain return values, but it does. It covers pagination metadata, filtering, and provides multiple examples. For a tool with 4 parameters and complex pagination, this is thorough and 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 coverage is 0%, so the description adds all parameter meaning. It explains platform_type as an enum, page as 1-based, size bounds (1-100 capped at 100), and flow_status with allowed integer codes. It provides default values and behavior, significantly enhancing understanding beyond the 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 explicitly states 'Get publish profiles for the current organization for a given platform type (paginated)', clearly indicating the action, resource, and scope. It distinguishes from sibling tools like get_publish_profile_details (singular) and other profile-related 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 provides clear context for usage: 'for a given platform type' and pagination details. Examples show typical use cases. However, it does not explicitly compare to alternatives or state when not to use this tool, which would elevate it to a 5.

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

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

With no annotations, the description must disclose behavioral traits. It does so by detailing pagination behavior, default page size, filter effects, and the response envelope structure. It does not mention any side effects or permissions, but as a read-only report retrieval, the transparency is adequate.

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 with sections (intro, args, returns, examples) and uses clear language. It is somewhat verbose (e.g., repeated mention of pagination), but every sentence provides value. The structure aids 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?

Given the presence of an output schema (external), the description covers the key usage aspects: pagination, filtering, and response envelope. It includes examples for common cases (no filters, date range, status filter). It does not explain edge cases or behavior with invalid parameters, but overall it is sufficient for correct invocation.

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

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

Schema description coverage is 0%, so the description carries the full burden. It provides clear descriptions for all 7 parameters, including format examples for dates, allowed integer values for status (with mapping), and pagination parameters (page, size). This adds significant meaning beyond the bare schema.

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

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

The description clearly identifies the tool as retrieving a publish resign report with optional filters. It states the resource ('publish resign report') and action ('get'). However, it does not explicitly distinguish this report from sibling report tools (e.g., get_build_history_report), leaving the agent to infer when to use this specific report.

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 guidance on parameter usage and pagination, including examples for different scenarios. However, it lacks explicit instructions on when to choose this tool over alternatives among the many sibling report tools. No 'when not to use' or prerequisite conditions are stated.

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

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

No annotations provided, so description carries full burden. Discloses pagination, default page size, date range behavior, status codes, and return envelope structure. Lacks mention of auth or rate limits, but adequate.

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?

Well-structured with distinct sections for purpose, args, returns, and examples. Each sentence adds value; 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?

Covers all parameters, return envelope, and includes examples. No missing essential details given the presence of output schema. Could mention sibling tools but not required for basic 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?

Schema has 0% description coverage; the description provides full parameter details including formats, defaults, allowed values (status codes), and examples, adding significant meaning beyond 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 retrieves a 'publish status report' with optional filtering. It does not explicitly differentiate from sibling get_* tools, but the resource name is specific enough.

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 (retrieve report, filter) and behavior without filters, but does not guide against using it for other reports or mention alternatives among siblings.

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

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

The description discloses pagination behavior (default size=50, use page), date range handling, filtering by organization/OS/build status, and references the return envelope. Examples illustrate behavior. No annotations exist, so burden is fully met.

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 with sections (general, important note, args, returns, examples), front-loaded with purpose, and every sentence adds value. No wasted text.

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

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

Given 7 parameters, no required ones, and an output schema reference, the description covers all aspects: purpose, filters, pagination, return format, and examples. It is fully self-contained for 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 0%, but the description compensates fully with a detailed 'Args:' section: includes format for dates, allowed values for os, build_status numeric mapping, and page/size defaults. This adds essential 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 identifies the verb 'Get' and resource 'signing report', with 'optionally filtered by date range and other parameters' adding specificity. It distinguishes from sibling tools by focusing on the signing report aggregation.

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 call without filters ('returns every item') and lists supported filters, providing clear context. However, it does not explicitly 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?

Despite no annotations, the description fully discloses behavioral traits: it returns profile details and paginated app versions, excludes signedCertThumbPrint, and describes the return envelope (success/error structure).

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 with a purpose sentence, bullet-like Args/Returns/Examples sections. Every sentence adds value 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?

Given the existence of an output schema and the description's thorough coverage of purpose, parameters, and return behavior, the tool is fully specified for an agent to select and invoke correctly.

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

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

With 0% schema description coverage, the description compensates fully by detailing each parameter: profile_id as UUID, page as 1-based default 1, size as 1-100 default 25 capped at 100.

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 retrieves a single enterprise app store profile by ID with optional app versions pagination. It distinguishes from sibling tools like get_store_profiles (which likely lists profiles) by specifying 'single profile' and 'by ID'.

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 parameter usage (page, size, defaults, constraints) and examples, but does not explicitly mention when to use this tool versus alternatives like get_store_profiles or other detail endpoints.

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?

No annotations are provided, so the description carries the full burden. It explains pagination, parameters, and return format, but does not explicitly state that the tool is read-only, safe, or any authentication/rate limit details. For a list tool, the safety is implicit but not explicit.

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 with clear sections for purpose, arguments, return format, and examples. 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 has 2 parameters, a paginated list response, and an output schema exists, the description is mostly complete. It explains the return envelope and gives examples. However, it does not mention if the list is ordered or any implicit limits on page number.

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 0%, but the description fully explains both parameters (page and size) including defaults, constraints (size capped at 100), and usage examples. This adds significant value beyond the empty 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 gets enterprise app store profiles for the current organization, paginated, and returns IDs, names, and configuration details. It also notes it does not support search filtering, which helps distinguish it from potential sibling tools that might offer search.

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 'This tool does not support search filtering,' which tells the agent when not to use it. However, it does not name an alternative tool for filtered searches, leaving some ambiguity.

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?

No annotations provided, so description carries full burden. Discloses it is a read operation and describes return format and error envelope. However, lacks mention of permissions, rate limits, or potential side effects.

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

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

Well-structured with sections (Args, Returns, Examples). Front-loaded with core purpose. Concise but could omit redundant 'Returns' section or merge with Examples.

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 output schema exists, description still provides full details on return envelope and data fields. Includes example usage. Sufficient for an agent to correctly 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?

Description adds meaning beyond schema by explaining each parameter's purpose and format (UUID). Schema has 0% description coverage, so description compensates well.

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 'Get a single workflow' by specific IDs. Distinguishes from sibling tools like get_build_profile_workflows (which lists workflows) and get_build_profiles (which gets profile list).

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 (to retrieve a single workflow by profile and workflow ID). Does not mention when not to use or alternatives, but context with siblings implies the differentiation.

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