omniseek_curator_act

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, and it does so extensively. It discloses safety gates ('every safety gate lives in the impl, unchanged'), mechanical refusals ('MECHANICALLY REFUSES an admit on hard red-line / incomplete evidence'), reversibility for live actions ('REVERSIBLE overlay row'), and side-effect boundaries ('does NOT apply', 'does NOT admit, only surfaces'). It also clarifies that stage_commit only prepares text and does not apply it, and that wall_probe only surfaces content and never admits. These details go well beyond a simple action description and are highly valuable for an agent.

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 long but well-structured with each verb on its own line, making it scannable. It front-loads the purpose and then breaks down actions logically. While it is verbose, the complexity of 18 parameters and multiple verbs justifies the length. There is some redundancy (e.g., repeating the fully-qualified name), but overall it is efficient for the information density required.

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 complexity, the description is nearly complete. It covers all verbs, required parameters, safety gates, and side effects. It also clarifies the fully-qualified MCP name. The main gap is that it does not explicitly describe the return value for successful calls (though it mentions 'packet' for probe and wall_probe, and an error dict for unknown verbs). Since there is no output schema, this would be helpful but is not critical for correct invocation. Overall, it provides enough context for an agent to use the tool correctly.

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 does thoroughly. For each verb, it lists the required parameters (e.g., submit requires name, urls, mode, domain, family; optional kind, regions, rationale, draft) and explains their semantics (e.g., mode enum values, draft as a working artifact, baseline_ref required for admit). It also explains how parameters affect behavior (e.g., confirm for retire_live toggles preview vs. write). This gives an agent clear meaning for all 18 parameters, even though they are not individually documented 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?

The description opens with a clear, specific statement: 'Use WHEN acting on the source-curation protocol — WRITE a source-lifecycle action'. It names the resource (source-curation protocol) and the action class (write lifecycle actions), and lists all specific verbs (submit, probe, decide, etc.), making it immediately distinguishable from sibling tools like omniseek_curator_view or omniseek_sources, which are read-oriented. The distinction is further reinforced by explicitly saying 'WRITE'.

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 states when to use the tool ('WHEN acting on the source-curation protocol') and provides per-verb guidance on when each action is appropriate. For example, it explains that wall_probe is for client-rendered shells and that apply_live is only for rss-safe subclass, while stage_commit is for non-auto families. It also notes that non-auto families are refused and directs to stage_commit as the alternative, and even clarifies that there is no 'omniseek-eye' server to avoid confusion. This gives an agent explicit routing among verbs and implies when not to use the tool (for reads).

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