Skip to main content
Glama

Show my agenda

my_agenda
Read-only

The user's day at a glance from Xenition: today's calendar events, tasks due today or overdue, and anything awaiting approval. Use ONLY when the user explicitly asks about their day, schedule, or agenda — e.g. 'what does my day look like', 'what's on my plate today'. Do NOT use it as a fallback for vague requests like 'just handle it' or 'take care of the rest' — for those, ask the user what they mean instead.

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
countYes
emptyNo
itemsYes
titleYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds meaningful context beyond that: it enumerates the three data sources merged into the result, which no structured field conveys. It does not discuss latency, caching, or refresh behavior, and an output schema covers the return shape, so a 4 is appropriate.

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?

The scope statement is front-loaded ahead of the usage constraints, and each sentence carries a distinct instruction (what it returns, when to call, when not to call). The 'from Xenition' branding and the doubled example phrasings add mild redundancy but do not obscure the guidance.

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

Completeness5/5

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

With zero parameters, a 100%-covered schema, an output schema defining the return values, and annotations covering the safety profile, the description's remaining job is routing and scope — both of which it handles fully.

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 of 4 applies. There is no argument syntax the description could usefully clarify.

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 aggregated resource — today's calendar events, tasks due or overdue, and pending approvals — with a clear verb of retrieval. This distinguishes it from list_events, list_tasks, and list_pending_approvals, which each return one slice rather than the combined day view.

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

Usage Guidelines5/5

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

Explicitly names the triggering phrasings ('what does my day look like') and an exclusion case ('just handle it'), and prescribes the correct alternative behavior (ask the user for clarification). Nothing is left to inference about when to invoke it.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.