fixou
Server Details
Create and track quote requests to local French tradespeople (80 trades) on fixou.fr.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.4/5 across 3 of 3 tools scored.
Each tool has a distinct and exclusive purpose: listing categories, creating a request, and querying a request's status. No overlap or ambiguity exists between them.
All three tool names follow a consistent verb_noun pattern in snake_case (list_categories, create_request, get_request), making them predictable and easy to understand.
With 3 tools, the set is concise and scoped to the core workflow of requesting quotes. It is appropriate for a simple service, though slightly on the low end.
The tools support the basic lifecycle of creating and checking a request, but lack editing, canceling, or listing all requests. The domain coverage has notable gaps that may limit agent autonomy.
Available Tools
3 toolscreate_requestAInspect
Cree une demande de devis Fixou au nom du client final. IMPORTANT : la demande n'est PAS publiee immediatement — elle attend une confirmation par email (double opt-in). L'email est celui du CLIENT FINAL (pas de l'agent) et est obligatoire : le client recevra un email « Confirmez votre demande » avec un lien valable 48 heures ; tant qu'il n'a pas clique, aucun artisan n'est contacte. Apres cet appel, invitez explicitement l'utilisateur a ouvrir sa boite mail et a cliquer sur ce lien de confirmation pour publier sa demande et suivre les reponses sur fixou.fr ; l'agent lui-meme n'a jamais acces a cet espace. La description doit faire au moins 20 caracteres. answers reprend les id de questions et les value d'options du metier (voir list_categories). Renvoie le requestId a utiliser avec get_request.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email du client final (obligatoire) ; il y recevra le lien de confirmation a cliquer pour publier sa demande, puis le suivi. | ||
| phone | No | Telephone du client final (optionnel), transmis aux artisans qu'il choisira. | |
| answers | Yes | Reponses au questionnaire du metier, indexees par `id` de question. Valeur unique (question single) ou tableau de valeurs (question multi), choisies parmi les `value` des options. | |
| postalCode | Yes | Code postal francais du lieu d'intervention (5 chiffres). | |
| description | Yes | Description libre du besoin, en francais, de 20 a 5000 caracteres. | |
| categorySlug | Yes | Slug du metier concerne, obtenu via list_categories. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: double opt-in, email requirement for client, agent never has access, and returns requestId. It could additionally mention rate limits or error handling, but the provided details are sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and includes all necessary details. It is somewhat lengthy but each sentence adds value. Could be slightly more concise, but it is well structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the flow: creation, confirmation, agent's role, and return value (requestId). It doesn't explain error cases or validation beyond minLength, but for this API the provided context is complete enough to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds meaning beyond the schema by explaining that answers uses id of questions and value of options (referencing list_categories), and clarifying that email is the client's. This aids parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Crée une demande de devis Fixou au nom du client final' using a specific verb and resource. It distinguishes from sibling tools: get_request retrieves, list_categories lists categories, while this tool creates requests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: the request is not published immediately, requires email confirmation with a 48-hour link, and the agent should invite the client to click. It does not explicitly state when not to use, but the sibling tools context implies alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_requestAInspect
Consulte le statut d'une demande Fixou et les reponses des artisans (nom de l'entreprise, message, prix indicatif, delai, note moyenne). Ne renvoie jamais de coordonnees : celles-ci ne sont communiquees qu'au client final, une fois qu'il a choisi un artisan sur fixou.fr. Une cle API ne peut consulter que les demandes qu'elle a elle-meme creees.
| Name | Required | Description | Default |
|---|---|---|---|
| requestId | Yes | Identifiant de la demande, renvoye par create_request. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explicitly states what is returned and what is never returned (contact details) and the API key restriction. It is transparent about limits, though idempotence or error cases are not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, no redundancy, every sentence adds value. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 1 param and no output schema, the description covers main outputs (status, artisan details) and constraints. Minor gap: exact fields of request status not fully enumerated, but sufficient for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of requestId. The description adds no extra semantics beyond the schema, hence baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool consults the status of a Fixou request and artisan responses, listing specific data returned. It distinguishes from siblings: create_request creates, list_categories lists categories. The purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use (to check request status and artisan responses) and constraints (never returns contact details, API key scoping). It implicitly differentiates from siblings, though no explicit when-not-to-use is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_categoriesAInspect
Liste tous les metiers proposes par Fixou, regroupes par famille, avec le questionnaire propre a chaque metier. A appeler avant create_request : le slug d'un metier devient le categorySlug, et le questionnaire indique les questions a couvrir. Dans create_request, l'objet answers doit utiliser les id de question comme cles et, comme valeurs, les value des options proposees (jamais les libelles).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It accurately describes a read-only listing operation with no side effects. However, it does not mention performance, pagination, or error scenarios, which would enhance transparency for a simple tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet comprehensive, with no unnecessary words. It front-loads the main action and then provides essential usage guidance in a logical order.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no parameters, the description fully covers the tool's purpose, output, and integration with create_request, providing complete context for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the description is not required to explain them. It goes beyond by explaining the output structure and its usage in subsequent tools, adding significant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists all 'metiers' (categories) offered by Fixou, grouped by family, with associated questionnaires. It distinguishes from sibling tools by specifying its role as a prerequisite for create_request and detailing how its output is used.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call before create_request, explains how the output fields (slug, questionnaire) map to create_request parameters, and provides precise details on constructing the 'answers' object.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!