Skip to main content
Glama

Dandori

Ajouter un abonnement

dandori_create_subscription

Ajouter un abonnement à suivre. Sans Plus, le nombre est limité (le refus le dit).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>",
      "amount": "<amount>",
      "next_renewal_date": "<next_renewal_date>"
    },
    "name": "dandori_create_subscription"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindNo
nameYesNom (ex. Netflix)
notesNo
amountYesMontant par échéance
currencyNoDevise sur 3 lettres (EUR par défaut)
space_idNoID de l'espace (champ spaces de dandori_daily_summary) ; par défaut l'espace principal
started_atNoDébut de l'abonnement (YYYY-MM-DD)
usage_ratingNoUsage réel, de 1 (jamais) à 5 (tous les jours)
billing_cycleNoFréquence ; custom avec billing_interval_months
reminder_daysNoJours avant le prélèvement où prévenir l'utilisateur (ex. [7, 3]) ; [] : aucun rappel ; sans lui, 3 jours avant
next_renewal_dateYesProchain renouvellement (YYYY-MM-DD)
budget_category_idNoID de la catégorie budget, du même espace
auto_create_transactionNoCréer une dépense au budget à chaque échéance
billing_interval_monthsNoAvec custom : nombre de mois entre deux échéances

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.2/5.0
Behavior3/5

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

The description adds value beyond the annotations by disclosing a plan-based cap on the number of subscriptions and pointing to the refusal message as the feedback channel. However, with idempotentHint=false it says nothing about duplicate handling, defaults for the many optional fields, or what a successful call returns.

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 no wasted wording, and the core action is front-loaded. The parenthetical about refusals is slightly elliptical but still earns its place as a quota hint.

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?

For a 14-parameter creation tool with no output schema, the description omits what a successful call produces (e.g., the created subscription's identifier) and how errors beyond the quota refusal surface. Its quota note is useful but leaves the agent under-informed about outcomes.

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 86%, so the input schema already documents nearly all 14 parameters including defaults (currency EUR, reminder_days 3 days, space_id main space). The description adds no additional meaning about any parameter, which is the baseline expectation when the schema carries the 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?

The description states a specific verb and resource ('Ajouter un abonnement à suivre'), making it obviously distinct from the sibling dandori_cancel_subscription. It never explicitly names a contrasting sibling, but the create semantics are unambiguous.

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?

There is no when-to-use or when-not-to-use guidance and no reference to an alternative tool or workflow. The only contextual note is a quota constraint for non-Plus accounts, which is a restriction rather than selection guidance.

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.

Resources