Skip to main content
Glama

inbox

Reads your Migros campaign messages from the message center after login; set full to true to fetch the complete list.

Instructions

Your message-center inbox (campaign messages). Requires login.

Input Schema

NameRequiredDescriptionDefault
fullNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3/5.0
Behavior3/5

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 the authentication requirement, which is a real behavioral constraint. However, it says nothing about whether reading the inbox mutates state (e.g. auto-marking messages read), ordering, or volume limits, all of which matter for a message-list endpoint.

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 with the resource stated first and the auth caveat second; nothing is padded. The parenthetical '(campaign messages)' is efficient disambiguation rather than 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?

Complexity is low (one optional boolean, no nesting) and an output schema exists, so return values need not be explained. Still, the undefined 'full' flag and the absence of any read-vs-mark-read clarification leave an agent short of what it needs to invoke this confidently.

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

Parameters2/5

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

Schema description coverage is 0% and the single parameter 'full' is a bare boolean with no description. The tool description never mentions 'full' at all, so an agent has no way to know whether it means full message bodies versus a summary, or full history versus unread. This is the clearest gap in the definition.

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?

The description identifies the resource precisely as 'your message-center inbox' and narrows it to 'campaign messages', which usefully disambiguates it from a generic messaging endpoint. It does not name or contrast with the related siblings mark_messages_read or delete_messages, so an agent must infer the relationship.

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?

'Requires login' is the only contextual signal, and it is a prerequisite rather than a when-to-use rule. There is no guidance on when to call this versus mark_messages_read or delete_messages, and no hint about what the 'full' flag changes about the listing.

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

Deploy Server

Other Tools