Skip to main content
Glama

Get MIO Folders

get-mio-folders
Read-only

Retrieve MIO messaging folders and unread counts; use returned folder IDs as folder_id in other MIO tools to access messages.

Instructions

Retrieve the list of MIO (internal messaging) folders and their unread counts. Folder IDs are string constants like SEARCH_FOLDER_MioRecu; pass them as folder_id to the other MIO tools.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv3.7.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false), and the description adds real value beyond that: it explains the contents of each entry (unread counts) and documents the folder ID constant format such as SEARCH_FOLDER_MioRecu. It does not mention ordering or whether folders are flat vs nested, so it is not exhaustive.

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

Conciseness5/5

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

Two tight sentences with no filler. The primary purpose is front-loaded and the follow-on guidance about ID usage comes second, matching the natural call order.

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

Completeness4/5

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

With no parameters, no output schema, and annotations covering safety, the description supplies enough to call it and to interpret the result (folders plus unread counts). A minor gap is that it doesn't state whether folders are ordered or can be nested, but nothing critical to invoking it is missing.

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

Parameters4/5

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

The tool takes zero parameters, so the baseline is 4. The description goes beyond the schema by pre-explaining the folder_id string constant format for downstream calls, which is useful even though this tool has no inputs of its own.

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

Purpose5/5

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

States a specific verb and resource ('Retrieve the list of MIO folders') plus what each item carries (unread counts). The folder resource is clearly distinct from sibling tools like get-mio-messages, create-mio-folder, and move-mio-message.

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

Usage Guidelines3/5

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

The second sentence tells the agent how the returned folder IDs are consumed by other MIO tools, which implies this is the discovery step before calling get-mio-messages. However, it never states when to use this versus alternatives or any exclusions, leaving usage largely inferred.

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