Content Calendar Agent by Nova (CIVAI)

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

With no annotations, the description carries the full burden and does well: it discloses the return shape ('deleted true/false'), the scope limit (this session only), the non-effect on already-generated public files, and an input safety rule ('Never accept path-like ids'). It omits irreversibility and any permission/auth requirements, which is the remaining gap for a destructive operation.

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?

Four dense sentences, zero filler, with the core action and scope front-loaded and the caveats and safety rule following in priority order. Every sentence carries distinct information.

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?

For a two-parameter delete tool with no output schema and no annotations, the description supplies scope, side effects, return value, and input constraints — everything needed to call it correctly. Return values are covered in prose precisely because no output schema exists.

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 already 100%, so the baseline is 3, but the description adds real meaning: preview_id must come from list_previews/get_preview in THIS session and must never be path-like — a validation constraint not stated in the schema. It says nothing extra about notification_message, hence not a 5.

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 ('Delete one stored PDF draft') scoped precisely by 'preview_id from this chat session only', which separates it from the list/get/generate siblings. The session-only qualifier and the id type make the operation unambiguous.

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?

Provides clear context: agent-only (hidden from suggestion buttons) and session-scoped, and adds an exclusion ('Does not remove already-generated public PDF files') that tells the agent when this is the wrong tool. It does not explicitly name the sibling to use for deleting public PDFs, so it stops short of full when/when-not routing.

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

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

With no annotations, the description carries the burden and does well: it discloses the two response modes (needs_selection + previews list vs immediate generation) and the pdf_url return. It does not say whether generation consumes/invalidates the preview (relevant given the delete_preview sibling) or what happens if the preview_id is stale.

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?

Three tight sentences leading with the action, then the branching flow, then the success output. Every sentence carries operational information with no padding.

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?

No output schema exists, so the description must explain returns and it does (needs_selection, previews with title+preview_id, pdf_url). Combined with no annotations, the main remaining gap is error/failure behavior (e.g., no previews at all).

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 100% and both parameters are fully documented in-schema, so baseline 3 applies. The description reinforces preview_id's omit-to-list-or-generate semantics, but says nothing about notification_message beyond what the schema already states.

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: 'Generate a PDF from a preview.' An agent can immediately tell this is a generation action distinct from the listing/fetch siblings, though no sibling is named explicitly for differentiation.

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?

Gives an explicit call sequence: invoke with no args first, branch on the result (multiple previews -> ask the user and re-call with preview_id; single preview -> generates immediately). This is a complete when/how procedure rather than an implied one.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the two possible return shapes, the required display layout (P, interaction_mode none, numbered picker), and prohibited follow-up calls. It omits any error/permission behavior, but for a UI-flow read tool the behavioral picture is unusually complete.

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 the tool's identity and sequenced instructions in a compact block with no filler. Some clauses are dense run-ons with internal jargon (layout P, interaction_mode none), which slightly hurts readability but not economy.

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?

There is no output schema, so the description must explain returns — it names document_markdown, needs_selection, and previews, which covers the branching outcomes. It does not describe the shape of items inside previews or failure modes, leaving a modest gap for a stateful interaction tool.

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 100%, so both parameters are already documented with conditional usage notes (omit on first tap, pass after selection). The description restates that sequencing rather than adding new semantics such as format or validation rules, so the baseline 3 applies.

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?

Identifies the trigger (Preview PDF button) and the resource (PDF drafts), and immediately states the branching return behavior (single draft → document_markdown; multiple → needs_selection + previews). It is clearly distinct from siblings like pdf__list_previews and pdf__generate_pdf, though it never explicitly contrasts itself with them.

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?

Explicitly prescribes the call sequence: no-args first to enumerate drafts, then a second call with preview_id only after the user replies with a number/title. It also states hard exclusions (NEVER collect_user_input or emit_display input for preview_id), which is exactly the when-not guidance an agent needs.

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

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

With no annotations, the description carries the burden and does well: it discloses the session-scoped nature, the concrete return shape, and critically what is NOT returned (document body). It stops short of stating read-only safety or any permission/rate-limit behavior, which leaves a small gap for a tool with zero annotation coverage.

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?

Three tight sentences, front-loaded with purpose, then return shape, then usage. No redundant restatement of title or name and no filler.

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?

There is no output schema, but the description enumerates the returned fields (previews, count, most_recent_preview_id) and the follow-up flow, so an agent has everything needed to call it and act on the result.

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 100% for the single notification_message parameter, so the schema already carries its meaning; the baseline of 3 applies. The description adds no param-level detail, which is acceptable given the coverage.

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 (List) and resource (stored PDF drafts) with explicit scope (this session), and even names the return payload. An agent can distinguish it from pdf__get_preview and pdf__delete_preview without opening any schema.

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?

Gives explicit triggering conditions ('user taps List PDFs or asks which drafts exist') and an explicit boundary plus next step ('Does not show document body — follow with get_preview after they pick'). This is exactly the routing guidance an agent needs.

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

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

With no annotations, the description carries the burden and does well: it discloses the mutation semantics (write/revise), the side effect (a preview_id is created), the session-scoped storage, and a hard content constraint. It leaves some gaps — it never says whether revising overwrites prior pages, whether previews expire, or what happens on failure.

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?

Four dense sentences, fully front-loaded: the core action first, then usage trigger, then the sibling alternative, then the hard constraint. Nothing is redundant padding.

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?

For a 4-param write tool with no output schema and no annotations, the description covers action, trigger, alternative, and key constraints, which is nearly enough. The remaining gap is error/overwrite behavior, which is not covered anywhere in the structured data.

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 100%, so the baseline is 3 and the schema already explains title, content, update_preview_id, and notification_message. The description reinforces the create-vs-revise meaning of update_preview_id and the content rules, but adds no syntax or format detail beyond 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?

States a specific verb+resource+effect: 'Write or revise draft markdown into session storage (creates preview_id).' It explicitly distinguishes itself from the sibling pdf__get_preview ('For showing an existing draft use get_preview'), so an agent can route correctly without opening either schema.

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?

Gives an explicit when-to-use trigger ('when the user asks to create/write/edit document content') and names the alternative for the opposite case (viewing an existing draft → get_preview). It also clarifies the audience constraint ('Agent-only — not a suggestion button'), removing an ambiguity an agent would otherwise have to guess at.

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

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

With no annotations provided, the description carries the full burden. It never says whether calling this has side effects, what the reply contains, or that it deliberately produces no artifact. For a tool whose whole behavior is 'respond with text instead of doing work', this disclosure is essential and absent.

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 front-loaded sentence with no filler; the condition precedes the action. It is appropriately sized but so terse that the ambiguity of what 'converse' means is never resolved.

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 tool is structurally simple (one optional param, no output schema), so the bar is lower, but the description still omits what the reply is, whether this is a fallback vs. a normal path, and how it relates to the slide/pdf siblings — real gaps for an agent deciding whether to call it.

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 100% for the single optional reply_hint parameter, so the schema already documents it. The description adds no additional meaning about how the hint shapes the reply, which matches the baseline-3 rule for high coverage.

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 names an action ('reply conversationally') and a trigger condition (ambiguous request), but 'converse' largely restates the tool name and never says what the reply actually is or that no slide/graphic is produced. It does not explicitly distinguish itself from the sibling generation tools, leaving the agent to infer it is a fallback.

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?

It gives a clear trigger: use when the request is ambiguous or needs clarification. That implicitly tells the agent not to use this when the request is clear, but it names no alternatives (e.g. slide__generate_image) and states no exclusions explicitly.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses nothing: no output format, no size/style constraints, no rate limits, no auth needs, no indication of whether generation is synchronous or how results are returned. For a generation tool this is a complete behavioral void.

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 single fragment is short but under-specified rather than concise: it carries a decorative emoji and a redundant 'Slidegen' prefix instead of substance. There is nothing to front-load because no useful content exists.

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 tool has low structural complexity (one optional parameter, no nested objects, no output schema), so the bar is low, but the description still fails to convey what an image generation call produces or how 'detail' shapes it. No output schema exists, so the description should at least hint at the return, and it does not.

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 100%, so the single 'detail' parameter is documented in the schema itself. The description adds no meaning about what 'detail' should contain, which is the baseline-3 case when the schema does the heavy lifting. The vague parameter name 'detail' means the description could have added real value here but does not.

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 generic verb+resource ('generate image'), so the basic purpose is inferable. However, it does nothing to distinguish this tool from its close siblings slide__generate_single_graphic and slide__generate_multiple_graphics, leaving the agent unsure which image/graphic generator applies. Clear enough to be viable, but with an obvious differentiation gap.

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?

There is no when-to-use, when-not-to-use, or alternative guidance of any kind. The agent gets no signal on how this differs from slide__generate_single_graphic, slide__generate_multiple_graphics, or slide__converse, all of which plausibly produce visual output.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure, and it discloses nothing: no side effects, no count of graphics generated, no format or size limits, no auth or cost implications. For a generation tool that presumably produces artifacts, this is a complete gap.

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 a single short line with no wasted words and is front-loaded, but its brevity reflects under-specification rather than disciplined conciseness.

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 one vague parameter, no annotations, and no output schema, the description should at minimum explain what gets generated and in what quantity. It supplies none of that, leaving the agent unable to predict the tool's behavior or output.

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 100%, so the baseline is 3. However, the lone optional 'detail' parameter is described only as 'Specific parameters for this action,' which is a catch-all with no real semantics; the description adds nothing to clarify it.

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 '🖼️ Slidegen: generate multiple graphics' essentially restates the tool name (generate_multiple_graphics) with an emoji and brand prefix, adding no detail about what a 'graphic' is, how many are produced, or what the operation actually does. It only weakly distinguishes itself from slide__generate_single_graphic via the word 'multiple'.

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?

There is no guidance on when to use this tool versus siblings such as slide__generate_single_graphic or slide__generate_image. No prerequisites, no exclusions, and no context about when multiple graphics are appropriate over single ones.

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

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

No annotations are provided, so the description carries the full burden, and it discloses nothing: not what kind of graphic is produced, not the output format, not whether it is asynchronous or costs a call, not side effects. Just 'generate single graphic'.

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?

It is short and front-loaded, so nothing is bloated. But the brevity comes from under-specification rather than economy: every sentence (there is effectively one fragment) fails to earn its place beyond a label.

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?

For a generation tool with no annotations, no output schema, and an opaque 'detail' parameter, the description should explain at minimum what it produces and how it differs from the multiple-graphics and image siblings. It supplies none of that.

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 100% (a single 'detail' param described as 'Specific parameters for this action'), and 0 params would be a baseline 4. The description adds no meaning to 'detail' at all, so the schema must do all the work, making the 3 baseline appropriate.

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 restates the tool name ('generate single graphic') with only an emoji prefix added. The word 'single' faintly distinguishes it from sibling slide__generate_multiple_graphics, but the description never makes that contrast explicit. It is essentially a tautology of the name.

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?

No guidance on when to use this tool versus slide__generate_multiple_graphics, slide__generate_image, or slide__converse. No prerequisites, no context, no exclusions. An agent must guess purely from the name.

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