Hiring Signals

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description adds genuinely new behavior beyond the annotations: the call is a no-op for SUCCEEDED/FAILED/ABORTING/ABORTED/TIMED-OUT runs, and the response returns the updated run details. It does not mention permission requirements or failure modes.

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?

Front-loaded with the core action and its status preconditions before the USAGE block, and no sentence is wasted. The USAGE EXAMPLES lines are thin (one is a bare restatement of the required runId) but the graceful variant does demonstrate a real parameter usage.

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 an output schema present, return values need not be detailed, and the description correctly just notes that updated run details come back. Purpose, preconditions, and usage are all covered; only permission/auth context is missing for a destructive, openWorld=false operation.

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

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

Schema description coverage is 100% and both parameters (runId, gracefully with its 30-second timeout) are fully documented in the schema, so the baseline is 3. The description adds little parameter meaning beyond the example 'Gracefully abort run y2h7sK3Wc', which only loosely illustrates the gracefully 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?

States a specific verb and resource ('Abort an Actor run') and narrows scope with the precondition 'currently starting or running', which makes the operation unambiguous. It never names a sibling such as get-actor-run to contrast against, but the destructive abort semantics are self-evidently distinct from the read-only tools in the sibling list.

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

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

'Use when you need to stop a run that is taking too long or misconfigured' gives a clear triggering condition, and the status no-op list functions as an implicit when-not-to-use rule for terminal runs. No alternative tools or host-level prerequisites (auth, workspace scoping) are offered, so it stops short of a full routing guide.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds real behavioral context beyond that: the blocking semantics and 45s cap of waitSecs, the meaning of summary (describes the past) and nextStep (prescribes one interpolated follow-up), which an agent needs to interpret the response.

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?

Front-loaded with the purpose, then USAGE, then examples, with every line carrying information: field list, summary/nextStep semantics, and the waitSecs contract. No filler sentences, and the examples are short and directly actionable.

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

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

With an output schema present, return values need not be explained, yet the description usefully characterizes summary and nextStep so the agent can act on them. Purpose, parameters, blocking behavior and examples are all covered; only auth/permission prerequisites for reading another Actor's run are unstated, which is 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?

Schema coverage is 100%, so both parameters are already documented in the schema with min/max/default and terminal-state enumeration. The description's waitSecs line ('0-45, default 30, waits up to that many seconds for terminal status') largely restates the schema, adding no syntax or format beyond it, 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?

The description gives a precise verb+resource ('Get detailed information about a specific Actor run') and enumerates the returned fields (status, storages, stats, summary, nextStep). It does not explicitly contrast itself with the sibling abort-actor-run, but the phrasing 'a run started by any Actor-running tool' makes its read-only inspection role 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 USAGE section states when to reach for it ('check the status of a run started by any Actor-running tool') and how to make it block via waitSecs > 0, reinforced by two concrete user_input examples. It stops short of stating when NOT to use it (e.g. versus abort-actor-run or a listing tool), so it is clear context without 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 annotations already declaring readOnlyHint=true and idempotentHint=true, the description adds valuable behavioral context: returns rows themselves, default limit of 20, and clean=true behavior. It also clarifies the nature of the return value beyond the schema.

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

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

Well-structured with clear USAGE and USAGE EXAMPLES sections. Some redundancy ('Get items (rows)...' and 'Returns the rows themselves...') but overall efficient and front-loaded with purpose.

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

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

Given the tool has 8 parameters, an output schema, and rich annotations, the description adequately covers key behaviors, usage triggers, and examples. It doesn't explain every parameter but relies on the schema for that, which is appropriate.

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

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

Schema coverage is 100%, so baseline is 3. The description adds extra meaning by explaining default limit (20) and the clean=true shortcut, which supplements the schema. It also provides examples for fields usage, though most parameter semantics are in the schema.

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

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

Description clearly states the tool gets items (rows) from a dataset and explicitly distinguishes it from metadata, counts, or schema. It names the exact resource (dataset items) and the action (get), and provides direct trigger phrases for when to use it.

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

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

Provides explicit use cases ('when the user provides a datasetId and asks to retrieve results...'), and clarifies what it is not for (metadata, counts, schema). However, it does not name alternative tools explicitly, only implies them.

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

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

Annotations already establish readOnlyHint, idempotentHint, and destructiveHint as false. The description adds valuable behavioral context beyond this: the exact key name requirement and the preservation of Content-Encoding with automatic client decompression. No contradictions with annotations.

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

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

The description is well-structured with a concise opening definition, a short behavioral note, and clear usage examples. Every section earns its place without unnecessary fluff.

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

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

For a simple two-parameter read-only tool with full schema coverage, an output schema, and strong annotations, the description covers the essential context: how to target a record, what to expect (Content-Encoding), and when it applies. The sibling context also helps differentiate it from listing operations.

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

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

Input schema coverage is 100%, so the schema already documents both parameters. The description adds usage examples and the 'exact key name' requirement, but these are minimally additive beyond the schema's own property 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 uses a specific verb and resource: 'Get the value stored under a specific key in a key-value store.' It also distinguishes itself by explicitly stating this is 'a single record, not a listing of all keys,' which separates it from sibling tools like get-dataset-items.

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

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

The description provides a clear usage context: 'Use when you need to retrieve a specific record (JSON, text, or binary) from a store.' It does not name alternative tools explicitly, but the 'not a listing of all keys' phrase gives implicit exclusion guidance for listing-style 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?

Beyond the annotations the description discloses cost and billing semantics ($1.25/1K, filtered-out jobs not charged, only pay for new jobs), stateful side effects (monitorName maintains separate 'already seen' baselines; jobs cut off by maxJobsPerCompany are not remembered), and the waitSecs cap-and-return behavior. These are real behavioral facts the agent cannot get from annotations or schema, though nothing addresses the destructiveHint=true flag or what data may be altered.

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 wrapper sentence is boilerplate but brief, and the actor paragraph is dense with genuinely useful facts front-loaded (what it does, what it returns, the default cap, the price). Slight redundancy with the schema's own parameter descriptions, but no wasted padding.

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 15 parameters, no required inputs, and an output schema present, the description covers what an agent needs: auto-detection behavior, the RUN_SUMMARY board record, the fallback for undetected companies, the pay-per-new-job model, and the default output cap. Only the interaction with the annotated destructive/openWorld profile is left unaddressed.

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 carries full parameter documentation and the baseline is 3. The description restates the filter set (names; title, location, remote filters) and the default of 20 per company but adds no parameter detail the schema does not already contain.

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: retrieve all open jobs for a company by auto-detecting its Greenhouse, Lever, Ashby, Workable, Recruitee or Personio board, and it lists the returned fields (title, location, salary, date, URL). It does not explicitly name the sibling kadi_bence--workday-jobs-scraper as the alternative for Workday companies, so the boundary is only implied by the platform list rather than stated.

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 context is implied rather than stated: monitoring mode is pitched as 'Ideal for a daily schedule (hiring signals, job alerts)', waitSecs points to get-actor-run for polling, and the companies field explains what to do when a company is not detected. There is no explicit statement of when to prefer this tool over the workday scraper or the generic dataset/run tools.

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

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

Annotations already declare destructiveHint=true/openWorldHint=true/readOnlyHint=false, so the safety profile is covered. The description adds useful context (pay-per-result pricing, default 20/site, monitoring/baseline behavior via onlyNewJobs, GDPR stripping), but these largely restate parameter descriptions rather than disclosing new behavior such as run lifecycle or rate-limit handling.

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?

Roughly two sentences, front-loaded with what the tool does, then scope, inputs, outputs and cost. There is minor boilerplate ('calls the Actor and retrieves its output results') but no significant padding.

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 an output schema and full annotation coverage, the description only needs to convey purpose and scope, which it does, including input overview, per-site default and output fields. Complete enough for correct invocation, with only sibling differentiation left implicit.

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 17 parameters in depth. The description only summarizes inputs at a high level ('names or URLs; title, country, date filters'), adding little beyond what the schema provides. 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?

The description states a concrete verb+resource (scrape every open job from a company's Workday career site) and lists example companies, output fields and pricing, so an agent understands the domain. It is clearly distinguishable from the generic ats-jobs-scraper sibling by its Workday/myworkdayjobs.com focus, though it never explicitly contrasts the two.

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 hints at usage with 'Input: names or URLs; title, country, date filters' and pricing, but gives no explicit when-to-use/when-not-to-use guidance and no routing against the ats-jobs-scraper sibling. Usage 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.