Nova Inbox 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. It usefully discloses the sending address and that composition is deterministic, but says nothing about the fact that sending is an irreversible side effect, required permissions, or failure behavior. Schema covers body/attachment constraints, so the gap is behavioral rather than structural.

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 zero filler; the verb and the distinguishing constraint ('deterministic; no LLM draft') both land immediately.

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 send tool with no annotations and no output schema, the description is thinner than ideal: it does not address irreversibility, auth/permission requirements, or what success looks like. The richly documented 7-parameter schema compensates for most structural needs, leaving only these behavioral gaps.

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% across all 7 parameters, including the html/text/subject relationship and attachment limits, so the schema does the heavy lifting. The description adds no parameter-level meaning beyond the schema, which matches the baseline 3.

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 (Send), resource (outbound email), and scope (from the user's @nova.civai.co address), and adds 'deterministic; no LLM draft' which implicitly separates it from the sibling 'converse'. It stops short of naming the alternative sibling explicitly, so it is clear but not maximally differentiated.

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 phrase 'no LLM draft' hints at when this tool is appropriate versus a draft-generating sibling, but there is no explicit when-to-use/when-not guidance, no mention of prerequisites, and no routing instruction. Usage is implied rather than stated.

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. It says nothing about whether this ends the turn, whether it mutates state, whether it should be combined with other tool calls, or what the reply consists of — significant gaps for a tool with zero structured behavioral 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?

A single tight sentence that front-loads the action and appends the trigger condition; nothing is wasted. It is efficient, though it is efficient at a fairly low level of detail.

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 low-complexity (one optional param, no output schema), so the short description is defensible, but with no annotations and no output schema the description should at least clarify the conversational fallback's role in the turn lifecycle. It stops just short 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?

There is one optional parameter (reply_hint) whose schema description already covers it at 100% coverage, so the baseline of 3 applies. The description adds no syntax, format, or influence guidance beyond what the schema already supplies.

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?

It gives a verb ('reply conversationally') and a trigger condition ('when the request is ambiguous or needs clarification'), which separates it from the calendar siblings by function. However, the 'resource' is nebulous — there is no statement of what the reply acts on or produces, so the agent must infer it is a non-action 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?

The description names one condition for use: ambiguity or need for clarification. It implies, but never states, that the event-management siblings (add/update/delete/check events) are the alternative when the request is clear, leaving the when-not boundary to inference.

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. It usefully discloses the return encoding (base64) and that exactly one attachment is retrieved, but says nothing about attachment size limits, failure modes, or permission/auth requirements for downloading attachments.

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?

One tight sentence with the action, the result format, and the selection options front-loaded. No filler or redundancy.

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, and the description correctly supplies the key return detail (base64), which is what an agent needs to handle the result. It stops short of covering error/size behavior, but is adequate for a simple single-attachment fetch 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 the baseline is 3, but the description adds meaning: drive_id and index are presented as alternative selectors on the required message_id, clarifying they are two addressing paths rather than required companions.

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 ('Download one email attachment') plus the return encoding ('as base64') and the two addressing modes. It is clearly distinguishable from read_message and list_messages, which surface message metadata rather than attachment content.

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?

Usage is implied rather than stated: the agent can infer this is the tool to fetch attachment bytes, and the description notes the two ways to select an attachment. There is no explicit when-to-use/when-not guidance nor any mention of the sibling tools.

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 burden, and it never explicitly states that this is a read-only, side-effect-free lookup with no arguments. That is strongly implied by 'Return', but there is no mention of auth requirements, caching, or stability of the returned address across calls.

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 sentence that is front-loaded with the verb and resource, with no filler. Every word earns its place.

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 zero-parameter, no-output-schema getter, the description supplies enough to call it correctly and even hints at the return format. Only minor omissions (read-only nature, auth context) remain.

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 tool takes zero parameters, which sets the baseline at 4. The description usefully documents the return format with an example (user@nova.civai.co), adding value beyond the empty 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 (Return) and a specific resource (the user's Nova Inbox email address) plus a concrete example format. It does not explicitly differentiate from siblings, but none of the sibling tools (compose_message, read_message, etc.) are confusable with an address lookup, so differentiation is implicitly handled.

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?

Usage is only implied: an agent can infer it should call this when it needs the user's inbox address, but the description never states when to use it or when not to. There are no natural alternatives to route against, so this gap is minor.

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. It does disclose a meaningful behavioral constraint (only the @nova.civai.co inbox is covered), but says nothing about ordering, pagination, whether sent/outbound messages are included, or the shape of results for a read 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?

A single front-loaded sentence with zero filler or redundancy. It is appropriately tight, though its brevity contributes to the gaps noted in other dimensions.

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 and no annotations, the description should compensate by covering return behavior and constraints; it covers inbox scope but omits ordering, pagination, and result format. All three parameters are schema-documented, so the remaining gap is behavioral rather than structural.

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%, with limit, query, and unread_only all documented inline (including the 1-50 range and default). The description adds no parameter meaning beyond the schema, 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?

States a specific verb (List) and resource (messages) scoped to the signed-in user's Nova Inbox, which is clear and unambiguous. It does not differentiate itself from siblings such as list_thread or read_message, so an agent gets no help choosing among the message-reading tools.

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 gives no when-to-use guidance, no prerequisites, and never names the alternatives (read_message for a single message, list_thread for a threaded view). Scope is implied by the phrase 'signed-in user's Nova Inbox' but nothing tells the agent when this tool is the right pick.

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 behavioral burden. It does add real value by disclosing ordering (oldest first) and that both inbound and outbound messages are included. However it says nothing about pagination, result limits, permissions, or behavior when the thread is empty or the id is invalid.

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 tight sentence with the scope qualifiers front-loaded. Every clause earns its place — verb, resource, inclusion rule, and ordering are all packed into one line with zero waste.

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 simple 2-parameter read tool with no annotations and no output schema, the description covers scope and ordering adequately. It is still silent on what happens when neither optional parameter is supplied and on return size/pagination, which an agent would want before invoking.

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 both parameters are already documented in the schema, including that message_id and thread_key are alternatives. The description adds no parameter-level detail beyond that, which is the expected baseline when the schema does the heavy lifting.

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 (messages in an email thread) with useful scope qualifiers: inbound + outbound, oldest first. It implicitly distinguishes itself from list_messages by operating on a whole thread, though it never names that sibling explicitly.

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?

Usage is only implied by the word 'thread' — an agent can infer this is for retrieving an entire conversation rather than a mailbox. There is no explicit when-to-use guidance, no statement of when to prefer read_message or list_messages instead, and no mention of prerequisites.

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. It does disclose the content scope returned (full body plus attachment metadata), which implies a safe read, but it omits any side effects (e.g. whether reading marks the message read), error behavior for invalid ids/indices, and any permission requirements.

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 sentence that front-loads the verb and target, then attaches the lookup modes and return scope as parenthetical detail. Nothing is wasted.

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 two simple parameters, no annotations, and no output schema, the description covers purpose and return content (body and attachment metadata), which is what an agent most needs. It stops short of side-effect and failure-mode information, a minor gap for a read 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 description coverage is 100%, and both parameters are documented as coming from list_messages results. The description restates the same origin (id or list index) without adding syntax, precedence, or behavior details beyond the schema, 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?

States a specific verb (read) and resource (one Nova Inbox message) with the two lookup modes (id or list index) and the return scope (full body, attachment metadata). 'One ... message' implicitly distinguishes it from list_messages and list_thread, but no sibling is named explicitly.

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?

Usage is only implied: you read a single message, presumably after list_messages produces an index or id. There is no explicit when-to-use, when-not, or named alternative such as list_messages for bulk retrieval.

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