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

There are no annotations, so the description must disclose behavior on its own. It reveals that a .mobileprovision file is downloaded, but does not state where it is written when dest_path is null, whether existing files are overwritten, or what signing/authentication requirements apply. This leaves key runtime effects unstated.

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

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

The description is one short sentence and all words carry meaning, making it easy to parse. It could have added behavior or destination details without becoming bloated, so it is concise rather than complete.

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

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

For a two-parameter file-download tool with no annotations and no output schema, the description lacks essential context: what happens without dest_path, whether the file is returned as content or saved, and what the response contains. It is minimally viable but leaves an agent guessing on core calling behavior.

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

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

Schema description coverage is 0%, so the description must compensate, but it only covers profile_id via 'by id.' It does not explain dest_path semantics, the default output location, or accepted file naming. The parameter names are reasonably self-describing, but no added meaning is given.

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

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

The description states a clear action and target: 'Download a provisioning profile (.mobileprovision) by id.' It identifies the resource and the unique key, but does not explicitly distinguish itself from other signing-related siblings such as asc_list or signing_inspect, leaving a small ambiguity about where listing ends and downloading begins.

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

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

No guidance is provided for when to prefer this tool over alternatives such as asc_list or signing_inspect. An agent is not told prerequisites like profile existence or authentication, and no exclusion conditions are given, so it must infer relevance from the tool name alone.

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 burden of behavioral disclosure. It indicates that this is a mutating operation that changes the app's entitlements, and it directs the user to run signing_quick_setup afterwards to regenerate profiles. This adds useful behavioral context beyond the basic action.

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, front-loads the action and examples, and ends with a crucial follow-up instruction. 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?

The description is sufficient for an agent to understand the tool's purpose and prerequisites, but it lacks details on return values or error handling, which could be important for a state-changing operation. However, without an output schema, the description's coverage is 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 0%, but the description provides examples for the 'capability' parameter (e.g., PUSH_NOTIFICATIONS, ASSOCIATED_DOMAINS) and indicates that 'identifier' is the bundle id. This compensates for the schema's lack of 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 action ('Enable a capability') and the target resource ('bundle id'), with examples of capabilities. It distinguishes from siblings like signing_quick_setup by noting the need to recreate profiles, but doesn't explicitly name which sibling to use for that follow-up.

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 (to enable a capability on a bundle id) and includes a post-requisite (recreate profiles with signing_quick_setup). However, it doesn't explicitly state when not to use it or mention alternatives for related operations.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'List', which implies a read operation, but it does not disclose pagination, filtering, output format, or whether the list is exhaustive. It also does not clarify whether this tool covers both App Store Connect and Developer Portal resources or only one of them, despite the description mentioning both.

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 short sentence with no wasted words. It is front-loaded with the verb and resource. However, it is so terse that it sacrifices useful detail, which is a minor structural issue.

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

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

The tool has an output schema, so return values are likely covered there, but the description does not explain the scope of the listing, the meaning of the resource enum, or how this tool relates to the many sibling tools. For a tool with no annotations and a single enum parameter, the description should at least enumerate the resource types or point to the schema. It is minimally adequate but leaves an agent guessing about the tool's exact role.

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%, but the single parameter 'resource' has a clear enum that fully defines its allowed values. The description adds minimal semantic value beyond the schema, merely saying 'resources' without mapping to the enum values. Since the enum is self-explanatory and there is only one parameter, 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 states a verb ('List') and a resource ('App Store Connect / Developer Portal resources'), but it is vague about what 'resources' means. The schema's enum clarifies the specific resource types, but the description itself does not enumerate them or distinguish this tool from the many sibling tools that also operate on App Store Connect resources.

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

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

The description provides no guidance on when to use this tool versus alternatives. Sibling tools like asc_register_bundle_id, asc_enable_capability, asc_register_device, asc_revoke_certificate, and asc_download_profile all relate to App Store Connect resources, but the description does not explain that asc_list is for read-only listing while those are for mutations. An agent must infer usage from the tool name and schema.

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?

There are no annotations, so the description carries the full behavioral burden. It states that the tool 'registers' an App ID, but it does not disclose side effects, duplicate failures, permissions/authentication requirements, or any post-registration behavior. For a mutation-like portal operation this is a significant gap.

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 one front-loaded sentence with no filler. It could earn a 5 if it added a usage note, but it remains appropriately concise for a two-parameter tool.

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

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

With no annotations and no output schema, the description should provide more operational context. It does not mention what happens on duplicate App IDs, whether name is truly optional, or what the API returns after registration, so the agent has to guess at the call's contract.

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%, and the description only clarifies 'identifier' as a bundle identifier. It does not explain the optional 'name' parameter, its default, or how it affects registration, leaving almost all semantic weight on the schema titles.

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 ('Register') and object ('explicit App ID (bundle identifier)') and scopes it to the Apple Developer portal, which cleanly identifies what the tool does. This also differentiates it from sibling tools like asc_register_device or asc_enable_capability by naming the exact resource type.

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 Apple Developer portal context implies when to use it, but the description provides no explicit guidance about when to choose this tool over alternatives such as asc_register_device or asc_list. Usage is inferable from the bundle-identifier wording, but exclusions and prerequisites are absent.

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?

There are no annotations, so the description carries the behavioral burden. It discloses a key behavior: with no udid, the tool uses the USB-connected device and requires pymobiledevice3. However, it does not mention authentication requirements, side effects of registering a device, or what happens on failure.

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 concise sentences, front-loading the core purpose and then adding the conditional USB behavior. Every sentence earns its place with no filler or repetition.

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

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

For a tool with two optional parameters and no output schema, the description is largely complete: it states the purpose, the primary invocation path, and a prerequisite. The main omissions are name semantics and expected result/error behavior, but they are not critical for a low-complexity registration 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 0% description coverage, so the description must compensate. It adds meaningful semantics for udid by explaining that omitting it triggers USB-device detection, but it does not explain the name parameter at all, leaving the parameter semantics only partially clarified.

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

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

The description uses a specific verb and resource: 'Register an iPhone for ad-hoc/development builds.' This clearly distinguishes the tool from sibling registration tools like asc_register_bundle_id and device_install_app, while also conveying the intended 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 clear usage context: it registers an iPhone for ad-hoc/development builds, and states the conditional behavior that with no udid it uses the USB-connected device. It also names the dependency pymobiledevice3, which is useful prerequisite guidance, though it does not explicitly name 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?

There are no annotations, so the description carries the burden of disclosing side effects. It states that profiles using the certificate become invalid and that App Store apps are unaffected, which is important behavioral context. It does not mention irrevocability or required permissions, but the main consequences of revocation are covered.

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 tight sentences with no filler. The action is front-loaded, followed by the key use-case and side effects, so every part 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 one-parameter revocation tool with no output schema and no annotations, the description covers the purpose, trigger, and consequences adequately. The main missing pieces are an explicit pointer to asc_list for retrieving certificate_id and clarification about whether revocation can be undone.

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 one required parameter, certificate_id, with 0% schema description coverage, and the description adds no information about it. The name is somewhat self-explanatory, but the description does not say where to obtain the ID or whether any format is expected, so it fails to compensate for the missing schema documentation.

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 specific verb and resource: 'Revoke a signing certificate.' The parenthetical 'frees a slot when Apple's certificate limit is hit' adds distinguishing context, and it is clearly different from related siblings like asc_list or signing_inspect, which list or inspect rather than revoke.

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

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

The description gives a concrete trigger for when to use the tool: when Apple's certificate limit is hit and a slot needs to be freed. It does not explicitly name alternatives or say when not to use it, but the context is clear enough for an agent to route correctly.

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

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

With no annotations, the description carries the burden of behavioral disclosure. 'Show' clearly indicates a read-only status operation, and the list of backends defines scope. However, it does not explain how the status is determined (e.g., local configuration vs live connectivity checks) or whether any authentication or side effects are involved.

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, front-loaded sentence with no filler or repetition. Every word contributes to clarifying what the tool reports.

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 status tool, the core purpose is conveyed, but the description omits any explanation of the optional project_path parameter and offers no usage guidance relative to sibling diagnostic tools. The lack of an output schema makes some return-value ambiguity acceptable, but the parameter gap remains.

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

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

The schema has one parameter, project_path, with zero description coverage, and the tool description never mentions it. An agent cannot tell whether project_path is required, what it should point to, or what happens when it is null. The description adds no meaning beyond the raw schema field name.

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 a specific verb ('Show') and a specific resource (backend configuration status), enumerating the exact backends covered: GitHub CI, App Store Connect, remote Mac, and USB device. It also tells the agent what output to expect (what is configured and what is missing), distinguishing it from the action-oriented 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?

The description implies a diagnostic use case but provides no explicit guidance on when to use this tool versus alternatives such as ios_doctor or mac_doctor. It does not state prerequisites, exclusions, or conditions under which another tool should be preferred.

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, but it only states the high-level action. It does not disclose side effects (e.g., terminating jobs, marking as failed), whether the operation is asynchronous, idempotency, permission requirements, or behavior when the run is already completed. This is a significant gap for a mutation tool.

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

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

The description is a single clear sentence with no wasted words, but it is extremely terse. It is concise without being complete; while it earns its place, it under-delivers on essential context that other dimensions penalize.

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

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

For a tool with three parameters, no annotations, and no output schema, the description is insufficient for an agent to invoke it correctly with full confidence. It lacks parameter semantics, cancellation edge cases, and behavioral details, leaving an agent to guess at important constraints.

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% and the description does not compensate by explaining any parameters. run_id is required but its meaning as a CI run identifier is only inferable from the name. The optional repo and project_path parameters are ambiguous—likely repository context, but the description gives no guidance on their purpose or whether they are needed.

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

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

The description clearly states a specific verb ('Cancel') and resource ('a running workflow run'), which distinguishes it from sibling tools like ci_trigger_build, ci_wait_for_run, and ci_get_logs by the action it performs. No ambiguity about what the tool does.

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 alternatives, such as when a run should be stopped, whether it can cancel non-running runs, or what to do if cancellation fails. There are no exclusions, prerequirements, or sibling comparisons.

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 must carry the full burden of behavioral disclosure. It mentions 'download and unzip' and the default destination, but it does not disclose whether it can overwrite existing files, what happens if the run has no artifacts, whether it requires network/auth, or the structure of the unzipped output. It also lacks information about return values or 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 a single sentence, front-loaded with the key action and artifact types, and immediately states the default destination. It is concise with zero waste, making it easy for an agent to parse quickly.

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 moderate complexity (4 params, no output schema, no annotations), the description provides the essential purpose and destination but misses important context such as error scenarios, prerequisites (e.g., run must be completed), and whether the tool handles directory creation. It is adequate for basic use but lacks depth.

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 compensate. It explicitly mentions the default destination, which clarifies the 'dest_dir' parameter's meaning and the output structure. However, it does not explain 'repo', 'project_path', or 'run_id' beyond what is obvious from their names, and the schema provides only titles, so the description adds some value but not full coverage.

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

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

The description clearly states the action ('Download and unzip'), the resource ('a run's build outputs'), and specifies the output types (IPA / simulator .app.zip), making it obvious what the tool does. It also distinguishes itself from sibling tools like ci_get_logs which fetch logs, not artifacts.

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 it (to obtain build artifacts) but does not explicitly state when not to use it or mention alternatives. Siblings like ci_get_logs exist for logs, but the description does not contrast with them. This leaves some ambiguity but is still clear enough for most agents.

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 behavioral burden. It does disclose the main side effect—writing files into the repo—and the default behavior of pinning the local Flutter version. However, it omits other behavioral details such as whether an existing workflow file is replaced by default, what the signing helper script does, or whether secrets are required.

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 dense sentences lead with the concrete file path, then summarize build modes and the default Flutter version behavior. Every sentence contributes information with no filler 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?

Five optional parameters, no output schema, and no annotations mean the description must provide substantial context, but it covers only the high-level purpose and one default behavior. An agent cannot confidently determine how to set `project_path`, `runner`, or `overwrite` from the description alone.

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 must compensate, but it only lightly hints at Flutter version matching. The meanings of `runner`, `overwrite`, `project_path`, and `flutter_version` are left unexplained, leaving the agent to guess at valid values and effects.

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

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

The description names a specific artifact it writes, `.github/workflows/flutter-ios-bridge.yml`, plus a signing helper script, and enumerates the build outputs it supports. This clearly differentiates it from siblings like `ci_trigger_build` or `mac_build`, which execute builds rather than generate CI 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 gives no explicit when-to-use guidance or alternatives, and it does not mention prerequisites such as an existing Flutter project or GitHub repo. Context like the build runner and output types is useful, but the agent must infer when this tool should be chosen over the many CI/signing 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?

With no annotations, the description carries the transparency burden.me description does disclose meaningful behavior: it fetches logs and extracts specific error lines plus the tail. However, it does not describe the output format, whether raw logs are returned, auth requirements, or how the only_failed and tail_lines parameters affect 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?

The description is a single, tightly written sentence that front-loads the primary action ('Fetch the job logs of a run') and then adds the useful processing detail in a compact clause. There is no filler or redundant 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?

Given five parameters, no annotations, and no output schema, the description is somewhat thin. It is enough for a default-parameter call with run_id, but it does not explain the output shape, parameter roles, or when repo/project_path are needed, leaving gaps for robust agent use.

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

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

Schema description coverage is 0%, and the description does not define any parameter by name. It only hints at 'log tail' and 'error lines' which loosely map to tail_lines and only_failed, but run_id, repo, and project_path semantics are left entirely to inference from their schema titles.

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

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

The description states a clear verb and resource: 'Fetch the job logs of a run', plus the additional filtering/processing behavior of extracting Xcode/CocoaPods/Flutter error lines and a log tail. This distinguishes it from run-list and run-waiting siblings, though it does not explicitly name a sibling alternative.

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 intended use case is implied: obtain job logs or errors for a CI run. However, the description provides no explicit when-to-use or when-not-to-use guidance, and does not mention alternatives such as ci_wait_for_run or ci_download_artifacts.

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 indicates a read-only 'list' operation, but it does not state that no runs are triggered or modified, nor does it clarify ordering, filtering behavior, or limit semantics beyond the schema default.

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, front-loaded sentence with no filler or repetition. Every word contributes to the basic purpose, making it easy to scan and parse.

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?

An output schema exists, so return-value documentation is not required from the description. However, with no annotations, no parameter explanations, and no usage context, the description is incomplete for an agent to correctly scope and invoke the tool across varied CI workflows.

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%, and the description does not explain any of the three parameters (repo, limit, project_path). The phrase 'iOS workflow' gives only weak context about project_path, so the agent receives no meaningful parameter semantics beyond parameter names.

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

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

The description states a clear action and resource: 'List recent runs of the iOS workflow.' This is specific enough to distinguish from siblings like ci_trigger_build, ci_cancel_run, and ci_get_logs, though it does not explicitly name an alternative.

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?

There is no guidance on when to use this tool versus alternatives such as ci_wait_for_run or ci_get_logs. The description does not mention prerequisites, typical call order, or exclusions, leaving the agent to infer usage from the tool name alone.

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 discloses the write behavior (uploading secrets), client-side encryption, and the include_asc_key conditional. However, it does not mention authentication requirements, whether existing secrets are overwritten, or how ASC key values are supplied, so the behavioral picture is incomplete.

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 the key action and destination front-loaded, followed by a compact list of secrets and the one conditional. No filler or redundant restatement of the parameter schema.

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

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

Although the surface purpose is clear, the invocation context is missing: repo is optional with no guidance, project_path is unexplained, and the source of ASC_KEY_ID/ASC_ISSUER_ID/ASC_PRIVATE_KEY is not described despite them being referenced. With no output schema or annotations, a caller cannot fully determine prerequisites or behavior.

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

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

Schema description coverage is 0%, so the description must compensate. It does map the main inputs to destination secrets (P12/PASSWORD/PROFILE_BASE64) and explains the include_asc_key flag, but repo and project_path remain unexplained and their role is left to inference.

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

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

The description opens with a specific verb and resource ('Upload signing material to the repo's GitHub Actions secrets') and enumerates the exact secret names, with a conditional for ASC keys. It also distinguishes itself from the sibling signing_quick_setup by noting it accepts .p12 files exported from anywhere.

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

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

The description gives clear context: it is for installing signing material into GitHub Actions secrets and is not limited to files produced by signing_quick_setup. It does not spell out explicit when-to-use/when-not-to-use rules, but the contrast with the sibling tool is implicit and useful.

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 behavioral burden. It discloses that the build uses pushed content at ref (not local state), returns a run id (implying asynchronous execution), and names the secret dependencies for certain configurations. It omits side effects like CI consumption but is not misleading.

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 filler: the core behavior, the source of truth, the return value, and the key conditional requirements are all conveyed. The most important fact 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?

For an all-optional-parameter trigger tool, the description covers the critical inputs and return value, and sibling tools like ci_list_runs/ci_get_logs implicitly cover monitoring. But with no annotations, no output schema, and no schema descriptions, it leaves several parameters and the async lifecycle only partially specified.

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 must compensate. It explains the meaning of ref and ties signing secrets to build_type/testflight, but repo, build_name, build_number, project_path, and export_method are left to name/enum inference only.

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 a specific action ('Start an iOS build on GitHub Actions') and the resource it affects. It is distinct from the local mac_build sibling by specifying GitHub Actions, but it does not explicitly name or contrast any sibling, so it stays at 4 rather than 5.

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

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

It gives useful context: the build is based on the pushed ref, and signed-ipa/testflight have secret prerequisites. However, it never states when to choose this tool over alternatives such as mac_build or ci_generate_workflow, nor does it provide exclusions.

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 discloses that the call blocks up to timeout_seconds, can be repeated, and returns status and per-step results. It does not explain what happens on timeout, whether the call is idempotent, or how polling behaves, so the disclosure is helpful but incomplete.

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 filler. The core behavior is front-loaded, and the practical timing guidance earns its place without bloating the description.

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

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

For a wait operation, the description covers the main behavior and intended usage pattern, but the lack of annotations and output schema leaves gaps around timeout behavior, parameter meaning for non-obvious fields like poll_seconds, and the exact structure of the returned per-step results.

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 needed to compensate. It only interprets timeout_seconds ('up to timeout_seconds'); run_id, poll_seconds, repo, and project_path remain unexplained. This leaves most of the 5-parameter surface undocumented.

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

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

The description states a clear verb and resource: wait for a run to finish and return status plus per-step results. It does not explicitly compare against sibling tools like ci_list_runs or ci_get_logs, but the wait/results purpose 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?

It tells agents to call repeatedly for long builds and gives a concrete duration expectation for iOS builds, which is useful guidance. It does not explicitly spell out when not to use it or name alternatives, but the repeated-call instruction conveys the intended usage pattern.

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 carry the behavioral burden. It implies a read operation by naming output fields, but it does not explicitly state whether it only reads device state, what happens with no UDID, or whether a device must be connected before calling.

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

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

The description is compact and front-loads the key return values with no filler. However, it is a fragment rather than a full operational sentence, which slightly limits clarity.

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

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

For a simple one-parameter tool with no annotations or output schema, the description should clarify the action, the parameter's purpose, and any device connection requirements. It covers none of these, so an agent would struggle to invoke it correctly.

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

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

The single 'udid' parameter is optional and has 0% schema description coverage. The description mentions UDID as an output field but does not explain how it functions as an input parameter or what passing null versus a string does.

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 indicates the tool returns device information (model, iOS version, UDID) for a connected device. It lacks an explicit verb like 'get' or 'return', but the noun phrase is unambiguous and distinct enough from vague 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?

There is no guidance on when to use this tool versus alternatives such as device_list or ios_doctor. No context, preconditions, or exclusions 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?

With no annotations, the description carries the full burden. It adds a meaningful prerequisite (the .ipa must be signed with an ad-hoc or development profile that includes the device), which is beyond the name alone. However, it does not disclose failure modes, side effects, whether an existing app is overwritten, or any permissions needed—leaving notable behavioral gaps.

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, tightly written sentence with no filler or redundancy. It front-loads the verb and direct object, and every phrase adds relevant information (signed, ad-hoc/development, includes this device, connected iPhone).

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 is a mutation operation with no annotations, no output schema, and two parameters, the description is under-specified. It does not explain the udid parameter, nor does it offer guidance on how to target a specific device when multiple are connected. The signing requirement is helpful, but the overall context is incomplete 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 must compensate for parameter meaning. It clarifies ipa_path by referencing 'a signed .ipa' but says nothing about the udid parameter, which is critical for selecting among multiple connected devices and is not self-evident from the schema (null default). This is a significant omission.

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 ('Install') and resource ('a signed .ipa ... on a connected iPhone'), clearly distinguishing this from siblings like device_uninstall_app (uninstall) and mac_install_simulator_app (simulator target). The target platform and installation artifact are 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 clearly implies when to use the tool (installing an .ipa on a physical, connected iPhone) but does not explicitly state alternatives or exclusions, such as 'use mac_install_simulator_app for simulators' or 'use device_uninstall_app to remove an app.' The usage context is forward but not fully explicit.

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

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

With no annotations present, the description carries the behavioral disclosure burden. It states exactly what is listed and over which transports, and 'List' implies a non-mutating read operation, giving the agent a clear expectation of no side effects. It does not mention minor caveats like device authorization/trust prompts, but for a simple enumeration tool this is sufficient.

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?

A single sentence that is front-loaded with the action ('List') and resource, followed by the connection scope. Every word earns its place and there is no fluff or repetition.

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

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

For a zero-parameter tool with an output schema, the description provides the essential operational context: what is being listed, how the devices connect, and on which host OS. It is complete enough for an agent to select and invoke it correctly, though it could be slightly stronger with a note about expected return data.

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

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

The tool has zero parameters, so the baseline of 4 applies. The description adds no parameter-level details, but none are needed; the agent can invoke the tool without any arguments.

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 ('List') and a clear resource ('iPhones/iPads connected over USB/Wi-Fi') with a host context. It clearly differentiates from sibling tools like device_list_apps or device_info by focusing on connected devices rather than installed apps or device metadata.

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 makes the tool's purpose obvious but provides no explicit when-to-use or when-not-to-use guidance. It does not name alternatives or conditions, leaving the agent to infer that this is the device-enumeration step from the verb and context alone.

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 burden of behavioral disclosure. It does communicate an important scope constraint by saying 'user-installed' rather than all apps, and implies a read-only listing operation. However, it does not disclose how the udid selects a device, what happens if multiple devices are connected, or whether system apps are excluded beyond the qualifier.

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 one short, front-loaded sentence with no filler or repeated information. It earns its place by adding the 'user-installed' scope and device target without 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?

The tool is simple with a single optional parameter and an output schema, so the missing return-value detail is less critical. However, the complete absence of parameter semantics and sibling routing leaves the description only minimally viable for an agent deciding how to invoke it.

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

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

Schema description coverage is 0% and the description never mentions the only parameter, udid. The agent gets no explanation of what udid is for, whether it defaults to a single connected device, or how it affects the result list. This is a complete gap for the sole parameter.

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

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

The description states a specific action and resource: 'List user-installed apps on the connected device.' It clearly identifies the tool as an app-enumeration operation and distinguishes it from nearby device tools like device_list or device_info, though it does not explicitly name any sibling alternatives.

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?

There is no guidance on when to use this tool versus alternatives such as device_list, device_info, or device_install_app. The description does not mention prerequisites, device connection requirements, or any conditions that would make another tool more 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?

With no annotations, the description carries the behavioral burden. It discloses the time limit (max 120 seconds) and optional filtering, but says nothing about output format (returned text? saved file?), whether it requires a connected device, or any side effects beyond capture. This is some value but incomplete.

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, zero wasted words. The core action, limits, and filters are front-loaded, and the second sentence adds a concrete usage tip. Excellent economy.

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 the clear purpose, the description lacks essential operational details: what does the tool return (logs inline, file path?), what is the default udid behavior, and what are the process default ('Runner') and seconds default (15). Without an output schema, the agent cannot anticipate the tool's response. This is a meaningful gap.

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

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

Schema description coverage is 0%, so the description must compensate. It explains 'filtered by text or process name' (match, process) and 'N seconds' (seconds), but omits 'udid' entirely. With 4 parameters and 3 partially explained, this earns a 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 states a specific action ('Capture the device syslog'), the resource ('device syslog'), and key modifiers (duration, filters). It clearly distinguishes from simulator log tools like mac_simulator_logs by specifying 'device'.

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 practical usage context: 'Launch the app on the phone while this runs to catch crash reasons.' It implicitly tells when to use (debugging crash reasons) but does not explicitly mention alternatives or when not to use, which costs one point.

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 of behavioral disclosure. 'Uninstall' implies destructive mutation, but the description does not mention irreversibility, permission requirements, effects on app data, or failure modes if the app is absent.

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 single sentence is free of fluff and front-loaded with the action, but it is too under-specified to be considered appropriately sized for a tool with zero parameter documentation.

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

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

The tool has no annotations and no output schema, so the description must compensate. It fails to explain key operational details like which device is targeted, how bundle_id is used, and what happens after uninstall, making it incomplete for reliable agent invocation.

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

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

Schema description coverage is 0%, and the description does not explain either parameter (udid, bundle_id). An agent gets no help mapping 'app' to bundle_id or understanding the optional udid's role, leaving the schema titles as the only guidance.

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

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

States a specific verb ('Uninstall'), resource ('app'), and context ('connected device'). Clearly distinguishes from siblings like device_install_app and device_list_apps by naming the inverse 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?

Provides no guidance on when to use this tool versus alternatives, nor any prerequisites such as the app being installed or a device being connected. The intended use is only implied by the tool name and sibling set.

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

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

No annotations are present, so the description carries the full burden. It discloses that the audit works without Xcode and that results are returned as issues sorted by severity with fixes, which is useful. However, it does not explicitly state that the tool is read-only and does not modify the project, and it is silent on whether any network access, authentication, or environment prerequisites are needed.

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

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

The description is dense and front-loaded with the core action and constraint, then packs a precise list of audit areas into one sentence. It avoids filler and each phrase adds specificity, though the long single-sentence list could be slightly easier to scan if split into short bullet-like clauses.

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?

There is no output schema, but the description does communicate the return shape: issues sorted by severity with fixes. It also names all major audit domains, making the tool's scope clear. It could be more complete about return format and side effects, but for a diagnostic tool with one optional parameter, the essential context is present.

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 should compensate, but it never mentions project_path, its meaning, default behavior, or how it relates to the project root. The schema only provides a title and nullable default, which is thin. For a single self-explanatory parameter this is a moderate gap, but still below the bar set for low-coverage schemas.

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 ('Audit') with a clear resource ('ios/ side of a Flutter project without Xcode') and enumerates concrete check items (bundle id, Info.plist usage strings, deployment target, icons, launch screen, privacy manifest, Firebase config, entitlements). This clearly distinguishes it from sibling tools like ios_set_info_plist_value or ios_get_build_settings, which are mutation/retrieval tools rather than a holistic audit.

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 as a diagnostic audit step before iOS build/release actions, but it never explicitly states when to prefer this over mac_doctor or the individual ios_get_* inspection tools. There are no exclusions or alternative routing, so the agent must infer the appropriate context from the audit-oriented wording.

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 disclosure burden. It transparently states 'Read', signaling a non-mutating operation, which is the most critical safety trait. However, it does not disclose the output format, the meaning of a null project_path, or potential failure modes, leaving notable behavioral gaps.

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, front-loaded sentence with no filler. It starts with the core action and object, lists representative settings, and adds the Podfile scope at the end. Every word contributes to understanding the tool's function.

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

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

For a simple read tool with one optional parameter, no annotations, and no output schema, the description covers the primary purpose but omits the return structure, default behavior when project_path is null, and any error conditions. It is adequate for basic use but leaves an agent uncertain about what to expect from 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?

The input schema provides no description for project_path (0% coverage), and the tool description does not explicitly explain the parameter's format, whether it should point to a directory or file, or what a null value does. The mention of 'from project.pbxproj' hints that the path targets an Xcode project, but this is insufficient to fully compensate for the absent schema documentation.

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 'Read' with a specific resource ('key Xcode build settings from project.pbxproj') and lists example fields (bundle ids, deployment target, team, signing style) plus the Podfile platform. This clearly distinguishes it from sibling write tools like ios_set_bundle_identifier and from ios_get_info_plist, which reads a different file.

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 conveys a clear context: use this tool to retrieve build settings and the Podfile platform, likely before modifying them. It implies but does not explicitly state when to use it versus alternatives, and it offers no exclusions or when-not-to-use guidance. This is clear contextual guidance without explicit routing.

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

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

No annotations are provided, so the description carries the full burden. It indicates a read operation (non-destructive), but does not disclose details such as whether the tool returns the entire plist as a dictionary, what happens if the file does not exist, or whether it respects standard iOS configuration. This is insufficient for an unannotated 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 a single short sentence that is front-loaded with the core action and optionality, with no unnecessary words. It earns its place perfectly.

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 (read a plist, optionally filter keys), the description covers the main usage but lacks edge-case handling (missing file, invalid keys) and does not specify return value structure (though no output schema is present). With no annotations, a bit more detail on error behavior would improve completeness, but for a read tool this is 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 description coverage is 0%, so the description must explain parameters. It mentions 'optionally only the given keys', which implies the 'keys' parameter filters output, but it does not explicitly describe 'project_path' or the format of keys. However, the minimal parameter count (2) and the description's hint partially compensate; a 4 is reasonable for the limited information given.

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 a specific action ('Read') on a specific resource ('ios/Runner/Info.plist') and mentions optional key filtering, distinguishing it from siblings like ios_set_info_plist_value and ios_remove_info_plist_key which mutate the file. It is concise and unambiguous.

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

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

The description implies this tool is for reading the Info.plist, and the sibling set includes modifiers (ios_set_info_plist_value, ios_remove_info_plist_key) but no explicit guidance on when to choose this over alternatives. It does not state exclusions or prerequisites, but the purpose is clear enough for an agent to infer usage in a read 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?

The description correctly signals a destructive delete operation and names the exact target file, which is useful. However, with no annotations available, it does not disclose behavior like failure on missing keys, irreversibility, or potential side effects on the project.

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?

One short sentence with zero filler. The core action and target are stated directly 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 simple two-parameter tool this is adequate, but it is not fully complete: there is no output schema, no annotations, no parameter descriptions, and the optional project_path behavior is undocumented.

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 must compensate. It only implicitly clarifies the purpose of the required "key" parameter and says nothing about the optional "project_path" parameter, leaving the agent to guess its meaning and default behavior.

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, "Delete", and a precise resource, "a key from ios/Runner/Info.plist". It clearly distinguishes this tool from the sibling get and set Info.plist 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 usage context is implied by the action: use this when a key should be removed from the iOS Info.plist. However, it does not explicitly mention alternatives or conditions such as preferring ios_set_info_plist_value for modification or ios_get_info_plist for inspection.

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 of behavioral disclosure. It states the mutation ('Change') and the affected targets ('Runner and RunnerTests'), but it doesn't disclose side effects, whether the change is reversible, whether it modifies other project settings, or what happens if the bundle_id is invalid. The mention of 'project.pbxproj' gives some context but not enough for a mutation tool.

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

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

The description is a single, efficient sentence that front-loads the action and target. It earns its place, though it could add a bit more context without becoming verbose.

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

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

For a mutation tool with no annotations, no output schema, and 0% schema description coverage, the description is too thin. It doesn't explain the project_path parameter, the expected format of bundle_id, or the implications of changing it. An agent would need to infer too much to invoke this tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the purpose of bundle_id implicitly ('Change the iOS bundle identifier') but doesn't describe the format or constraints (e.g., reverse-DNS, allowed characters). project_path is entirely undocumented in both the schema and description, leaving the agent to guess its meaning and default behavior.

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

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

The description states a specific verb ('Change') and resource ('iOS bundle identifier (Runner and RunnerTests) in project.pbxproj'), which clearly identifies what the tool does. It doesn't explicitly differentiate from siblings like asc_register_bundle_id, but the target file and platform make the purpose reasonably distinct.

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

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

No guidance is provided about when to use this tool versus alternatives such as asc_register_bundle_id or signing_quick_setup. The description implies usage for changing the bundle identifier in an iOS project, but it doesn't state prerequisites, context, or exclusions.

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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It does state the files that will be modified, which is useful, but it does not disclose whether changes are reversible, whether existing values are overwritten, whether the version is validated, or what side effects may occur.

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 with no filler or redundancy. It front-loads the action and resource, then lists the affected files in a compact and readable way.

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

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

Given that there are no annotations, no output schema, and two parameters with zero schema descriptions, this description is too thin. It explains the core action but leaves parameter behavior, defaults, and usage context undocumented, so an agent may not call it correctly in edge cases.

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 must compensate, but it only implicitly explains 'version' and says nothing about project_path, its optionality, or the default values. An agent cannot fully determine what project_path should point to from the description 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 uses a specific verb ('Set'), names the exact resource ('minimum iOS version'), and enumerates the precise files modified (project.pbxproj, Podfile, AppFrameworkInfo.plist). This clearly separates it from sibling tools that manipulate Info.plist keys or build settings.

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 alternatives, nor does it mention prerequisites, such as requiring an Xcode project or whether project_path must be specified. Usage context is only implied by the purpose statement.

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

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

With no annotations provided, the description must carry the full burden of behavioral disclosure. 'Set' implies a write, but there is no mention of overwriting existing keys, whether the file must already exist, potential side effects, or reversibility. The value_type list is useful but does not disclose operational consequences.

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, front-loaded with the core action, and every sentence contributes: the action, the value_type options, and a concrete example. There is no filler or redundancy.

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

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

For a tool with 4 parameters, no annotations, and no output schema, this description is not fully complete. It leaves project_path, value serialization details, and overwrite/merge behavior undefined, so an agent cannot reliably handle non-trivial calls without additional assumptions.

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 must compensate. It lists value_type options and gives one clear example, but it does not explain project_path, what 'auto' means, or how array/dict/json values should be formatted. The coverage is only partial.

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

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

The description uses a specific verb and resource: 'Set a key in ios/Runner/Info.plist.' This clearly distinguishes it from sibling tools like ios_get_info_plist and ios_remove_info_plist_key by action alone, though it does not explicitly name those alternatives.

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 usage context is implied: use this when you need to set an Info.plist key. However, it never says when not to use it or points to get/remove alternatives, so the guidance is inferred rather than explicit.

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

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

The description only states the boot action and default selection. It does not disclose what happens if the simulator is already booted, whether booting is idempotent, what side effects occur, or what the return/result looks like. With no annotations, these behavioral details are missing.

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 one tight sentence with no filler or repeated schema information. It is front-loaded with the action and then states the default behavior. It could be slightly clearer, but it 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 one-parameter tool with no output schema, the description provides enough to make a basic call. However, it leaves gaps around parameter semantics, idempotence, and behavior when no device is specified, so it is only minimally 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 description coverage is 0%, so the description must compensate, but it only hints at default behavior when the parameter is omitted. It does not explain what device_name_or_udid accepts, how matching works, or what values are valid beyond the property name.

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 and resource: 'Boot a simulator', and further clarifies the default selection (already-booted one or newest iPhone). This is specific enough to distinguish it from sibling tools like mac_run_on_simulator or mac_list_simulators.

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

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

No guidance is given on when to use this tool versus alternatives, such as mac_run_on_simulator, mac_install_simulator_app, or mac_screenshot. There are no prerequisites, exclusions, or hints about the expected workflow 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 must carry behavioral disclosure. It does disclose two useful traits: a sync occurs first by default, and the result is ok plus a tail of build output. It stops short of explaining build side effects, signing implications, or the meaning of the modes, which are material for a build 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?

Single sentence with no filler; the sync-first behavior and return shape are front-loaded in their own clauses. Every word earns its place.

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

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

The tool has four parameters, a meaningful mode enum, and no output schema, and the description does not explain the mode options or extra_args. The return note is helpful, but an agent cannot tell what simulator/no-codesign/ipa mean or how project_path affects the build, so the definition 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?

Schema description coverage is 0%, so the description must compensate. It only clarifies sync_first ('syncs first by default'); mode values, extra_args, and project_path are left undefined in both schema and description. That is insufficient for an agent to set parameters correctly without additional inference.

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

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

States the precise operation 'Build the project' on a specific target 'remote Mac' and clearly separates it from sibling tools like mac_sync_project and mac_run_on_simulator. The parenthetical about sync-first behavior and the return-value note reinforce what the tool does without ambiguity.

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

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

The use case is implied: call this when you need a remote Mac build, and the default sync behavior hints at interplay with mac_sync_project. However, it never says when to choose this over mac_run_on_simulator or ci_trigger_build, nor does it mention exclusions or 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?

With no annotations, the description carries the full behavioral burden. The verb 'Check' clearly signals a read-only diagnostic operation, and the list of checked components sets expectations. It does not mention potential side effects, network requirements, or output format, but for a no-parameter health-check tool this 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?

A single sentence that front-loads the action ('Check'), names the resource ('the remote Mac'), and then lists the specific components. Every word earns its place, with no filler or redundancy.

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

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

For a simple zero-parameter diagnostic with no output schema, the description adequately communicates scope. It omits what the result looks like and does not contrast with ios_doctor, but these are minor gaps for a straightforward health-check 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 tool has zero parameters, so the input schema completely covers parameter semantics. The baseline of 4 applies because there is nothing for the description to add about 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 uses a specific verb ('Check') with a clear resource ('the remote Mac') and enumerates exactly what is covered (macOS, Xcode, Flutter, CocoaPods, simulator runtimes). This makes it immediately distinguishable from sibling tools like ios_doctor, which target the iOS project toolchain rather than the Mac environment.

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 intended use is implied: run this when you need to know the state of the remote Mac's development environment. However, there is no explicit when-to-use or when-not-to-use guidance, and no alternative tool is named even though ios_doctor is a close sibling that could be confused with 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?

With no annotations, the description carries the full burden of behavioral disclosure. It mentions login shell and in_project, but omits important behaviors for a shell execution tool: output/exit-code semantics, timeout behavior, default working directory, environment assumptions, and the destructive potential of arbitrary commands.

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

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

The description is compact and front-loaded: the main action appears first, followed by a useful usage example. Every sentence earns its place, though the brevity leaves some critical details unaddressed.

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

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

The tool has four parameters, no output schema, and no annotations, so the description needs to be much more thorough. Only one parameter is meaningfully explained, and there is no guidance on expected output, errors, timeouts, or project_path behavior. This is insufficient for reliably invoking the tool in varied contexts.

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 must compensate for the input schema. It explains in_project and gives a helpful example, but command, project_path, and timeout_seconds are left undocumented. The parameter semantics are only partially explained.

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

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

The description clearly identifies the action ('Run a shell command on the remote Mac') and the resource, and the examples ('pod install', 'flutter test') make the intended use concrete. It does not explicitly distinguish this from sibling mac_* tools, but its broad shell-execution purpose is clear.

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 the tool via examples and explains the in_project behavior, but it gives no explicit guidance on when not to use it or which sibling tools to prefer for specialized tasks. Usage context is implied rather than 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 behavioral burden. It does disclose one useful behavioral trait—relative paths resolve inside the synced project—and the verb 'Download' implies a non-mutating remote fetch. But it does not mention whether local_dest is overwritten, whether directories are created, or any permissions/scope requirements.

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

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

The description is short and front-loaded, with no filler. The example path is compact and useful. It loses a point only because the terseness comes at the cost of missing parameter and usage detail, though the structure itself is 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 tool with 3 parameters, no annotations, and no output schema, a single sentence is not complete enough. An agent is left guessing about local_dest semantics, the role of project_path, overwrite behavior, and how this tool differs from CI artifact download alternatives.

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 must compensate. It clarifies remote_path with the relative-path rule and a concrete example, but local_dest and especially project_path remain unexplained beyond their parameter names. This is insufficient for a 3-parameter tool with no 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 opens with a clear verb+resource: 'Download a file from the remote Mac.' The example and path-resolution note make the tool's scope specific and distinguish it from related tools such as ci_download_artifacts or device_install_app.

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 by noting that relative paths resolve inside the synced project, which suggests this is for retrieving files produced on the Mac. However, it never explicitly names alternatives or says when not to use this tool, so an agent must infer the boundary versus sibling tools like ci_download_artifacts.

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 of behavioral disclosure. It states that the tool installs and launches the app, but it does not disclose whether an existing app is replaced, whether the simulator must already be booted, what state changes occur, or any authorization requirements. This is a mutating operation with only minimal 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?

A single sentence that front-loads the core purpose, includes a relevant artifact-source example, and contains no filler or redundant restatement of the tool name.

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 annotations and no output schema, the description is too thin for an installation tool with optional parameters. It does not explain how device_name_or_udid and bundle_id are used, what happens if they are omitted, prerequisites like booted simulators, or the side effects of installing over an existing app.

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 must compensate. The phrase 'zipped simulator .app' maps to app_zip_path, but bundle_id and device_name_or_udid are not explained at all, including why they are optional or how they affect the install/launch. The parameter names and titles offer some clue, but the description adds little semantic 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?

The description names a specific verb and resource: installing a zipped .app on the remote Mac's simulator, and it also states the follow-up action of launching it. This clearly differentiates it from nearby tools like device_install_app, which targets physical devices, and mac_run_on_simulator, which focuses on running rather than installing a zipped artifact.

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

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

The phrase 'e.g. from ci_download_artifacts' gives a clear workflow context, implying this tool is meant for taking a downloaded artifact and installing it. However, it does not explicitly state when to prefer this over sibling alternatives such as mac_run_on_simulator or device_install_app, nor does it state exclusions such as requiring a booted simulator.

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 conveys that the tool is a read-only listing operation and scopes to the remote Mac, but it does not explicitly state side-effect-free behavior or clarify how the only_booted flag affects results. The gap is moderate but not dangerous for a listing 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 one focused sentence with no filler or repetition. It is appropriately sized for the simplicity of the tool and front-loads 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?

The tool is simple, has an output schema, and the one optional parameter is visible in the schema. However, the description lacks any clarification of the only_booted parameter and provides no usage context relative to sibling tools, leaving modest but real gaps.

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

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

Schema description coverage is 0%, so the description must compensate by explaining only_booted, but it does not. The parameter name is somewhat self-explanatory, but the description does not clarify the default behavior or semantics of the flag.

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 ('List') with a clear resource ('iOS simulators') and scope ('on the remote Mac'). It is immediately distinguishable from sibling tools like mac_boot_simulator, mac_run_on_simulator, and mac_install_simulator_app, which perform different actions.

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

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

The description gives no guidance on when to use this tool versus alternatives, and it does not mention any exclusions or prerequisites. An agent must infer that this is the discovery step before booting or running on a simulator.

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 of behavioral disclosure. It names the operation but does not disclose side effects, prerequisites, whether a matching app must be installed, failure modes, or what happens when the URL is invalid.

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 efficiently structured sentence with the action and object front-loaded. Every word earns its place and there is 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 2-parameter tool with no output schema and no annotations, the description is too thin. An agent is left without information about simulator boot requirements, URL format constraints, the optional device parameter, or expected outcomes.

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 must compensate. It clarifies that `url` accepts URLs, deep links, or universal links, but says nothing about `device_name_or_udid`, including how it is used, its default behavior, or when it matters.

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

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

The description states a specific action (open) on a specific resource (URL/deep/universal link) in a specific environment (simulator). It is clear and distinguishable from siblings like mac_boot_simulator or mac_run_on_simulator, though it does not explicitly differentiate itself.

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

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

No guidance is given about when to use this tool versus alternative simulator/device tools, no prerequisites such as a booted simulator are mentioned, and no exclusions are stated. Usage context is only implied by the tool's name and one-line description.

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 reveals that the tool performs four stages, which is useful, but it does not disclose side effects such as overwriting an installed app, the direction or scope of 'sync', potential build time, or whether it boots the simulator automatically. For a state-changing workflow, this is a meaningful gap.

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, front-loaded sentence with no filler or redundant information. It could be more polished — 'Sync' is vague without an object — but it is appropriately sized for a straightforward tool description.

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

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

This is a multi-stage, state-changing tool with no annotations, no output schema, and no parameter descriptions. The one-line summary gives the high-level pipeline but omits critical context like default behavior (rebuild and sync_first default to true), what counts as a successful run, and how to select or specify the simulator device.

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% and the description adds no parameter-level meaning. An agent must guess the semantics of rebuild, sync_first, project_path, and device_name_or_udid from names alone, with no explanation of how they affect the sync/build/install/launch sequence.

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 clear verb chain — 'Sync, build for the simulator, install and launch the app' — and identifies the target environment as 'the remote Mac's iOS Simulator.' This distinguishes it as an all-in-one run workflow from more granular siblings like mac_build, mac_sync_project, or mac_install_simulator_app, though it does not name those alternatives explicitly.

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 its use case: run the app on the iOS Simulator with a sync/build/install/launch sequence. However, it provides no explicit guidance about when to prefer this composite tool over chaining mac_sync_project, mac_build, and mac_install_simulator_app, nor does it mention any prerequisites such as a booted simulator or configured project.

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 of behavioral disclosure. It does state that the result is returned as an image, but it omits side effects, failure behavior, whether a simulator must be running, and how the optional simulator selection affects 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?

The description is a single sentence with no wasted words and is front-loaded with the action and resource. It is concise, though slightly under-specified for parameter meaning.

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

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

For a tool with no annotations and no output schema, the description should explain how the optional device parameter works, what prerequisites exist, and what the returned image represents. It only covers the basic action and return type, so an agent is left guessing about important calling details.

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

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

The only parameter, device_name_or_udid, is undocumented in both the schema and the description, and schema description coverage is 0%. The description does not compensate by explaining whether this parameter selects the target simulator or what happens when it is omitted.

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 ('Take') and names a precise resource ('screenshot of the iOS Simulator on the remote Mac'), plus the output type ('return it as an image'). This clearly differentiates it from sibling tools like mac_fetch_file or the device_* 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 intended use is implied by naming the iOS Simulator on the remote Mac, which distinguishes it from physical-device tools. However, it does not state prerequisites such as the simulator needing to be booted, nor does it name when-not-to-use conditions or 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 the full burden of behavioral disclosure. It reveals that Flutter print/debugPrint output is included, but it does not state whether this is a read-only operation, what 'recent' means, whether the simulator must be booted, or how the output is structured. This is too thin for an unannotated 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 a single front-loaded sentence that wastes no words. The parenthetical about Flutter print/debugPrint is relevant and earns its place, and the key scoping phrase 'from the app running in the simulator' appears early.

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

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

With four parameters, zero schema description coverage, no annotations, and no output schema, the description leaves too much unexplained. An agent still does not know how filtering works, what the default time window is, what the returned lines look like, or what conditions cause failure, so the tool is not adequately specified.

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 must compensate by explaining grep, process, seconds, and device_name_or_udid. It does not document any of them; the only useful context is that Flutter prints appear in the logs, which is general content information rather than parameter semantics.

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

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

The description identifies a clear resource — recent unified-log lines from the app in the simulator — and correctly notes that Flutter print/debugPrint output appears there. It lacks an explicit action verb like 'Retrieve' or 'Get' and does not explicitly contrast it with siblings such as device_syslog, so it falls short of full sibling differentiation.

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

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

There is no guidance about when to use this tool versus alternatives like device_syslog, mac_exec, or mac_run_on_simulator. The description implies it is for inspecting simulator app logs, but it does not state prerequisites, exclusions, or the conditions that should route an agent to a different 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?

With no annotations, the description carries the behavioral disclosure burden. It clearly reveals the skip list and, importantly, that clean=true wipes the remote copy first, which is critical destructive behavior an agent must know.

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

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

The description is a single, front-loaded sentence that communicates the core action, exclusions, and the clean behavior without unnecessary words. Every clause 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?

The tool is simple, but the description omits any explanation of project_path, remote destination details, or return/result expectations. The core behavior is clear, but an agent would still need to infer some calling conventions.

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 real meaning for the clean parameter by explaining that clean=true wipes the remote copy first, which the schema does not. However, project_path is not described at all, and with 0% schema description coverage this is a notable gap.

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

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

The description uses a specific verb and resource: 'Upload the Flutter project to the remote Mac'. It also clarifies scope by listing excluded directories, making the tool's purpose distinct from build/run/device 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?

There is no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The purpose is implied, but the description does not help an agent choose between this and other Mac-related 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, the description carries full responsibility for behavioral disclosure. It does mention the password requirement for .p12, but does not explicitly state that the tool is read-only, describe its return format, or mention potential errors. 'Inspect' implies non-destructive behavior, but this is left to inference.

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, front-loaded sentence with no filler. It efficiently conveys the tool's scope and the password constraint, making every word count.

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

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

For a simple read-only tool with no output schema and no annotations, the description covers the core inputs and password constraint. However, it does not explicitly state the return format, whether the operation is non-destructive, or what happens on invalid input. Given the absence of annotations, this is a noticeable gap.

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

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

The schema has zero description coverage, so the description must add meaning. It explains that `path` refers to a .mobileprovision or .p12 file, and that `p12_password` is required when inspecting .p12 files. This adds meaningful context beyond the bare parameter titles.

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

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

The description states a specific verb ('Inspect') and names the exact resource types (.mobileprovision and .p12), enumerating the fields extracted from mobileprovision. This clearly distinguishes it from sibling tools like signing_quick_setup, which perform setup rather than inspection.

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

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

No guidance is provided on when to use this tool versus alternatives, nor any exclusions. The only usage hint is that .p12 files require a password, which is a prerequisite rather than a scenario. An agent would have to infer when to choose this tool from its name and purpose alone.

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 discloses several important behaviors: it registers a bundle id, creates or reuses a certificate from a locally generated CSR, creates a provisioning profile, saves artifacts to a specific path, and optionally uploads to GitHub secrets. It also notes that ad-hoc/development profiles include all registered devices. It does not mention side effects like whether existing certificates are revoked or whether the operation is reversible, but the disclosed behaviors are substantial and go well beyond a generic 'sets up signing' statement.

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 dense sentence that front-loads the core purpose ('One-shot iOS code signing from Windows/Linux') and then lists the steps and key behaviors. It is efficient and avoids fluff, though the long sentence could be slightly easier to parse if broken into two sentences. Every clause 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 complexity (9 parameters, no output schema, no annotations), the description covers the main flow and key defaults but leaves gaps: it doesn't explain what the return value looks like, what happens if the bundle id is already registered, whether force_new_certificate revokes the old certificate, or what include_asc_key does. For a complex setup tool, an agent would benefit from more detail on side effects and prerequisites, but the description is still usable for basic 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?

Schema description coverage is 0%, so the description must compensate for the 9 parameters. The description explains the purpose of bundle_id (defaults to project's), profile_kind (ad-hoc/development include all registered devices), and push_to_github (uploads secrets). However, it does not explain repo, app_name, p12_password, project_path, include_asc_key, or force_new_certificate beyond what the schema names imply. The description adds some meaning but leaves several parameters under-documented.

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

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

The description states a specific verb ('One-shot iOS code signing') and resource (bundle id, certificate, provisioning profile, .p12/.mobileprovision files), and clearly distinguishes this from siblings like signing_inspect, asc_register_bundle_id, and ci_set_signing_secrets by describing the full end-to-end flow. It also notes the platform context (Windows/Linux) and the optional GitHub secrets upload, which makes the tool's purpose unmistakable.

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

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

The description implies when to use this tool: when you need a complete signing setup in one shot, including certificate creation/reuse, profile creation, and optional GitHub secret upload. It does not explicitly state when NOT to use it or name alternatives (e.g., use asc_register_bundle_id for just registering a bundle id, or ci_set_signing_secrets for just uploading secrets), but the 'one-shot' framing and the detailed flow provide clear context for an agent to select 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?

With no annotations, the description carries the full burden of behavioral disclosure, but it only mentions listing builds and their processing state. It does not state whether the operation is read-only, what 'recent' means, whether authentication or configuration is needed, or what happens when no builds exist. The verb 'List' implies safety but does not explicitly confirm it.

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

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

The description is a single efficient sentence with no wasted words, and the core action is front-loaded. It is appropriately compact for a simple list operation, though it sacrifices detail needed for full self-sufficiency.

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, no annotations, and zero parameter coverage, the description is not complete enough for an agent to invoke the tool with confidence. It lacks information about return format, parameter roles, and app selection semantics, all of which are important for correct use.

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

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

Schema description coverage is 0%, and the description mentions none of the three parameters (limit, bundle_id, project_path). The agent receives no explanation of how these parameters affect the query, what values are valid, or how they interact with each other.

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

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

The description states a specific verb ('List') and resource ('recent TestFlight/App Store builds') and adds the useful detail of returning processing state. However, it does not explicitly differentiate itself from sibling tools like testflight_distribute or asc_list, so it falls short of full distinction.

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

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

The description gives no guidance on when to use this tool versus alternatives such as ci_list_runs, asc_list, or testflight_distribute. There is no indication of prerequisites, exclusions, or scenarios where a sibling tool would be more 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?

No annotations are provided, so the description carries the full burden. It discloses that the tool mutates distribution state (adds a build to beta groups) and that uses_non_exempt_encryption can be left as-is with None, but it does not disclose side effects, required permissions, whether the operation is reversible, or what happens if the build is already in a group. The 'None = leave as is' note is helpful but incomplete.

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 that front-loads the main action and includes a parenthetical clarification for the encryption parameter. It is compact and readable, though the parenthetical could be slightly clearer.

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

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

For a mutation tool with no annotations and no output schema, the description is too thin. It does not explain the expected workflow (e.g., call testflight_builds first to get ids), what a successful response looks like, or failure modes. The reference to testflight_builds helps but is not enough.

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 must compensate. It explains uses_non_exempt_encryption and beta_group_ids source, but build_id is only implied as the target build. It does not explain the format of beta_group_ids or the meaning of the default false for uses_non_exempt_encryption versus None.

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

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

The description states a specific action ('Answer export compliance... and add it to TestFlight beta groups') with a clear resource (a processed build) and references the sibling tool testflight_builds for ids. It is distinguishable from siblings like testflight_builds, though it doesn't explicitly name a sibling it is not.

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 context: it operates on a processed build and takes beta group ids from testflight_builds. It does not explicitly state when to use this tool versus alternatives, nor does it mention prerequisites like having a processed build or being authenticated with App Store Connect.

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