export_keynote_to_pdf

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. It hints at macOS Keynote automation but never states that Keynote must be installed, that macOS is required, that the export writes files into the harvest root, or what happens when the .key file is missing or Keynote is unavailable. The phrase 'using macOS Keynote automation' gestures at the dependency but does not disclose 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?

A single, complete sentence that front-loads the purpose with zero filler. Every word carries meaning — verb, source format, target format, and mechanism in one pass.

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?

This is a 7-parameter automation tool with no annotations and no output schema, yet the description is one sentence. It omits the macOS/Keynote prerequisite, permission requirements (automation/accessibility prompts), output location defaults, and side effects. For a tool of this complexity, the description should be substantially richer.

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 only 43%, below the 50% threshold where the description must compensate. Four parameters (slug, title, redactionMode, keynoteAppPath) are undocumented in both the schema and the description. The description's 'native Keynote .key file' phrase maps weakly to keynotePath but adds nothing about the other three undocumented parameters.

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 specific verb (Export), resource (.key file), target format (PDF), and mechanism (macOS Keynote automation). This clearly distinguishes it from its closest sibling harvest_keynote_pdf, which implies collecting already-exported output rather than converting a native file.

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 core use case is evident from the verb-object construction, so an agent can infer when to call it. However, the description gives no explicit guidance about when NOT to use it or which sibling covers the complementary case (harvest_keynote_pdf is never named as the alternative for already-generated PDFs). Guidance is implied, not stated.

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