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 reveals that virtualization is bypassed and that conversation-IDs plus a preview are returned, but says nothing about read-only safety, pagination semantics of maxScrolls, cost of full enumeration, or permissions.

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, front-loaded with purpose and the virtualization caveat, followed by return contents. Nothing is redundant, though the tool name and description carry some overlap.

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 annotations and no output schema, the description should explain return shape, enumeration limits, and safe usage. It only partially covers returns (conversation-IDs + preview) and omits pagination behavior and the consequence of maxScrolls, so it is incomplete for the agent.

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%: folder's accepted values and maxScrolls' default of 140 are already documented in the schema. The description adds no syntax or format details beyond that, so it earns only 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?

States a specific verb and resource: it lists all emails in a folder and explicitly notes it overcomes message-list virtualization, which distinguishes it from siblings like outlook_list_recent. However, it never names those siblings, so an agent must infer which of the ten other tools it replaces.

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 when-to-use or when-not-to-use guidance. It does not contrast with outlook_list_recent or outlook_search, which are the obvious alternatives for listing or finding mail, leaving the agent to guess when scroll enumeration is preferable.

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 beyond the act of closing. It does not say whether the session/login is discarded, whether in-flight operations are aborted, whether a subsequent tool call relaunches the browser, or whether the call is idempotent if no instance is running.

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 short sentence with the action front-loaded and no filler. Nothing in it is 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?

For a lifecycle/teardown tool inside a suite of browser-backed outlook_* tools, the description omits the consequences an agent most needs: loss of session state, impact on other tools, and whether re-login is required afterwards. With no annotations and no output schema to fall back on, these gaps are unmitigated.

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, so there is nothing for the description to clarify beyond the schema. Baseline 4 applies for a parameterless tool.

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 a specific verb and resource ('Schließt die Hintergrund-Browserinstanz'), so an agent immediately knows this tears down the background browser. It does not differentiate itself from any sibling, but no sibling performs teardown, so the gap is minor.

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 explicit statement of when to call this versus keeping the browser alive, nor any prerequisite or sequencing guidance. Use is only weakly implied by the name and by the fact that other outlook_* tools need the browser instance.

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 does add valuable behavioral context by clarifying that the email is only drafted and must be opened and sent manually, which distinguishes a draft creation from a send operation. It says nothing about authentication requirements, whether an existing draft is overwritten, or error behavior.

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 short sentences, front-loaded with the core action and target folder, with no wasted verbiage. The second sentence is mildly hand-holding but earns its place by clarifying that sending is a separate manual step.

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 create-draft tool with a fully described schema and no output schema, the definition covers what the tool does, where the result lands, and that the user must send manually. It is complete enough to invoke correctly, with only minor gaps around auth and duplicate-draft handling.

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 all four parameters (to, cc, subject, body) are already documented with format hints like comma/semicolon-separated recipients. The description adds no additional parameter meaning beyond what the schema provides, making the baseline 3 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?

States a specific verb and resource ('Erstellt einen neuen E-Mail-Entwurf') and pinpoints the destination folder ('Ordner Entwürfe/Drafts in Outlook Web'). It is unambiguous, though it relies on the name rather than explicitly distinguishing itself from the read-only siblings (the tool set contains no other creation tool, so the risk is low).

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 second sentence describes the post-creation workflow ('open in Outlook, proofread, send'), which implies the tool is for staging emails that the user will send manually. However, it never states explicit conditions for choosing this tool over alternatives or any prerequisites (e.g. login), leaving usage only implied.

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 disclosure burden. It adds genuine value by naming the extraction surface (Markdown, Teams links, metadata), which tells the agent what comes back. It still omits whether authentication/session state is required (a sibling 'outlook_login' exists) and whether the read has any side effects such as marking mail as read or advancing the reading pane.

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 compact sentence with the payload enumeration up front and the default-index behavior trailing, which is the right ordering. Minimal waste, though the parenthetical list is slightly dense and the index clause is largely redundant with the schema.

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 compensates by describing the returned content (Markdown, Teams links, metadata), so the agent knows what to expect. Both parameters are covered by the schema. What is missing is any statement of required session/auth state or how it relates to the near-identical 'outlook_read_email' sibling.

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 'id' and 'index' are already documented in the schema. The description only restates the index-0 default, adding no syntax, precedence rules (what happens if both id and index are supplied), or format details beyond the structured fields; 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?

The description states a specific verb and resource ('Liest eine E-Mail ... vollständig aus') and enumerates the returned payload (Markdown, Teams-Links, Metadaten), so the agent knows exactly what the tool produces. However, it does not distinguish itself from the sibling 'outlook_read_email', which appears to read an email as well, leaving real overlap unresolved.

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 only usage hint is the default behavior ('Standardmäßig die oberste E-Mail (Index 0)'), which restates the schema default rather than explaining when to pick this tool. No condition selects it over 'outlook_read_email', 'outlook_search', or 'outlook_list_recent', and no prerequisites (e.g. prior login via 'outlook_login') are mentioned.

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 discloses that results include names and item counts, which is useful. But it doesn't state whether it requires authentication first (e.g., outlook_login), whether it's a read-only operation, or if there are rate limits.

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, well-formed sentence that front-loads the verb and resource and includes the relevant return details. No wasted words.

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 zero-parameter list tool with no output schema, the description is almost adequate. However, the lack of any usage guidance or behavioral context (like auth requirements) leaves gaps for an agent that must decide between this and outlook_navigate_folder.

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 are zero parameters, so the baseline is 4 per the rules. The description appropriately doesn't discuss parameters since none exist.

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 ("Listet") and resource ("Ordner im Navigationsbereich") and even enumerates the folder types returned. It distinguishes itself reasonably from siblings like outlook_navigate_folder, though it doesn't explicitly name an alternative.

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 – an agent can infer this is for discovering the folder structure before navigating or searching. However, there's no explicit when-to-use vs. outlook_navigate_folder or outlook_list_recent, and no stated 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 not state that the operation is read-only, what order results come in beyond "latest", whether read/unread matters, or whether results are truncated by limit. For a tool with zero annotation coverage this leaves real gaps.

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 short sentence with the key scoping information (newest, inbox) front-loaded and no filler. It is efficient, though arguably too terse given the unanswered behavioral questions.

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 (one optional param, no output schema, no nested objects), so little is required. Still, the description omits sorting guarantee, folder assumptions, and read-only status, which are the few things an agent would want for this call.

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 the single optional "limit" parameter is fully documented with a default of 10 in the schema itself. The description adds no additional semantics beyond what the schema already provides, 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?

The description gives a specific verb ("Listet") and resource ("E-Mails") with scope qualifiers: newest and inbox-only. That scope distinguishes it somewhat from search-style siblings, but it never names or contrasts with outlook_search, outlook_bulk_list, or outlook_read_email, so an agent must infer the boundary itself.

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 statement of when to use this tool versus outlook_search, outlook_bulk_list, or outlook_navigate_folder. The agent must infer that this is the default 'show me what's new' call from the name alone.

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 disclose meaningful traits: the window is visible, requires Edge/Chromium via WSLg/Desktop, and the login is one-time. It omits what happens after authentication (session persistence, whether it blocks, what it returns), which matters for an interactive auth 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?

A single, efficiently worded sentence with the key behavioral detail (visible browser window) front-loaded. No filler, though it is arguably slightly terse given the tool's interactive nature.

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 one-parameter auth tool with no output schema and no annotations, the essential trigger is conveyed. However, the post-login behavior and how it relates to the broader outlook_* session workflow are left unstated.

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 the single realm parameter is already documented with its default and examples in the schema. The description adds nothing about realm, so the baseline of 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 concrete verb and resource: opens a visible browser window for a one-time Microsoft 365/OWA sign-in. An agent can tell this is the interactive-authentication tool distinct from read/search siblings like outlook_list_recent, though it never explicitly names how it relates to 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?

The phrase 'damit du dich einmalig ... anmelden kannst' implies this is the setup step to run before authenticated operations, but there is no explicit statement of when to invoke it versus outlook_status (e.g. to check whether a session already exists) or any preconditions/exclusions.

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 does not say whether navigation persists as session state, whether it requires an authenticated session, or what happens on an invalid folder – all relevant for a state-changing navigation call.

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 verb and valid values appear immediately. It is appropriately sized for a one-parameter tool.

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 low-complexity one-parameter tool with no output schema or annotations, the description covers what the tool does and its accepted values. It is missing post-condition or session-state behavior, which an agent would need to know before relying on the navigation taking effect.

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 parameter is already documented. The description's enumeration of folder values (inbox|sentitems|archive|deleteditems|drafts|newsletter) adds a slightly more complete list than the schema's 'inbox, sentitems, archive, ...', but otherwise repeats structured data. 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?

The description gives a clear verb+resource ('Navigiert in einen Mail-Ordner') and enumerates the valid folder values, which directly matches the tool name. It does not explicitly distinguish itself from sibling outlook_list_folders, but the verb 'navigate' vs 'list' makes the distinction reasonably inferable.

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 explicit when-to-use guidance, no prerequisites (e.g., must already be logged in), and no named alternative such as outlook_list_folders for discovering folders first. Usage is only implied by the operation name.

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 a non-obvious trait: it auto-scrolls through the folder until the conversation is found, implying UI navigation side effects. But it omits whether reading alters folder/view state, what happens if the conversation is not found, and any auth/permission needs.

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 sentences, front-loaded with what the tool does and followed by the lookup/discovery behavior. No filler, though the parenthetical '(Markdown)' and '(data-convid aus bulk_list)' stack a lot of detail into one sentence.

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 UI-driven read tool with no output schema and no annotations, the description covers the return (Markdown in the reading pane) and the search-until-found behavior. It is still missing the differentiation from outlook_get_email and the failure/edge behavior, leaving the agent with meaningful unknowns.

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. The description adds only that the id is a conversation-ID sourced from bulk_list and that folder scopes the read, which largely restates the schema; baseline 3 is 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?

States a specific verb and resource ('Liest eine E-Mail vollständig im Lesebereich (Markdown) an') with a clear scope (full read, Markdown, reading pane). However, it does not distinguish itself from the sibling tool outlook_get_email, which an agent would reasonably assume reads an email too.

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 helpfully says the id comes from bulk_list ('data-convid aus bulk_list'), giving some usage context. But it never states when to use this versus outlook_get_email or outlook_search, so the agent must infer the distinction from names alone.

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 says nothing about whether this search is read-only (safe), what happens on zero results, whether it searches all folders or just the inbox, or any rate limits. For a search tool with no annotation coverage, this is a significant 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?

A single, front-loaded sentence that states the action, the target surface, and the input mechanism. No waste, and the key information (what it searches and how) comes first.

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 description is minimally adequate for a 2-parameter search tool with full schema coverage and no output schema. However, with no annotations and no behavioral context (read-only? scope?), an agent lacks important safety and scope information it can't infer from the schema.

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 both `query` and `limit` documented in the schema (limit's default of 10 and query's example terms are all in the schema). Baseline 3 applies 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?

The description states a specific verb ("Sucht") and resource ("E-Mails in Outlook Web") and clarifies the search is keyword-based. It doesn't differentiate itself from all siblings (e.g., outlook_list_recent, outlook_bulk_list), but the search-by-keyword scope is clear.

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 through the search-term examples (Kundenname, Ticketnummer, Absender), but the description never explicitly says when to use this tool versus outlook_list_recent or outlook_read_email. No alternatives or exclusions are named.

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 discloses the two things reported (connection status, login state), which is the core behavioral fact for a status check, but says nothing about side effects, required permissions, or what the result looks like.

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 connection-status check is stated before the login check, and nothing is 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?

For a zero-parameter status tool with no annotations and no output schema, the description conveys what is verified. It could go slightly further by hinting at the returned shape (e.g. a boolean or status string), since no output schema exists to cover 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?

The tool takes zero parameters, so schema semantics are a non-issue and the baseline of 4 applies. There is nothing for the description to disambiguate.

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: it checks the Outlook Web connection status and whether the user is logged in. This clearly distinguishes it from action-oriented siblings like outlook_login or outlook_navigate_folder, though it doesn't explicitly name an alternative.

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 says what is checked but gives no guidance on when to call it — e.g. before running other Outlook tools to verify a session, or after outlook_login to confirm success. No when-not conditions or alternatives are mentioned.

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