x_review_export

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

The description discloses critical behavioral traits beyond the annotations: operations are local declarations, not proof of human approval or truth, never contact X, and never open a session. It also reveals that preview mode surfaces partial-result warnings and that export requires explicit acknowledgment, giving the agent a strong safety model.

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 dense but well organized into without-review and with-review paths, followed by a crucial safety caveat. Every sentence adds distinct value, and no space is wasted on restating the tool name or input schema.

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?

The description is sufficient for a complex nested-parameter tool with no output schema: it covers both modes, prerequisites, output formats, and local-only behavior. It does not describe the exact export response shape, but the main workflow an agent needs to invoke correctly is fully explained.

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?

With 0% schema description coverage, the description must carry parameter meaning. It explains the review workflow components: snapshotDigest is required for export, acknowledgedPartial must be true, note and format are involved, and recordIds correspond to the user-reviewed IDs. It could more explicitly define snapshotId, but context makes it clear enough.

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 both operational modes: a read-only preview of a local snapshot without review, and a reviewed export that writes user-approved IDs as JSON or CSV. It also differentiates itself from nearby tools like x_export by emphasizing that all operations are local and never contact X.

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 tells the agent when to preview (without review) versus when to export (with review), and states required conditions such as snapshotDigest and acknowledgedPartial=true. It does not explicitly name an alternative tool for the no-review export case, but the mode-based guidance is clear enough.

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