notion_personal_submit

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

Goes well beyond the annotations: it discloses return identifiers (job_id, thread_id), states the idempotent dedup behavior that the idempotentHint only implies, warns that external responses are data rather than instructions (prompt-injection hygiene), and explains that long answers land in answer_path/code_artifacts rather than the tool output. This is exactly the kind of behavioral context annotations cannot carry.

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?

Front-loaded with purpose first, then output behavior, then safety and retry rules. Every sentence carries distinct information with no padding, though the telegraphic staccato style makes the stream of constraints slightly harder to scan than a grouped structure would be.

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?

With no output schema, the description fully carries the return-value burden: it names both durable IDs, explains where full answers are persisted, and advises reading the saved file for complete content. Combined with idempotency, timeout, and injection guidance, an agent has everything needed to call this 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 coverage is 67%, with prompt completely undocumented. The description adds meaning for request_key by explaining the dedup/reuse semantics, but it never explains the prompt vs. prompt_file choice, which is the schema's central oneOf constraint. Partial compensation for a real coverage gap.

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 and resource: 'Submit one authorized text task,' and scopes it sharply with 'Personal chat only; never Custom Agent.' It does not, however, name its siblings (notion_personal_ask/read/reply) or contrast its purpose against them, so the agent must infer the boundary rather than being told.

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?

Offers concrete operational guidance that few descriptions include: reuse request_key after errors, do not resend after a timeout, and never submit to a Custom Agent. These are clear when/when-not conditions, but they concern retry behavior only — there is no explicit guidance on when to pick this tool over the sibling ask/read/reply tools.

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