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

With no annotations, the description must communicate behavior itself. It states the accessibility scope ('accessible to the user') and that it returns uids, implying a read-only enumeration. It doesn't mention edge behaviors like empty results or pagination, but for a simple list tool the disclosure is minimally adequate.

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 compact sentence front-loads the action and resource, then adds the only additional useful information (uid usability). 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?

For a 0-parameter tool with no output schema or annotations, the description tells the agent what the result is (accessible calendars with uids) and how to use it downstream. It leaves minor details (e.g., fields returned for each calendar) to the output, but this is sufficient for selecting and invoking the 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?

The tool has zero parameters, so the baseline is 4. The description adds relevant context about the returned uid, but there are no parameters to document.

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 begins with a specific verb ('List') and a precise resource ('BlueMind calendars accessible to the user'). It also clarifies the output's purpose ('uid usable with search_events / list_events'), which distinguishes it from email-focused siblings like list_mail_folders and search_emails.

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 doesn't explicitly enumerate when not to use it, but it establishes a clear workflow context: call this before search_events/list_events to obtain calendar uids. The resource scoping to calendars vs mail folders implicitly disambiguates among siblings.

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 behavioral burden. It adds the key recurrence behavior: recurring events are returned as series with their recurrence rule and occurrences might need expansion. It does not cover output format or pagination, but for a read-only listing that is a minor 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?

Three short sentences, no filler, with the core purpose first and the non-obvious recurrence behavior right after. Every sentence 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 simple list tool with full parameter schema coverage, the description covers the important operational facts: range, default calendar, and recurrence behavior. It is slightly incomplete because there is no output schema and it doesn't mention result shape, sorting, or how search_events differs, but these are not blockers.

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 input schema already documents all 4 parameters at 100% coverage, so the baseline is 3. The description's note about defaulting to the user's default calendar repeats the calendar_uid schema default, and it adds no syntax or format details for date_min/date_max beyond what the schema provides.

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 action and resource: 'List calendar events in a date range' with 'agenda view', so an agent knows it is a broad chronological listing. It does not explicitly contrast with search_events, so it misses the top-level sibling differentiation needed for a 5.

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?

'Agenda view' and the date-range framing imply it is for browsing all events over a period, but the description never says when to use this over search_events or mentions exclusions. The usage context is present implicitly, not 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?

There are no annotations, so the description carries the behavioral disclosure burden. It does disclose that the tool returns folders with uid and full name and the word 'List' signals a read-only action, but it does not mention details like folder hierarchy, inclusion of system folders, ordering, or side effects. This is adequate but not rich.

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 sentence that states the action, the resource, examples, and the returned information. Every part is useful and there is no redundancy or 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?

For a parameterless listing tool, the description is complete: it names the resource and the output fields. With no annotations, no output schema, and no parameters, there is little else an agent needs to call it appropriately.

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 has zero parameters and the schema is empty, so there is no parameter meaning to explain. The description correctly focuses on the result fields instead, making the tool's use obvious.

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 uses a specific verb ('List') and names the resource ('mail folders of the BlueMind mailbox') with examples (INBOX, Sent) and the output fields (uid, full name). This clearly distinguishes it from sibling tools that deal with emails, calendars, or events.

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 usage context is implied: use it when you need the mail folders of a BlueMind mailbox. However, there is no explicit guidance about when not to use it or how it relates to sibling tools like list_recent_emails or search_emails, leaving some routing 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?

No annotations exist, so the description carries the burden, and it does well: it discloses ordering, default folder selection, and the output contract that returned identifiers are suitable for read_email. It omits pagination/error behavior, but for a simple non-destructive listing tool the core behavior is transparent.

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?

Two tight sentences with no filler. The main behavior and key output detail are front-loaded, and every clause adds value.

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 simple, all parameters are optional and schema-documented, and the description tells the agent what to do with the returned identifiers despite the lack of an output schema. It is complete enough for correct invocation, with only minor room for stronger sibling differentiation.

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 parameters are already well documented. The description reinforces the INBOX default and the usable output identifiers but does not add substantial meaning 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 operation — list recent emails — with folder scope, default INBOX, and newest-first ordering. The returned identifiers and reference to read_email clarify the tool's role and help distinguish it from search_emails.

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 clear context for use: browsing recent emails in a folder, defaulting to INBOX, and feeding results into read_email. It does not explicitly name alternatives or state when not to use it, but the intended usage is readily inferable.

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 behavior disclosure. It communicates that this is a read-only retrieval operation and explains what the response will contain: headers, text body, and attachment list. It does not detail edge cases or the effect of prefer_html, but the absence of side effects is clear.

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 compact sentence with no filler. The core action and return contents are front-loaded, and the parameter provenance is wrapped in a concise parenthetical.

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 explains the likely return shape well enough (headers, text body, attachment list) and identifies how to obtain the required IDs. It could be more explicit about headers/attachment list details and the prefer_html behavior, but nothing essential is missing for a straightforward read operation.

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 schema already explains each parameter. The description adds meaningful provenance by stating that folder_uid and item_id come from search_emails or list_recent_emails, which helps an agent supply valid values. prefer_html is not mentioned in the description, but its schema description is sufficient.

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 ('Read'), a clear resource ('an email'), and enumerates the returned content (headers, text body, attachment list). It also names the source tools for the required IDs, so an agent can distinguish it from search/list tools without opening the 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?

The parenthetical 'from search_emails or list_recent_emails' clearly signals the intended workflow: first locate emails via those sibling tools, then read full content with this tool. It does not explicitly contrast this tool with alternatives, but the prerequisite relationship is clear.

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. It discloses meaningful traits: default behavior (all folders searched), query semantics (plain words hit body, field targeting supported), restriction options, and the return payload linkage (folder_uid + item_id). While it doesn't discuss pagination subtleties or error cases from malformed queries, it covers the core behavioral surface well for a no-annotation tool.

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 purpose, then flows logically from syntax to default scope to restriction options to return value. It is slightly long, but the query-syntax examples earn their place given they materially improve the agent's ability to form correct queries. No filler or redundant restatement of schema fields.

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 wisely discloses the key return fields (folder_uid + item_id) and their downstream use with read_email. It covers query semantics, default scope, and restriction params. Minor gaps remain, such as sorting behavior and the full shape of the response, but the description is well-proportioned to the tool's moderate complexity and 100% schema coverage.

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%, establishing a baseline of 3, and the description adds genuine value on top: concrete Elasticsearch syntax examples (subject:report, from:alice, has:attachments, is:unread, AND/OR composition) teach an agent how to construct effective queries beyond the schema's terse 'query_string syntax' note. It also clarifies the folder_uid vs folder_name distinction. This exceeds the baseline.

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 opens with a specific verb and resource: 'Full-text search of emails in the BlueMind mailbox.' This clearly distinguishes it from siblings like list_recent_emails (listing vs searching), read_email (reading vs searching), and search_events (events vs emails). The scope is precise and the differentiation from sibling tools is immediately evident.

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 provides clear operating context: the query is Elasticsearch query_string syntax, all folders are searched by default, and folder_uid or folder_name restricts scope. It also signals a downstream workflow by noting results are 'usable with read_email.' It doesn't explicitly name exclusions or when-not-to-use conditions versus alternatives, but the context is strong enough that an agent can infer appropriate invocation.

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 behavioral disclosure burden. It does explain what fields are searched, the optional date range, and the default calendar behavior. However, it does not describe result ordering, whether pagination is applied beyond schema defaults, or the shape of the returned events, which are meaningful behavioral details for a search tool.

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?

Two compact sentences with no filler. The core action and scope come first, followed by the key default behavior. Every word adds 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 search tool with a fully documented schema and no output schema, the description covers the essential context: searchable fields, optional date filtering, and the default calendar. It could mention result ordering or pagination, but those are partially inferable from the schema's limit/offset descriptions, so the gap is not critical.

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. The description adds value by specifying that query text spans summary, description, location, and attendees, which is richer than the schema's generic 'Text to search for'. It also clarifies that date_min and date_max form an optional date range and that calendar_uid defaults to the user's default calendar.

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 clearly identifies the verb (search), the resource (calendar events), and the search scope (summary, description, location, attendees). It also distinguishes this from list_events by emphasizing text-based search, making the tool's purpose 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?

The description gives clear context: use this when searching calendar events by text, optionally constrained by a date range. It does not explicitly name alternatives or state when not to use it, but the phrase 'Search calendar events by text' makes the intended usage evident relative to sibling list tools.

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