preview_save_job

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

With no annotations, the description carries the full burden, and it does disclose the capability-gating and default-disabled state, which is non-obvious and valuable. It stops short of the most important behavioral fact for a preview tool: that it validates without persisting the save, and what the preview returns. That omission is significant given 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, front-loaded with the purpose and followed by the gating condition. Nothing is redundant or padded.

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 preview-safety tool with no annotations, no output schema, and no parameter documentation, the definition is thin. It should state that no mutation is persisted and what a successful preview yields, since nothing else in the structured data conveys that.

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, and it adds no meaning for either parameter. It says nothing about the `changes` array (per-field set/remove operations, 1-25 items) or the `provider` enum of linkedin/naukri, leaving an agent to infer the payload shape entirely from 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: 'Preview a save_job mutation.' That distinguishes it from the execution siblings such as execute_confirmed_mutation. It does not explicitly contrast with the other preview_* tools (e.g., preview_application_submission), but the 'save_job' resource is specific enough for selection.

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 supplies a real precondition: disabled by default, available only when the provider advertises an approved mutation capability, which usefully points an agent at discover_provider_capabilities. However, it never states the follow-on flow (that a preview precedes execute_confirmed_mutation) or when an agent should call preview rather than skip it, leaving the workflow implied.

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