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

No annotations provided, but description fully covers behavioral traits: it 'inspects' (read-only) and 'proposes only — applies nothing', so no destructive action. Clear about its safe, non-modifying nature.

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 with clear front-loading of purpose. Efficient but could be slightly more concise (e.g., parentheses). Still very well structured.

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?

Tool has one optional parameter and no output schema. Description explains purpose, usage, and behavior adequately. Lacks mention of output format but sufficient for its simplicity.

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 only parameter 'limit' is fully described in the schema (100% coverage). The description adds no additional semantic info beyond 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?

Clearly states it inspects raw IndexedDB stores and proposes a field mapping. Distinct from sibling tools which deal with people, conversations, messages, search, and topics.

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 describes when to use: when schema is unrecognized after a Teams update or to inspect DB structure. Also clarifies it only proposes, not applies, and requires human verification.

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?

Despite no annotations, the description discloses output fields (canonical name, p:handle, message count, last-contact time) and the scanning behavior ('most-talked-to first' when query omitted). It does not mention any destructive actions, which is appropriate. A slight improvement would be to confirm the tool is read-only.

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 concise sentences: purpose, usage guidelines, and extra behavior. No redundancy. Efficiently front-loaded.

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?

Without annotations or output schema, the description covers input/output behavior but fails to explain the 'n' parameter. Since 'n' defaults to 8 and caps at 25, its role (number of results?) is not fully clarified. This gap reduces completeness.

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 descriptions in schema are decent. The tool description adds value by explaining the behavior of omitting query and the ordering. However, the 'n' parameter is not mentioned in the description, which could be overlooked.

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 states the tool resolves name fragments to canonical names and p:handles, with contact stats. It distinguishes from siblings by explicitly advising when to use search/read_messages instead.

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 states when to use (ambiguous name, need contact stats) and when not to (ordinary filtering, use search/read_messages). Provides alternative 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?

The description warns that it reads the local Teams cache, not the full server archive, which is a critical behavioral trait. With no annotations provided, this disclosure adds value. It does not mention any destructive actions, which is consistent with 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?

Two sentences cover purpose, filters, and a critical caveat. Every sentence is meaningful and efficient, front-loading the main function.

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 lacks details about the return format or fields, which would help with no output schema. The caveat adds context, but overall completeness is moderate for a tool with 6 parameters.

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 83%, so baseline is 3. The description lists filter options but does not add significant detail beyond the schema. It groups parameters but does not clarify formats or defaults 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 clearly states the tool lists conversations with default newest N and filtering by kind/participant/title/time. The verb 'list' and resource 'conversations' are specific, and the tool is distinct from siblings like search or read_messages.

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 implies usage for browsing conversations with default and filter options. However, it does not explicitly state when not to use it or compare to alternatives, though sibling tools suggest different purposes.

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 fully discloses critical behavior: it reads the local Teams cache only, not the full server archive, and explains the story order and pagination mechanisms. This provides complete transparency.

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 sentences: first states purpose and order, second explains targeting and pagination, third notes the cache limitation. No unnecessary words, well-organized for quick comprehension.

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 7 parameters and no output schema, the description covers key behavioral aspects: targeting, pagination, ordering, and cache limitation. It could mention the limit default (in schema) or time filtering, but is sufficiently complete 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 coverage is 71% (some parameters lack descriptions like 'since' and 'until'). The description adds value beyond the schema by explaining targeting by handle/substring, pagination with cursor, and centering with around. It compensates for missing schema details but doesn't explicitly cover all parameters.

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 states the verb 'Read' and the resource 'one conversation's messages'. It specifies the story order (oldest→newest) and how to target by handle or substring, distinguishing it from siblings like list_conversations or search.

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 explains how to use the tool: target by handle or substring, page back with cursor, center with around. It implies usage for reading a full conversation in order, but lacks explicit comparison to siblings like search or when not to use.

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?

Discloses that it reads the local Teams cache, not the full server archive - a critical behavioral trait. No annotations provided, so this is valuable context.

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 sentences with no redundancy: purpose, parameter hints, and behavioral note. Efficient and front-loaded.

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?

Covers purpose, key parameter usage, and the local cache limitation. Missing output details but acceptable given no output schema. Adequate for a search 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?

With 50% schema description coverage, the description adds meaning for from/in and mentions_me, but leaves many parameters (since, until, kind, etc.) without additional explanation 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?

Clearly states 'full-text search across all messages with filters' and distinguishes from siblings like read_messages. The empty query behavior as filtered browse adds specificity.

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 explicit guidance on empty query, from/in usage with substrings/handles, and mentions_me flag. Lacks explicit when-not-to-use vs siblings, but context 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?

With no annotations provided, the description adds important context by disclosing that it reads the local Teams cache and not the full server archive. However, it does not mention other behavioral traits like whether results are sorted or if pagination is supported.

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 two sentences plus a note, all essential. It is front-loaded with the core purpose and scoping, then adds a critical limitation. 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?

Given no output schema and moderate complexity (7 parameters, none required), the description adequately explains purpose, scoping, and the local cache limitation. It could be improved by mentioning the exemplar message structure but is sufficient for agent selection.

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 description adds limited meaning beyond the schema. It mentions 'window' and 'scope' conceptually but does not elaborate on format or edge cases for the parameters.

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 states it returns distinctive/trending topics over a window, with scoping to overall, person, or conversation. It distinguishes from sibling tools like read_messages or search by focusing on trending analysis.

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 implies usage for trending topics and mentions scoping, but lacks explicit guidance on when to use this tool vs alternatives like search or list_conversations. No exclusions or prerequisites are stated.

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