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

No annotations exist, so the description carries the full behavioral burden. It implies a side-effect-free read by naming the two facts returned (account in use, token source), but it says nothing about whether the token value is exposed or masked, whether the check makes a network/auth call, or what happens when no valid token is configured.

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 front-loaded sentence with no filler; the two outputs (account and token origin) come in the right order. It is arguably too short rather than too long, but the structure itself is clean.

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 output schema and no annotations, the description must fully specify behavior and results. It names the two returned facts but leaves the return shape (field names, masking of the token, failure/empty-state behavior) undefined, which is the main remaining gap for a zero-param diagnostic 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 takes zero parameters and the description correctly does not invent any, so there is nothing to document. Baseline 4 applies for a no-parameter tool.

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 ('check') and a specific resource ('which Meta account is in use and where the token came from'), so an agent knows exactly what question this tool answers. It does not explicitly differentiate itself from the org-listing siblings, but the resource domain (Meta account/token) is distinct enough from list_orgs/select_org that confusion is unlikely.

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?

Usage is only implied: the agent must infer that this is a diagnostic call to run before other Meta operations when the active identity is uncertain. There is no explicit when-to-use, when-not-to-use, or named alternative among the 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?

No annotations are supplied, so the description carries the full burden. It usefully discloses the LIVE safety guard via confirm_live, but says nothing about overwrite semantics in the target channel, required permissions, reversibility, or failure behavior when confirm_live is omitted.

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, no filler, with the core action first and the safety prerequisite attached to the specific case that needs it.

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 5-parameter mutation tool with no annotations and no output schema, key details are missing: whether the copy overwrites or appends, what the response contains, and what error occurs when confirm_live is false against LIVE. The essentials for constructing the call are present, but not for predicting its effect.

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 80%, so binary_id, app, and org are already documented in the schema. The description only adds the confirm_live=true requirement for LIVE targets, which the schema does not convey; to_channel and org get no additional meaning from the prose.

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 (copy) and resource (build) with scope: an existing build moved into another release channel, and it names list_channels as the source of the binary id. That cleanly separates it from upload_build, which would create a new binary instead of reusing one.

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?

Tells the agent to obtain binary_id from list_channels and gives an explicit gating condition: copying into LIVE requires confirm_live=true. It stops short of stating when to prefer upload_build or what happens if the target channel already has builds, but the primary selection path is clear.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the endpoint and that execution happens as the logged-in developer, but says nothing about whether mutations are possible, permission requirements, rate limits, error behavior, or response format for a raw query 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 definition is a single front-loaded sentence with no wasted words. It is appropriately terse for a description, though the terseness contributes to gaps covered in other dimensions.

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 raw GraphQL escape hatch with nested variables, no annotations, no output schema, and 0% schema description coverage, the description is too thin. An agent lacks enough information about parameter usage, mutation safety, and expected return/error behavior to invoke it confidently.

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 the 'variables' object at all. It implies the 'query' parameter should be raw GraphQL, but provides no guidance on variables syntax, formatting, or how the two parameters interact.

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

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

The description states a specific verb and resource: run a raw GraphQL query against graph.oculus.com as the logged-in developer. It clearly identifies an escape-hatch tool, though it does not explicitly name when to use it instead of siblings like metavr or list_apps.

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 only usage cue is the parenthetical '(advanced)', which signals audience rather than conditions. There is no explanation of when this tool is appropriate versus the many higher-level sibling tools, and no prerequisites or exclusions are given.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It never states that this is a read-only call, whether results are paginated, or what authentication/org-selection state is required, all of which matter for a list operation in this sibling set.

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, front-loaded sentence with no waste or filler. It is efficient, though the brevity contributes to the gaps noted in other dimensions rather than being an asset on its own.

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 (one optional parameter, no nested objects, no output schema), so the description is minimally viable. However, with no annotations and no output schema, it should say more about return shape or pagination than a single scoping clause.

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

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

Schema coverage is 100% and the single 'org' parameter is documented in the schema as 'Organization id or name; defaults to the selected org'. The description adds nothing beyond that, so the baseline 3 applies.

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

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

States a specific verb+resource ('List apps') and scopes it to an organization, so an agent knows exactly what it returns. It does not distinguish itself from the closest sibling (list_channels / list_orgs), but the resource name 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?

No guidance on when to call this versus the other list_* siblings, nor on prerequisites such as needing a selected org first (select_org exists as a sibling). Usage is only implied by the tool name.

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 must carry behavioral context. It adds useful return-value detail with "ALPHA/BETA/RC/LIVE/custom" and "The store channel has is_live=true", but omits permissions, ordering, pagination, and side-effect information.

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 short sentences with no wasted text. The core purpose is front-loaded, and the additional is_live note is directly relevant to interpreting the output.

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 listing tool with fully documented parameters, the description covers the resource and a key return-value nuance. It is nearly complete, though it could mention response ordering or whether all channels are always returned.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description does not add meaning beyond what is in the schema, and with full coverage the baseline of 3 is appropriate.

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

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

The description uses a specific verb and resource: "List an app's release channels" and adds that it returns their latest builds. It clearly describes the tool's purpose, but does not explicitly differentiate it from sibling tools such as list_apps or list_orgs.

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?

Usage is implied by the phrase "an app's release channels", but the description gives no explicit when-to-use guidance, prerequisites, or alternatives. It does not clarify when to choose this over other listing 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 must carry the behavioral burden. It does disclose that results are filtered by the authenticated account's membership, which is meaningful context, but says nothing about ordering, pagination, or what happens if the account belongs to zero orgs.

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 front-loaded sentence with no filler; every word contributes to scope and resource identity.

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

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

For a zero-parameter read-only list operation with no output schema or annotations, the description covers what is needed to select and invoke it. Only the return shape/count semantics are left implicit, a minor 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 tool takes zero parameters, so the baseline is 4. There is nothing schema-level left for the description to clarify.

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 (List) and resource (developer organizations) with an explicit scope: only those the logged-in account belongs to. That scope distinguishes it from siblings like list_apps, list_channels and list_test_users, though it does not name a near-neighbor alternative 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 phrase 'the logged-in account belongs to' implies when this tool applies (identity-scoped discovery) but gives no explicit when-to-use/when-not guidance or pointer to alternatives such as select_org or auth_status.

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

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

No annotations are provided, so the description carries full behavioral burden. It implies a read operation via 'List' but does not disclose permissions, pagination behavior, whether only test users are returned, or any other operational traits.

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

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

The description is a single, efficient sentence with the verb and scope front-loaded. There is no wasted wording.

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 list tool with one optional parameter and no output schema, the description is minimally adequate but lacks usage guidance and behavioral context. It does not explain what a 'test user' is or what the listing returns, though the tool's simplicity limits the 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 description coverage is 100%, and the sole optional 'org' parameter is fully documented in the schema as an organization id or name defaulting to the selected org. The description adds no parameter semantics beyond what the schema already provides, so baseline 3 is appropriate.

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

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

The description states a specific verb ('List') and resource ('test users') scoped to an organization. It clearly distinguishes the tool from sibling list operations such as list_orgs, list_apps, and list_channels, though it does not elaborate beyond the name-level 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?

There is no guidance on when to use this tool versus alternatives, no exclusions, and no prerequisites. The only implied usage is that it lists test users, which an agent could infer from the 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 behavioral burden. It discloses that arbitrary CLI commands are executed, but says nothing about side effects, destructive potential, authentication requirements, execution environment, output format, or error behavior, despite this being a powerful command-execution 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?

A single front-loaded sentence with no wasted words. The examples make the broad scope immediately understandable, and the ellipsis appropriately signals that the listed commands are not exhaustive.

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 passthrough with full schema coverage and an example, the description is adequate to start forming a call. However, for a generic command-execution tool with no annotations and no output schema, it should say more about safety, available command syntax, and return 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?

The schema has 100% description coverage and already provides an example argument array. The description adds useful command categories such as devices, app install, logcat, and perf, but does not explain argument syntax, options, or JSON output conventions beyond the schema example.

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

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

The description states a specific verb and resource: run metavr CLI commands bundled with MQDH, with concrete examples like devices, app install, logcat, and perf. It is clear what the tool does, though it does not explicitly distinguish itself from structured sibling tools such as list_apps or upload_build.

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 generic CLI passthrough versus the many specific sibling tools like list_apps, upload_build, graphql, or auth_status. An agent can infer that it is for arbitrary metavr commands, but there are no explicit inclusions, exclusions, 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?

With no annotations, the description does carry one valuable behavioral disclosure: the selection is persisted across sessions, meaning a global state mutation. It omits what happens on an ambiguous partial match, whether the org is validated to exist, and what the call returns, which matters for a state-changing tool with zero annotation coverage.

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 short sentences, zero filler, with the core action and the persistence side effect 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 one-parameter tool with no output schema, the description covers the action, accepted inputs, and the cross-session persistence. Only the ambiguity/validation behavior on partial matches is left unstated.

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

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

Schema coverage is 100% and the schema already documents 'Organization id or name (partial match ok)'; the description only restates 'by id or name' and adds no tie-breaking or ambiguity behavior. Baseline 3 is appropriate.

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

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

States a specific verb and resource ('Select the active developer organization') plus the accepted identifier forms, so the agent knows this sets active state rather than listing orgs. It doesn't explicitly name list_orgs as the discovery sibling, which keeps it from a 5.

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

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

'Select the active...' plus 'Saved across sessions' implies the tool is used to pin a working context before other calls, but there is no explicit when-to-use/when-not or guidance to call list_orgs first when the org id is unknown.

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

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses the write operation, draft default, LIVE publishing guardrail, dry-run preview, background execution, and polling via returned job_id. This is the key context an agent needs before invoking a mutating async upload.

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: first the action, then draft/publish semantics, then live confirmation, then dry-run, then async polling. Every sentence provides useful operational information.

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

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

For a complex ten-parameter mutation with no output schema and no annotations, the description covers the critical async flow and safety gates. It does not mention prerequisites such as authentication or org selection, but those are partially handled by schema fields and sibling tools.

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

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

Schema description coverage is 100%, so the schema already documents all ten parameters thoroughly. The description reinforces publish, confirm_live, and dry_run behavior, but it does not add substantial meaning beyond the structured field descriptions; baseline 3 is appropriate.

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

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

The description states a specific verb and resource: upload an APK or PC build directory to an app's release channel using ovr-platform-util. It also distinguishes the Quest/PC artifact types, making the tool's role immediately 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?

It gives clear operational conditions: draft by default, publish=true to publish, confirm_live=true for LIVE, and dry_run=true to preview. It also names upload_status as the required follow-up, though it does not compare against siblings such as copy_build.

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; 'Get' implies read-only and 'progress and output' tells the agent what fields come back, which is the key behavioral fact given there is no output schema. It does not cover what happens for an unknown/expired job_id, how long job records persist, or whether output is truncated by tail.

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 short sentences, front-loaded with what the tool returns and followed by the one non-obvious usage rule. Nothing redundant.

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, non-destructive polling tool with no output schema, the description covers purpose, the job_id contract, and the nature of the return value. Only edge cases (missing job, expired jobs, partial output) are left unstated.

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

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

Schema coverage is only 50%: tail is documented inline while job_id has no schema description. The description compensates by explaining job_id semantics — its optionality and the list-all behavior when omitted — which is meaning beyond the raw schema.

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

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

States a specific verb (get) and resource (progress and output of uploads) and anchors it to the sibling that creates those uploads, upload_build. An agent can tell from the description alone that this is a polling/status tool, not a lister of builds or orgs.

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 sentence 'Omit job_id to list all jobs' gives explicit operating guidance for the two modes (single job vs. all jobs). It stops short of naming an alternative tool or exclusion conditions, but there is no obvious sibling competing for this job.

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