Skip to main content
Glama

E-mail one rent notice to its tenant

immo_avis_echeance_envoyer

WHEN ONE rent call must be e-mailed to ITS tenant. Without confirmer: true, returns a preview and sends NOTHING — show it to the user and ask. destinataire must be the tenant's e-mail on file. One e-mail per call, never bulk. Ask the user's explicit approval first.

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": {
      "appel_id": "<appel_id>",
      "destinataire": "<destinataire>"
    },
    "name": "immo_avis_echeance_envoyer"
  }
}

Input Schema

NameRequiredDescriptionDefault
abonneNoSubscriber code (SUB-…) — admin key only.
appel_idYesRent call id (immo_appel_loyer).
confirmerNo
destinataireYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior4/5

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

Beyond the annotations (non-read-only, open-world, non-idempotent, non-destructive), it discloses the critical dry-run semantics: without confirmer:true it returns a preview and sends NOTHING. That is high-value behavior an agent could not infer from the schema. It does not describe the preview's contents or delivery failure behavior, so not a 5.

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?

Four short, front-loaded sentences with no filler, and the safety-critical preview rule appears early. The first sentence is a grammatical fragment and the heavy capitalization is slightly noisy, 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 a small, external-effect tool with no output schema, the description covers the send gate, recipient constraint, per-call limit, and approval requirement. Return-shape details for the preview are absent but arguably inferable; overall it is sufficient to call correctly and safely.

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 coverage is only 50% — confirmer and destinataire have no schema descriptions — and the description compensates for both: confirmer acts as the send gate, and destinataire must be the tenant's e-mail on file. That closes the documentation gap the schema leaves open.

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 names a specific verb and resource (e-mail one rent call to its tenant) and scopes it to a single notice. The emphasis on 'ONE ... never bulk' distinguishes it from batch-style siblings such as relance_impaye or quittance_loyer, though it does not name an alternative explicitly.

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 states the triggering condition (a single rent call needing to be e-mailed), the exclusion (never bulk), and a procedural rule (ask for explicit user approval first). It lacks explicit routing to a sibling tool for the bulk case, which keeps it below a 5.

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