Locate Yahoo Mail messages in a folder by sender, subject substring, or unseen status, and return up to a set number of matches.
Search emails in a folder by sender, subject substring, or unseen status.
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Filter by sender address/name | |
| limit | No | ||
| folder | No | INBOX | |
| subject | No | Filter by subject substring | |
| unseenOnly | No |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'Search' implies a read-only operation, but the description says nothing about pagination, result ordering, the default 10-item limit, or what happens with multiple filters combined. For a tool with zero annotation coverage, this leaves significant 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 front-loaded sentence with no filler; the filter dimensions are listed immediately after the verb+resource. Nothing is wasted, and the reader gets the core capability in one pass.
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 5 parameters, 40% schema coverage, no annotations, and no output schema, one sentence is not enough. The description omits how results are bounded (limit/default 10/max 50), how filters combine, and what a result contains, all of which an agent needs to invoke and interpret this tool correctly.
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 40% (only 'from' and 'subject' are documented), so the description must compensate. It does name sender, subject, folder, and unseen status, which maps meaning onto the undocumented folder and unseenOnly parameters, but it omits the limit/pagination parameter entirely and adds no syntax hints (e.g. substring matching, case sensitivity).
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 (search) and resource (emails) plus the filter dimensions it supports (sender, subject substring, unseen status). However, it never distinguishes itself from the sibling list_emails, which is the obvious alternative for enumerating a folder's contents, so an agent must infer the search-vs-list boundary.
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 list_emails, get_email, or any other sibling, and no mention of prerequisites or when-not-to-use. The only usage signal is the implied 'use this if you want to filter,' which is weak given the near-identical sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.