Skip to main content
Glama
Sign In

Dandori

by life.dandori
OverviewDiscussionsAdmin

Créer ou modifier une routine

dandori_save_routine

Créer une routine (sans id, title et recurrence_type obligatoires) : une habitude à cocher ou une suite d'étapes, répétée chaque jour, certains jours de la semaine ou chaque mois. Avec id, la modifier ; seuls les champs fournis changent, is_active false la met en pause

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": "dandori_save_routine"
  }
}

Input Schema

NameRequiredDescriptionDefault
idNoID de la routine à modifier ; absent pour en créer une
modeNohabit : une seule case à cocher ; steps : une suite d'étapes
timeNoHeure (HH:MM)
stepsNoÉtapes, dans l'ordre (mode steps). En modification, la liste remplace les étapes : une étape absente est retirée
titleNoTitre de la routine (obligatoire à la création)
categoryNoMoment ou thème : morning, health, mind, evening, home
is_activeNoModification : false pour mettre la routine en pause
starts_onNoDate de départ (YYYY-MM-DD) : rien n'est prévu avant. Aujourd'hui ou plus tard, jamais avant la création de la routine
recurrence_daysNoJours de la semaine, 1 = lundi à 7 = dimanche ; obligatoire avec weekly et custom
recurrence_typeNodaily : chaque jour ; weekly ou custom : les jours de recurrence_days ; monthly : le jour recurrence_day_of_month (obligatoire à la création)
recurrence_day_of_monthNoJour du mois (1 à 31) ; obligatoire avec monthly

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior3/5

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

Beyond annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false) it discloses the partial-update contract ('seuls les champs fournis changent') and the pause semantics, which is genuinely useful. However it omits the most consequential behavior for a mutating save: that the 'steps' array replaces the existing list so absent steps are deleted — an agent could easily lose data by not knowing this.

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?

Create-vs-update is front-loaded and the two sentences earn their place. The parenthetical of required creation fields and the chained clauses ('répétée chaque jour, certains jours de la semaine ou chaque mois') make it dense to parse, but nothing is redundant.

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?

For an 11-parameter, dual-mode mutation tool with no output schema, the description covers creation vs. modification, required creation fields, recurrence granularity and the pause flag. The main remaining gap is that steps-replacement and the monthly/weekly dependency on recurrence_days/day_of_month are only in the schema, not surfaced in the prose.

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%, so the schema already defines every parameter including creation-time requirements. The description adds modest value by consolidating that title and recurrence_type are mandatory at creation and that omitting id switches to update mode. Baseline 3 is appropriate since the schema carries most of the semantic load.

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+resource pair ('Créer une routine' / 'Avec id, la modifier'), and adds disambiguating detail about the two shapes a routine can take (habit checkbox vs. step sequence) and the recurrence options. It does not name a sibling (e.g. dandori_toggle_routine for pausing), so it stops short of full differentiation.

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?

Gives a clear decision rule: without 'id' you create (title and recurrence_type required), with 'id' you modify. It also explains that is_active=false is the way to pause rather than delete, which is a useful usage cue. No explicit 'do not use this for X' exclusion is given.

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

All Dandori toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources