zuckerbot_export_leads

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

No annotations were provided, so the description carries the full burden of behavioral disclosure, and it does so exceptionally. It documents the bare-id semantics versus Meta's CSV 'l:' prefix, UTC and inclusive date semantics, the exact permission requirement, the error behavior when permission is missing, and the truncation/cap behavior. Nothing in the description conflicts with the structured information.

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 front-loaded with the core purpose and each subsequent sentence earns its place by addressing a specific operational concern. It is dense and information-rich without becoming bloated or redundant.

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 there is no output schema, the description provides the minimum necessary return expectations, date handling, permission requirements, CSV-ID caveat, and pagination/truncation behavior. It also routes the agent to the correct sibling for metadata, making this roughly complete for correct invocation and interpretation.

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?

The schema already documents all three parameters, so the baseline is 3. The description adds meaning by clarifying that dates are inclusive and by telling the agent where to obtain form_id values. This is genuinely useful, but the schema still carries most of the parameter-level burden.

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-resource operation ('Export lead submissions from a Meta instant form') with date range and an explicit list of returned fields (id, created_time, submitted field values). It is clearly distinguishable from the sibling list tools, especially by pointing the caller to zuckerbot_lead_forms for finding form ids.

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 tells the agent when the tool is appropriate, how to obtain the required form_id, and what to do when results are truncated: narrow the date range and re-call. It also names the permission prerequisite, so the agent can route errors to the correct remediation without guessing.

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