Skip to main content
Glama
SVerITG

Metis

by SVerITG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Metis — Add Reminder

add_reminder

Schedule reminders on the researcher's dashboard calendar to capture follow-ups, deadlines, or recurring tasks with flexible date, time, and repeat settings.

Instructions

Put a reminder on the researcher's dashboard calendar.

Use this whenever they ask to be reminded of something, or whenever you agree
to come back to something later. It appears as a chip on the Work calendar on
the chosen day.

Args:
    text: What to remind them of. Write it so it still makes sense in a week
        with no other context — "re-run the routing audit", not "check that".
    date: When. Either YYYY-MM-DD, or a phrase: "tomorrow", "in a week",
        "in 3 days", "in two weeks", "in a month".
    project_id: Optional project slug to file it under (e.g. "metis-dashboard").
        Leave empty for a reminder that belongs to no project — that is a
        normal case, not a fallback.
    remind_at: Optional time of day, "HH:MM".
    until: Optional end date, same formats as `date`. Its meaning depends on
        `repeat`, and the two readings are mutually exclusive:
          * without `repeat` — a MULTI-DAY event. `date`..`until` is one
            continuous block (a conference, a field trip, leave).
          * with `repeat` — when the SERIES stops. Leave empty for open-ended.
        A recurring multi-day event is not supported; say so rather than
        silently picking one of the two readings.
    repeat: "" (default), "daily", "weekdays", "weekly", "monthly" or
        "yearly". A repeating plan is stored as one row plus this rule and
        expanded when the calendar is drawn, so changing it changes every
        future occurrence at once.
    duration_days: How many days ONE occurrence covers, default 1. Use it with
        `repeat` for something like "the first three days of every month".
        Without `repeat`, prefer `until` — it says the same thing more clearly.

Returns:
    Confirmation naming the date, span or schedule it was placed on.

Input Schema

NameRequiredDescriptionDefault
dateYes
textYes
untilNo
repeatNo
remind_atNo
project_idNo
duration_daysNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.5

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden. It discloses that the reminder appears as a chip on the Work calendar, explains that a repeating plan is stored as one row and expanded on render, notes that recurring multi-day events are unsupported and should be flagged rather than silently resolved, and describes the return confirmation. These details give the agent a complete behavioral picture.

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?

The description is well-structured with a clear front-loaded purpose statement, then an Args section, and a Returns section. Every sentence adds value, and despite its length, the information is necessary given the 7 parameters and 0% schema coverage. There is no redundant or filler content.

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?

Given the complexity of the tool (7 parameters, recurring events, multi-day spans) and the absence of annotations, the description provides everything an agent needs: when to use, how to format each parameter, behavioral caveats, and what to expect on return. The existence of an output schema does not make the Returns note superfluous because the description confirms the confirmation content.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must fully document all parameters. It does so thoroughly: it explains the purpose and format of each of the seven parameters, including examples for date phrases, the mutually exclusive interpretations of `until` depending on `repeat`, allowed values for `repeat`, default behavior for `duration_days`, and the optional nature of `project_id`.

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 states a specific verb and resource: 'Put a reminder on the researcher's dashboard calendar.' It clearly distinguishes from tasks or notes by calling it a reminder and describing its appearance as a chip on the Work calendar. However, it does not explicitly name a sibling alternative or contrast itself with other scheduling tools in the sibling list.

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

Usage Guidelines4/5

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

It gives clear usage context: 'Use this whenever they ask to be reminded of something, or whenever you agree to come back to something later.' This tells the agent when to invoke the tool, but it does not state when not to use it or offer explicit alternatives for similar needs.

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