PV Solaire Énergie — Estimation solaire et devis (France)

Demander un devis d’installation photovoltaïque (France)

demander_devis

Dépose une demande de devis gratuite et sans engagement pour une installation de panneaux solaires en France. Un installateur certifié RGE proche du lieu du projet prend la demande en charge et recontacte directement le particulier pour établir son devis. ⚠️ PREMIÈRE ÉTAPE SUR DEUX. Cet outil envoie un code à 4 chiffres par SMS sur le téléphone fourni et renvoie un demande_id : la demande n’est transmise à AUCUN installateur tant que ce code n’a pas été validé via confirmer_demande. Demande le code à l’utilisateur puis appelle confirmer_demande. N’annonce jamais la demande comme envoyée avant ce second appel. N’appelle cet outil qu’avec l’accord explicite de la personne concernée et avec ses vraies coordonnées — jamais avec des données inventées ou de test. Appelle d’abord estimer_production_solaire et transmets son estimation_id : le devis sera bien plus précis.

Input Schema

Name	Required	Description
`nom`	Yes	Nom de famille du demandeur.
`email`	Yes	Adresse e-mail réelle du demandeur, transmise avec la demande à l’installateur qui la prend en charge.
`ville`	Yes	Commune du lieu de l’installation.
`prenom`	Yes	Prénom du demandeur.
`adresse`	Yes	Adresse du lieu de l’installation (numéro et rue), pas l’adresse de facturation.
`demarche`	No	Maturité du projet. Aide l’installateur à prioriser son rappel.
`objectif`	No	Objectif du projet.
`telephone`	Yes	Téléphone MOBILE réel du demandeur, au format français (10 chiffres ou +33). Le code de confirmation à 4 chiffres y est envoyé par SMS : un numéro fixe ou erroné empêche définitivement la demande d’aboutir. C’est aussi le numéro auquel l’installateur rappelle.
`precisions`	No	Précisions libres utiles à l’installateur (contraintes d’accès, ombrage, travaux prévus…).
`code_postal`	Yes	Code postal du lieu de l’installation (5 chiffres).
`equipements`	No	Équipements envisagés, séparés par des virgules (ex. « batterie de stockage, borne de recharge, ballon thermodynamique »).
`orientation`	No	Orientation principale de la toiture. Inutile si `estimation_id` est fourni : elle est alors mesurée.
`facture_elec`	No	Facture d’électricité mensuelle moyenne en euros. Ne renseigne ce champ que si l’utilisateur donne réellement un montant.
`surface_toit`	No	Surface de toiture disponible, en m². Inutile si `estimation_id` est fourni.
`estimation_id`	No	Identifiant renvoyé par `estimer_production_solaire` pour la même adresse. Fortement recommandé : il attache l’analyse réelle de la toiture à la demande. Valable 2 heures.
`type_logement`	No	Type de bâtiment à équiper.
`type_couverture`	No	Type de couverture. Aucune API ne le fournit : c’est la seule caractéristique de toiture qu’il faut demander à l’utilisateur.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 8, 2026

changedInput schema / properties / email / description

Previous value: -"Adresse e-mail réelle du demandeur, transmise aux installateurs avec la demande."New value: +"Adresse e-mail réelle du demandeur, transmise avec la demande à l’installateur qui la prend en charge."

changedInput schema / properties / telephone / description

Previous value: -"Téléphone MOBILE réel du demandeur, au format français (10 chiffres ou +33). Le code de confirmation à 4 chiffres y est envoyé par SMS : un numéro fixe ou erroné empêche définitivement la demande d’aboutir. C’est aussi le canal par lequel les installateurs rappellent."New value: +"Téléphone MOBILE réel du demandeur, au format français (10 chiffres ou +33). Le code de confirmation à 4 chiffres y est envoyé par SMS : un numéro fixe ou erroné empêche définitivement la demande d’aboutir. C’est aussi le numéro auquel l’installateur rappelle."

First observedSep 8, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only declare the generic write/open-world profile; the description adds the concrete side effects: an SMS 4-digit code is sent, a `demande_id` is returned, nothing reaches an installer before confirmation, and the consent/real-data requirement. That is exactly the kind of behavior an agent cannot infer from readOnlyHint=false.

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?

Front-loaded with purpose, then the hard warning, then the workflow and prerequisites. Every sentence is actionable (state the code flow, never claim it was sent, consent rules, call estimer first); nothing is filler.

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?

For a 17-parameter write tool with no output schema, the description still covers the return value (`demande_id`), the failure mode (fixed or wrong number permanently blocks the request), the prerequisite tool, and the confirmation tool. An agent has everything needed to call it and to explain the outcome to the user.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter meaning the schema does not: `estimation_id` is strongly recommended and valid for 2 hours, which makes `orientation` and `surface_toit` redundant. It does not, however, give per-field guidance for the remaining 15 parameters.

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 verb and resource ('Dépose une demande de devis gratuite... pour une installation de panneaux solaires en France') and immediately scopes it as step one of a two-step flow, naming `confirmer_demande` as the required follow-up. An agent can distinguish it from `confirmer_demande`, `estimer_production_solaire` and `rechercher_installateurs` without opening any schema.

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?

Explicit when-to-use (with explicit consent, real contact data, no test data), explicit ordering constraint (the request is not transmitted to any installer until `confirmer_demande` validates the SMS code), and an explicit recommendation to call `estimer_production_solaire` first. Also tells the agent what not to announce to the user.

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

All PV Solaire Énergie — Estimation solaire et devis (France) tools Inspect

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

Need Help?