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

With no annotations, the description carries the burden for behavioral disclosure. It implies a read operation but does not mention the optional 'wait' parameter (which can block up to 60 seconds) or any side effects, errors, or return behavior. It adds some context (the 'unknown' trigger) but lacks depth.

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. It front-loads the primary purpose and places the usage condition in parentheses, avoiding unnecessary words.

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

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

Given no output schema and no annotations, the description must compensate for missing details. It omits explanation of the wait parameter, the nature of the returned status/result, and potential errors or timeouts. This leaves agents guessing about blocking behavior and response format, making it incomplete for a tool that can wait.

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 explain parameters. It only implies jobId by referencing 'a job started with askew_run', but never explicitly describes it or the 'wait' parameter. The description fails to add meaning for the wait parameter, which is essential for correct usage.

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

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

The description states a specific verb ('Get') and resource ('status and result of a job'), and names the related tool askew_run, which differentiates it from siblings like askew_run, askew_list_routes, etc. The parenthetical adds a clear distinguishing condition.

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

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

It explicitly provides a usage trigger: 'use when the run returned unknown'. This names the alternative (askew_run) and the condition that selects this tool, giving clear guidance on when to invoke 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 provided, the description carries the full burden. It does state the key behavioral outcome — acknowledged items no longer appear — which is useful. However, it does not disclose whether acknowledgment is reversible, what permissions are required, or what happens to the underlying items beyond visibility.

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, purposeful sentence with no filler. It front-loads the action and immediately states the practical result, making it easy to scan and understand.

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 core purpose and effect. Still, it leaves gaps: where the ids are obtained, whether acknowledgment is permanent, and what prerequisite 'handled' actually means. An agent could invoke it, but with only partial confidence.

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 'ids' parameter beyond hinting that items are involved. The schema says ids is a non-empty string array, but the description does not clarify that these are inbox item IDs or where they come from. The low schema coverage requires more compensation than this provides.

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

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

The description names a specific verb ('Mark'), a clear resource ('handled inbox items'), and the expected consequence ('so they no longer appear'). This distinguishes it from sibling tools like askew_inbox_list and askew_inbox_wait, making the action 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 phrase 'handled inbox items' gives clear context about when this tool is appropriate: after items have been processed and need acknowledgment. It does not explicitly name alternatives or exclusion conditions, but the intended usage is reasonably inferable from the sibling set.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It usefully indicates that items are sent by the phone and that acknowledgement is expected afterward, implying items are not auto-acked. However, it does not disclose ordering, pagination, whether the list is destructive, or how unacknowledged items behave over time.

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

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

The description is two sentences with no waste. The main action is front-loaded, concrete examples are placed parenthetically, and the follow-up action (ack) is included without bloating the text.

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

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

For a simple one-parameter, no-output-schema tool, the description provides enough context to know what the tool does and what to do next. It does not enumerate the output item shape, but the examples give a sufficient high-level understanding for an agent to invoke it effectively.

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

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

Schema description coverage is 100%: the only parameter, 'since', is documented as an ISO time filter for items after that time. The description adds no parameter-level detail, but none is needed because the schema already explains the parameter sufficiently.

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 ('Fetch') and resource ('items the phone sent to the agent'), with concrete examples such as trigger data, share sheet, and payments. This clearly distinguishes it from sibling askew_inbox_ack and most other sibling tools. The only minor gap is not explicitly contrasting with askew_inbox_wait, but the name and description make the list-versus-wait distinction 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 explicitly instructs to call askew_inbox_ack after handling items, establishing a clear workflow sequence. It does not explicitly state when to prefer this tool over askew_inbox_wait or other siblings, but the fetch semantics are implied strongly enough for an agent to select it appropriately.

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

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

With no annotations, the description carries the burden. It discloses the wait duration and the looping behavior, but does not disclose what happens on timeout (e.g., returns empty, returns null, errors), whether it consumes the item, or whether it is a read-only operation. The timeout behavior is partially implied by the schema default/maximum, but the return-on-timeout behavior 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?

One sentence with a parenthetical usage hint. Every word earns its place, and the key behavior (wait up to 30 seconds) is front-loaded. 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 polling tool with no annotations and no output schema, the description is thin. It does not explain the 'since' parameter, what a 'new inbox item' means, what the return value looks like, or timeout behavior. The loop hint helps, but an agent still lacks enough to call it correctly with confidence.

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 does not explain either parameter. 'since' is entirely unexplained (likely a timestamp/cursor), and 'timeout' is only implied by the description's 'up to 30 seconds'. The schema provides types/defaults but no semantic meaning, so an agent cannot confidently construct a correct call.

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

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

The description states a specific verb ('wait') and resource ('new inbox item'), and adds a concrete time bound ('up to 30 seconds'). It is clear enough to distinguish from siblings like askew_inbox_list (list) and askew_inbox_ack (acknowledge), though it does not explicitly name them.

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 parenthetical 'loop this to react immediately' gives explicit usage context for a polling/waiting pattern. It implies this tool is for blocking until a new item arrives, versus listing or acknowledging. It does not explicitly state when not to use it or name alternatives, but the loop guidance is useful and 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?

With no annotations, the description must carry the transparency burden. 'List' communicates a read-only, non-destructive operation, and 'registered to this account' clarifies scope. It does not disclose whether the data is live or cached, or whether an active connection is required, but for a simple listing tool this is a reasonable baseline.

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 is front-loaded with the action verb and clearly enumerates the returned items. The parenthetical clarification '(runnable Shortcuts)' adds value without unnecessary length.

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

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

For a zero-parameter listing tool, the description covers the essential information: what is listed and the account scope. There is no output schema, but the description implies the return content. It could mention the purpose of the list (e.g., preparing for a run), but that is not strictly necessary.

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 zero parameters and 100% coverage, so there are no parameter semantics to clarify. The baseline for no parameters is 4, and the description adds relevant context about what is being listed without needing to describe parameters.

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

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

The description clearly states the verb 'List' and the resources: routes (runnable Shortcuts), devices, and connection mode registered to the account. It is specific and understandable, though it does not explicitly differentiate itself from sibling tools by name.

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

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

The intended use is implied: call this when you need to discover routes, devices, or connection state. However, there is no explicit guidance on when to prefer this tool over siblings or any mention of prerequisites like authentication or connection 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals meaningful traits: delivery goes to the phone, the message is kept in the results box, and it is strictly one-way rather than conversational. It does not cover failure behavior or delivery guarantees, but the disclosed intent is strong.

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 clear, front-loaded sentence with a parenthetical behavioral qualifier. Every part 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 tool with 5 parameters, no output schema, and no annotations, the description is too thin. It explains the high-level effect but not how to populate the parameters, what the tool returns, or what happens on failure, leaving an agent to guess about critical invocation details.

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

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

Schema description coverage is 0%, and the description adds no parameter-specific guidance. Property names like title, body, content, ref, and deviceId are somewhat self-explanatory from the notification context, but ambiguous duplication between body and content and the purpose of ref and deviceId remain unexplained.

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: it sends a notification to the user's phone and persists it in the results box. The parenthetical emphasizes agent-to-person, one-way communication and explicitly distinguishes it from a conversation, which separates it from the inbox 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 gives clear context for when this tool is appropriate: one-way notification delivery from agent to person rather than a conversation. It does not explicitly name an alternative tool like askew_inbox_* for two-way exchanges, but the exclusion is clear enough.

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

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

With no annotations, the description carries the burden, and it discloses important behavior: locked-phone operation, end-to-end encryption, validation before execution, a blocking wait, and an 'unknown' status requiring polling. It does not spell out that Shortcuts can have side effects or detail permission requirements, so it is not a 5.

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

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

Four dense sentences with the core operation first, followed by the most important constraints and polling behavior. No filler or repetition of schema fields.

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 no-output-schema, async execution tool, it covers prerequisites, input validation, wait semantics, and polling. It is slightly incomplete on selecting the route via routeId vs routeName and on expected success/error result shapes, but it is closer to complete than most definitions.

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 strongly clarifies `input` (exact keys, date format, mismatched-input rejection) and partly explains `wait` via the timeout sentence. However, routeId and routeName are not explained, and the description never mentions idempotencyKey beyond what the schema already says, leaving 60%-coverage gaps partially unaddressed.

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

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

The opening sentence uses a specific verb-resource pair ('Run a Shortcut (route) on the user's iPhone') and clearly differentiates the tool from sibling list/get tools by saying the run returns the result, while listing routes first and polling with askew_get_run.

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 an explicit precondition ('Call askew_list_routes first'), a hard constraint on input keys and date format, and a concrete error-handling path ('if status is "unknown", poll with askew_get_run'). This tells the agent exactly when and how to use the 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 adds a meaningful security property: the variable is sealed with the phone-issued key and the relay cannot read it. However, it omits return format, error behavior, and permission details, so transparency is only partial.

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. The security parenthetical is the only extra clause and it earns its place by communicating an important constraint.

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 read operation, the description provides the essential purpose and an important security caveat. However, since there is no output schema, it does not state what the tool returns or how it behaves on missing variables, leaving an agent with enough to invoke but not fully anticipate the outcome.

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 only exposes a `name` string with minLength 1, and the description adds context by clarifying that the name refers to a variable shared with the phone. Coverage is 0%, but the single self-evident parameter limits the need for deeper explanation.

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 verb and resource: 'Read a variable,' and the shared-with-phone qualifier adds specificity. It does not explicitly name a sibling such as askew_variables_set, but the read/write contrast is readily inferred.

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 alternatives like askew_variables_set. There are no conditions, exclusions, or references to sibling tools, so the correct usage context must be inferred 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 provided, the description carries the full burden of behavioral disclosure. It does provide some useful context about encryption ('sealed with the account key') and that the phone reads it with the same key, which is helpful. However, it omits critical behavior such as whether the operation overwrites existing variables, what happens on failure, any size limits, or the response format. This is a meaningful gap for a write 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 a single, concise sentence that front-loads the core action ('Write a variable shared with the phone') and adds a brief technical note about sealing. Every word earns its place with no filler. It is appropriately sized for such a simple 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?

Given the tool's simplicity (2 parameters, no output schema), the description is generally adequate for a basic understanding but lacks essential context. It does not explain whether the write is an upsert, how errors are reported, or what the tool returns (if anything). An agent cannot infer important operational details that are not in the schema or annotations, making the tool harder to use correctly without external documentation.

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 does not explain the semantics of 'name' or 'value' beyond the schema's types. The phrasing 'Write a variable' implies name is the variable identifier and value is the content, but it does not clarify aspects like allowed value shapes, constraints, or how the name must be formatted. The description adds little value over the raw schema.

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

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

The description clearly states the verb 'Write' and the resource 'variable shared with the phone', which distinguishes it from the read counterpart (askew_variables_get). It conveys the essential purpose without being a tautology. However, it does not explicitly name any sibling tool for differentiation, relying on inference from the phrase 'shared with the phone'.

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 phrasing 'shared with the phone' implies a use case, but it does not specify when to choose this over other tools like askew_variables_get or askew_run. The agent must infer usage from context alone, which is insufficient.

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