Creates a no-shell local worker job record in the issueops worker state directory so tasks can be queued without executing shell commands.
Create a no-shell local worker job record. This writes only to the issueops worker state directory and never executes shell commands.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | ||
| payload | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already say it is not read-only, not destructive, not idempotent and not open-world. The description adds real value on top: it scopes the write to the issueops worker state directory and rules out shell execution, which is precisely the fear an agent would have with a tool named 'worker_enqueue'. It does not say what happens on duplicate enqueue, which the non-idempotent hint makes relevant.
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 with the purpose first and the two most important constraints immediately after. No boilerplate, nothing that can be trimmed.
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 parameter documentation, the description carries the whole burden and only covers one of the two concerns. The side-effect story (writes only to the worker state directory, no shell) is complete, but the input contract (kind values, payload format) and the absence of a stated return value leave the agent short for a two-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description says nothing about either parameter. 'kind' is required but its accepted values are never given, and 'payload' (a string, format unspecified) is not mentioned at all. This is the definition's largest gap, since the agent cannot know what to pass for kind or how to encode payload.
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: 'Create a no-shell local worker job record.' The phrase 'job record' plus 'never executes shell commands' distinguishes it from execution-oriented siblings such as worker_run_read_only. It stops short of naming those siblings explicitly, so an agent must infer the boundary.
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 when-to-use or when-not-to-use statement, and no alternative is named. The contrast with shell execution is implied by the 'no-shell' framing, which suggests this queues a record for something else (worker_run_read_only, worker_status) to act on, but the agent has to work that out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.