iOffice MCP

io_list_mail

Read-only

List iOffice mail packages and letters with filtering by recipient, sender, status, building, and date range plus sorting and pagination. Retrieve compact, full, or brief mail records.

Instructions

List iOffice mail items (packages and letters). Supports filtering and pagination.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "io_list_mail"
  }
}

Input Schema

Name	Required	Description
`view`	No	Response shape. compact strips image/avatar URLs from the response; "full" returns iOffice's payload untouched. No field projection: this server has no verified record of which iOffice fields matter, and inventing one would risk dropping a field a caller needs. "brief" returns one line per item — title — <ISO date or "no date"> — <status> — with "-- " note lines for an empty or partial page.
`limit`	No	Max results (default 50, max 100)
`search`	No	Filter by recipient name, tracking number, or sender
`status`	No	Filter by status (e.g. received, delivered, returned)
`endDate`	No	Filter mail received on or before this date (ISO 8601)
`orderBy`	No	Property to sort by (default: id)
`startAt`	No	Pagination offset (default 0)
`startDate`	No	Filter mail received on or after this date (ISO 8601)
`buildingId`	No	Filter by building ID
`orderByType`	No	Sort direction (default: asc)
`recipientId`	No	Filter by recipient user ID

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv3.3.0Nov 5, 2026

changedInput schema / properties / view / description

Previous value: -"Response shape: \"compact\" (default) drops fields the response already carries elsewhere; \"full\" returns every field this server understands. compact strips image/avatar URLs from the response; \"full\" returns iOffice's payload untouched. No field projection: this server has no verified record of which iOffice fields matter, and inventing one would risk dropping a field a caller needs."New value: +"Response shape. compact strips image/avatar URLs from the response; \"full\" returns iOffice's payload untouched. No field projection: this server has no verified record of which iOffice fields matter, and inventing one would risk dropping a field a caller needs. \"brief\" returns one line per item — title — <ISO date or \"no date\"> — <status> — with \"-- \" note lines for an empty or partial page."

changedInput schema / properties / view / enum

Previous value: -[
-  "compact",
-  "full"
-]New value: +[
+  "compact",
+  "full",
+  "brief"
+]

Changed12 schema fields changedv3.2.6Oct 17, 2026
- addedInput schema / properties / buildingId / exclusiveMinimum
```
Added value: +0
```
- addedInput schema / properties / buildingId / maximum
```
Added value: +9007199254740991
```
- changedInput schema / properties / buildingId / type
```
Previous value: -"number"New value: +"integer"
```
- addedInput schema / properties / limit / maximum
```
Added value: +100
```
- addedInput schema / properties / limit / minimum
```
Added value: +1
```
- changedInput schema / properties / limit / type
```
Previous value: -"number"New value: +"integer"
```
- addedInput schema / properties / recipientId / exclusiveMinimum
```
Added value: +0
```
- addedInput schema / properties / recipientId / maximum
```
Added value: +9007199254740991
```
- changedInput schema / properties / recipientId / type
```
Previous value: -"number"New value: +"integer"
```
- addedInput schema / properties / startAt / maximum
```
Added value: +9007199254740991
```
- addedInput schema / properties / startAt / minimum
```
Added value: +0
```
- changedInput schema / properties / startAt / type
```
Previous value: -"number"New value: +"integer"
```
First observedv3.2.1Sep 27, 2026

TDQS

C2.9/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and external-data scope are known without the description. The description adds nothing behavioral beyond that – no mention of default page size behaviour, how paging terminates, or how the three view shapes affect payload size (that only lives in the schema).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the resource and its scope, with no redundant restatement of the title. It is arguably too terse rather than too long – the second sentence is generic enough to be nearly filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 11 optional parameters, no output schema, and read-only annotations, the description does the minimum: it establishes the tool as a paginated filtered list. It omits anything an agent would want before calling – default result count, how to detect the last page, or when to prefer brief/compact views – but the schema fills most of that in.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, including detailed notes on the view enum, date semantics, and sort defaults, so the schema carries the full burden. The description contributes no additional parameter meaning, which lands at the baseline 3 for a fully documented schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (list iOffice mail items) and names the sub-types it covers (packages and letters), which distinguishes it from io_get_mail, io_create_mail, io_deliver_mail and io_return_mail. It stops short of explicitly differentiating from those siblings by name, so it is clear but not textbook 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description never says when to use this list endpoint instead of io_get_mail, nor when to combine status/date/recipient filters versus a plain listing. 'Supports filtering and pagination' merely implies usage; there are no exclusions or alternatives named, which is a real gap given 50+ sibling tools.

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

Deploy Server