Elfy.Life

Server Details

Articles, recettes, événements, calculateurs HOMA/QUICKI — santé métabolique, alimentation cétogène

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over 23 days
Last Tested: 2026-11-01 10:18
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4/5.0

Scored 2026-10-30 21:35 across 8 tools

Disambiguation4/5

Most tools have clearly distinct resource+action targets: the two calculators compute different indices, and get_article/get_recipe/list_recipes/list_upcoming_events are unambiguous. The only mild overlap is between search_content (which also returns recipes) and list_recipes, though the descriptions clarify when to use each.

Naming Consistency5/5

All eight tools follow a strict verb_noun snake_case convention (calculate_*, get_*, list_*, search_*), with verbs that match their actions. No mixed casing or inconsistent verb styles.

Tool Count4/5

Eight tools is well-scoped for a read-only health content site with calculators; each tool serves a distinct purpose. It is slightly lean on the discovery side but nothing feels redundant.

Completeness4/5

The read-only surface covers search, article/recipe retrieval, recipe listing, events, FAQ, and the two site calculators, with no create/update needed for public content. Minor gaps exist: there is no tool to list/browse all articles or categories (only filtered search), and no dedicated event-detail retriever, though relatedSlugs and the linked presentation article mostly compensate.

Available Tools

8 tools

calculate_homaCalculer l'indice HOMAA

Read-onlyIdempotent

Inspect

Calcule l'indice HOMA-IR (insulinorésistance) à partir de la glycémie à jeun (mmol/l, ou mg/dl avec glycemiaUnit) et de l'insulinémie à jeun (mUI/l), avec l'interprétation et les seuils publiés sur Elfy.Life. Le résultat est accompagné d'un avertissement : ce n'est pas un diagnostic médical.

Name	Required	Description	Default
`glycemiaUnit`	No	unité de la glycémie : mmol/l (défaut) ou mg/dl	mmol/l
`glycemiaMmolL`	Yes	glycémie à jeun, dans l'unité glycemiaUnit (mmol/l par défaut, malgré le nom)
`insulinemiaMicroUiMl`	Yes	insulinémie à jeun, en mUI/l (équivalent µUI/ml)

Output Schema

Name	Required	Description
`index`	Yes
`value`	Yes
`inputs`	Yes
`disclaimer`	Yes
`thresholds`	Yes	plages d'interprétation publiées (bornes null = non bornées)
`calculatorUrl`	Yes
`interpretation`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive behavior, so safety is covered. The description adds genuinely new information: the result includes interpretation with published thresholds from Elfy.Life and carries a non-diagnostic disclaimer, which an agent could not infer from the annotations.

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?

A single well-formed sentence that front-loads the action, inputs and units, then adds the two pieces of output context. Dense but every clause carries information; only the repeated unit notation adds minor redundancy with the schema.

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?

With an output schema present and full annotation coverage, the description only needs to supply purpose, unit conventions and any extra return semantics, all of which it does. An agent has everything required to call the tool correctly.

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 description coverage is 100%, so the baseline is 3. The description goes slightly beyond by explicitly stating the mg/dl alternative via glycemiaUnit and the mmol/l default, reinforcing the unit handling documented in the schema.

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 (calcule) and a named resource (indice HOMA-IR / insulinorésistance), lists the exact inputs and units, and distinguishes itself from the content-oriented siblings by being the only computational tool in the set.

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?

Makes the usage context clear (fasting glycemia + insulinemia values) and implicitly rules out alternatives, since no sibling computes indices. There is no explicit 'when not to use' or prerequisite note beyond the 'à jeun' qualifier.

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

calculate_quickiCalculer l'indice QUICKIA

Read-onlyIdempotent

Inspect

Calcule l'indice QUICKI (sensibilité à l'insuline) à partir de la glycémie à jeun (mmol/l, ou mg/dl avec glycemiaUnit) et de l'insulinémie à jeun (mUI/l), avec l'interprétation et les seuils publiés sur Elfy.Life. Le résultat est accompagné d'un avertissement : ce n'est pas un diagnostic médical.

Name	Required	Description	Default
`glycemiaUnit`	No	unité de la glycémie : mmol/l (défaut) ou mg/dl	mmol/l
`glycemiaMmolL`	Yes	glycémie à jeun, dans l'unité glycemiaUnit (mmol/l par défaut, malgré le nom)
`insulinemiaMicroUiMl`	Yes	insulinémie à jeun, en mUI/l (équivalent µUI/ml)

Output Schema

Name	Required	Description
`index`	Yes
`value`	Yes
`inputs`	Yes
`disclaimer`	Yes
`thresholds`	Yes	plages d'interprétation publiées (bornes null = non bornées)
`calculatorUrl`	Yes
`interpretation`	Yes

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare the safe, read-only, idempotent profile, so the bar is lower; the description still adds real value by disclosing that the result comes bundled with published interpretation thresholds from Elfy.Life and a non-diagnostic disclaimer. It stops short of describing output structure, but that is covered by the output schema.

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 tightly packed sentences that front-load the computation and its inputs, then the ancillary warning. Nothing is redundant, though the parenthetical unit enumeration slightly duplicates schema text.

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?

With an output schema present the description needn't explain return values, and it does cover inputs, interpretation, and the medical disclaimer. What's missing is any guidance on sibling selection or input validity ranges, a small gap for a 3-parameter calculation tool.

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 tripled parameter documentation already carries the semantics and baseline 3 applies. The description only restates the unit handling ('mg/dl avec glycemiaUnit') already spelled out in the schema and adds no conversion formula or range constraints.

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 and resource ('Calcule l'indice QUICKI') and names the exact inputs (glycémie à jeun, insulinémie à jeun) with units, so the agent knows precisely what the tool computes. It does not, however, explicitly distinguish itself from the sibling calculate_homa, which computes a related insulin-sensitivity index.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies its use case (deriving a QUICKI insulin-sensitivity score from fasting labs) but never states when to pick it over calculate_homa or what preconditions apply. The rubric's 3 ('implied usage') fits: an agent can infer intent but gets no explicit routing guidance.

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

get_articleLire un article Elfy.LifeA

Read-onlyIdempotent

Inspect

Renvoie le contenu complet (Markdown, liens absolus) d'un article public d'Elfy.Life, avec son URL canonique. Les boutons d'appel à l'action de la page (newsletter, entretien, calculateur…) sont retirés du contenu et listés à part dans callToActions ; les articles, recettes et calculateurs liés sont listés dans relatedSlugs (à lire avec get_article ou get_recipe), et les questions fréquentes de l'article dans faq.

Name	Required	Description	Default
`slug`	Yes	slug de l'article, tel que renvoyé par search_content

Output Schema

Name	Required	Description
`faq`	Yes	questions fréquentes publiées sous l'article
`url`	Yes
`title`	Yes
`content`	Yes	Markdown, liens absolus
`abstract`	Yes
`dateCreated`	Yes
`dateModified`	Yes
`relatedSlugs`	Yes
`callToActions`	Yes

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already cover readOnly/idempotent/non-destructive, and the description adds real value beyond them: CTAs are stripped from the body and hoisted into callToActions, with relatedSlugs and faq split out. It does not discuss error behavior for unknown slugs or whether private/draft content is excluded, 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?

A single front-loaded sentence that leads with the return value and then enumerates the auxiliary fields; every clause carries information. It is dense but not padded, though it could be split for readability.

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?

An output schema exists, yet the description still helpfully explains the shape of the non-body sections (callToActions, relatedSlugs, faq). Combined with the read-only annotations and the fully documented single parameter, an agent has nearly everything needed; only failure/edge-case behavior is absent.

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?

There is a single parameter with 100% schema description coverage, and the schema already explains that slug must come from search_content. The description adds no additional slug syntax or format detail, so the baseline of 3 applies.

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: returns the full Markdown content plus canonical URL of a public Elfy.Life article. It is clearly distinguishable from get_recipe and search_content by naming the resource type and the related-slug routing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the description says relatedSlugs should be read with get_article or get_recipe, which hints at traversal, and the schema notes slug comes from search_content. There is no explicit 'use this when… / not when…' statement or exclusion, so an agent must infer when to pick this over siblings.

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

get_recipeLire une recette Elfy.LifeA

Read-onlyIdempotent

Inspect

Renvoie une recette publique d'Elfy.Life (ingrédients, préparation et matériel en Markdown, durées ISO 8601, difficulté sur difficultyScale, valeurs nutritionnelles par portion, catégorie, image) avec son URL canonique. Les champs non renseignés sont omis. Les offres et inscriptions de la page (bannières, newsletter recettes) sont retirées de la préparation et de l'utilisation et listées à part dans callToActions.

Name	Required	Description	Default
`slug`	Yes	slug de la recette, tel que renvoyé par search_content

Output Schema

Name	Required	Description
`url`	Yes
`use`	Yes	Markdown
`image`	No
`title`	Yes
`category`	No
`cookTime`	No	durée ISO 8601
`prepTime`	No	durée ISO 8601
`equipment`	No	Markdown
`nutrition`	No	valeurs par portion
`totalTime`	No	durée ISO 8601
`difficulty`	Yes
`description`	No
`ingredients`	Yes
`preparation`	Yes	Markdown
`recipeYield`	No
`callToActions`	Yes	offres et inscriptions retirées de la préparation et de l'utilisation
`difficultyScale`	Yes

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive, closed-world. The description adds genuinely non-obvious behavior: unset fields are omitted, and offers/newsletter CTAs are stripped out of the preparation and usage text and surfaced separately in callToActions. That materially changes how an agent should interpret the payload, though nothing is said about errors or missing slugs.

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?

Three tight sentences, front-loaded with the return contract before the field-omission and CTA caveats. The field enumeration partly duplicates what the output schema already declares, which is the only real redundancy.

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?

With an output schema present, the description need not explain return values, yet it still covers the two non-obvious payload behaviors (omitted fields, extracted CTAs) plus the canonical URL. Combined with full annotation coverage and a fully documented single parameter, nothing needed to invoke it correctly is missing.

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 coverage is 100% and the single slug parameter is already documented in the schema, including its provenance from search_content. The description adds no additional constraint or format detail, so baseline 3 applies.

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: 'Renvoie une recette publique d'Elfy.Life' and enumerates the returned content (ingrédients, préparation, matériel, durées, difficulté, nutrition, catégorie, image, URL canonique). It is clearly a single-recipe fetch, distinct from list_recipes, but it never names the sibling alternatives explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The only usage signal is the implicit pairing with search_content (the slug source), which is already stated in the schema. There is no explicit statement of when to call this versus list_recipes or search_content, so an agent must infer that this is the detail-fetch step after a search.

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

list_recipesLister les recettes Elfy.LifeA

Read-onlyIdempotent

Inspect

Liste les recettes publiques d'Elfy.Life (cétogènes, pauvres en glucides), par titre, avec des filtres optionnels : catégorie (slug), durée totale maximale en minutes, glucides nets maximaux par portion (les recettes sans valeur nutritionnelle sont alors exclues). Renvoie total et nextOffset pour la page suivante (null s'il n'y en a plus). Le détail d'une recette est disponible via get_recipe.

Name	Required	Description
`limit`	No	nombre maximal de recettes
`offset`	No	nombre de recettes à sauter, pour la page suivante (nextOffset)
`category`	No	slug de la catégorie de recettes (ex. « pains »)
`maxNetCarbsG`	No	glucides nets maximaux par portion, en grammes
`maxTotalMinutes`	No	durée totale maximale (préparation + cuisson), en minutes

Output Schema

Name	Required	Description
`total`	Yes
`message`	No
`recipes`	Yes
`nextOffset`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive behavior, so the description correctly spends its words elsewhere: it discloses a real side effect of filtering ('les recettes sans valeur nutritionnelle sont alors exclues') and the pagination contract with nextOffset/null. Missing only things like default page size behavior or ordering guarantees beyond the title sort.

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?

Three sentences, front-loaded with purpose, then filters, then pagination, then the sibling pointer. No redundancy with the schema or annotations — every clause adds information.

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 filtered-list tool with an output schema and full annotation coverage, the description supplies everything else an agent needs: filter semantics, the exclusion side effect, pagination contract, and the escalation path to get_recipe.

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; the description goes beyond it by explaining that maxTotalMinutes includes prep plus cook time and that maxNetCarbsG implicitly excludes recipes lacking nutrition data — semantics no schema field carries. category as a slug is also clarified with an example.

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 ('Liste les recettes publiques d'Elfy.Life') with the domain qualifier (cétogènes, pauvres en glucides) and the sort order (par titre). It explicitly routes detail lookups to get_recipe, so an agent can separate it from its sibling without opening a schema.

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?

The description names get_recipe as the alternative for single-recipe detail and marks all filters as optional, giving clear usage context. It stops short of stating when to prefer other siblings like search_content, so it is clear but not fully exhaustive.

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

list_upcoming_eventsÉvénements à venirA

Read-onlyIdempotent

Inspect

Liste les prochains événements (ateliers, webinaires, conférences) proposés par Elfy.Life, avec l'article de présentation et le fichier calendrier .ics. Si aucun événement n'est programmé, la liste est vide ; un message l'indique et newsUrl donne la page des actualités où les prochains sont annoncés.

Name	Required	Description	Default
`limit`	No	nombre maximal d'événements

Output Schema

Name	Required	Description
`events`	Yes
`message`	No
`newsUrl`	No	actualités, où sont annoncés les prochains événements

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds real value beyond that: it discloses the empty-result state and the newsUrl fallback page where future events are announced, which an agent cannot infer from the schema.

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?

Two sentences, front-loaded with the resource and scope, then the empty-state caveat. Every clause carries information; nothing repeats the title or name.

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?

With an output schema present, return-value detail is optional, and the description nonetheless names the article and .ics payload plus the empty case. Complete enough to call correctly; only the effect of 'limit' stays implicit.

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% and the single 'limit' parameter carries its own description and bounds, so the schema does the work. The description says nothing about the limit or default page size, so it adds no meaning beyond the structured field.

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 + resource ('Liste les prochains événements') and enumerates the covered event types (ateliers, webinaires, conférences) plus what each entry carries (article de présentation, fichier .ics). No sibling tool overlaps this scope, so no differentiation burden exists.

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?

The trigger context is clear: the tool answers questions about upcoming Elfy.Life events. It also tells the agent what to do when the list is empty (point the user to newsUrl). No explicit exclusions or named alternatives, but none of the siblings are plausibly confusable.

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

search_contentRechercher dans Elfy.LifeA

Read-onlyIdempotent

Inspect

Recherche les articles et recettes publics d'Elfy.Life (santé métabolique, insulinorésistance, prédiabète, nutrition cétogène). Renvoie le titre, un extrait, l'URL et la date de mise à jour de chaque page, le nombre total de résultats et nextOffset pour la page suivante (null s'il n'y en a plus). Le contenu complet est disponible via get_article et get_recipe.

Name	Required	Description	Default
`type`	No	type de contenu : all (défaut), article ou recipe	all
`limit`	No	nombre maximal de résultats
`query`	Yes	mots-clés de recherche, en français
`offset`	No	nombre de résultats à sauter, pour la page suivante (nextOffset)

Output Schema

Name	Required	Description
`total`	Yes
`message`	No
`results`	Yes
`nextOffset`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior. The description adds useful behavioral context: it returns only excerpts, includes total result counts, exposes nextOffset (null when exhausted), and points to other tools for full content. It does not mention auth or rate limits, but the main behavioral traits are covered.

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?

Two tightly written sentences front-load the purpose and scope, then summarize return shape and alternatives. Every part earns its place with no redundancy.

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 read-only search tool with full schema coverage, output schema, and safety annotations, the description is nearly complete. The only minor gap is that it does not explicitly distinguish this search from search_faq or list_recipes, though the resource scope makes the distinction reasonably clear.

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 all four parameters are already documented in the schema. The description only indirectly references nextOffset/pagination and does not add syntax or format details beyond what the schema provides; baseline 3 is appropriate.

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?

The description uses a specific verb ('Recherche') and names the exact resource: public articles and recipes on Elfy.Life, with topical scope. It also distinguishes itself from siblings get_article and get_recipe by explaining that those provide full content, making the search-vs-fetch boundary clear.

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 clearly implies the tool is for discovery and explicitly routes full-content retrieval to get_article and get_recipe. However, it does not clarify when to use this instead of sibling tools like search_faq or list_recipes, so the alternatives guidance is strong but not exhaustive.

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

search_faqRechercher dans les FAQ Elfy.LifeA

Read-onlyIdempotent

Inspect

Recherche dans les questions fréquentes d'Elfy.Life (FAQ générale et FAQ des articles) : réponses courtes validées par l'équipe éditoriale, en Markdown, avec le lien direct vers chaque question et la page source. À privilégier pour une question précise ; pour approfondir, lire l'article source avec get_article.

Name	Required	Description	Default
`limit`	No	nombre maximal de réponses
`query`	Yes	mots-clés ou question, en français

Output Schema

Name	Required	Description
`total`	Yes
`message`	No
`results`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description still adds real context beyond them: results are short answers validated by the editorial team, rendered in Markdown, and include a direct link per question plus the source page.

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?

Two sentences, front-loaded with scope, then the usage routing. Every clause carries information: corpus, answer nature, format, and links.

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?

An output schema exists, so return values needn't be detailed, and the description still previews result shape (Markdown, link, source page). It could add what happens on zero results or coverage limits, but nothing essential for correct invocation is missing.

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 coverage is 100% and both parameters are documented in the schema itself (keywords/question in French, max results). The description only echoes 'question précise' and adds no syntax, language or limit guidance beyond that, so baseline 3 applies.

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 ('Recherche dans les questions fréquentes d'Elfy.Life') and narrows the scope to two concrete FAQ corpora, which separates it from search_content. It also names the follow-up sibling get_article, so an agent can distinguish it from alternatives without opening a schema.

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?

'À privilégier pour une question précise' gives a clear selection context, and 'pour approfondir, lire l'article source avec get_article' names the alternative and the condition that switches to it. No explicit exclusion against search_content or the calculators, so it stops short of a full when/when-not map.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateOct 30, 2026

Changedget_recipe2 fields changed

addedOutput schema / properties / callToActions

Added value: +{
+  "description": "offres et inscriptions retirées de la préparation et de l'utilisation",
+  "items": {
+    "properties": {
+      "label": {
+        "type": "string"
+      },
+      "url": {
+        "format": "uri",
+        "type": "string"
+      }
+    },
+    "required": [
+      "label",
+      "url"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

changedOutput schema / required

Previous value: -[
-  "title",
-  "url",
-  "difficulty",
-  "difficultyScale",
-  "ingredients",
-  "preparation",
-  "use"
-]New value: +[
+  "title",
+  "url",
+  "difficulty",
+  "difficultyScale",
+  "ingredients",
+  "preparation",
+  "use",
+  "callToActions"
+]

8 tool updatesOct 30, 2026

Changedcalculate_homa3 fields changed

changedInput schema / properties / glycemiaMmolL / description

Previous value: -"glycémie à jeun, en mmol/l"New value: +"glycémie à jeun, dans l'unité glycemiaUnit (mmol/l par défaut, malgré le nom)"

addedInput schema / properties / glycemiaUnit

Added value: +{
+  "default": "mmol/l",
+  "description": "unité de la glycémie : mmol/l (défaut) ou mg/dl",
+  "enum": [
+    "mmol/l",
+    "mg/dl"
+  ],
+  "type": "string"
+}

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "calculatorUrl": {
+      "format": "uri",
+      "type": "string"
+    },
+    "disclaimer": {
+      "type": "string"
+    },
+    "index": {
+      "enum": [
+        "HOMA",
+        "QUICKI"
+      ],
+      "type": "string"
+    },
+    "inputs": {
+      "properties": {
+        "glycemiaConvertedFrom": {
+          "properties": {
+            "unit": {
+              "enum": [
+                "mg/dl"
+              ],
+              "type": "string"
+            },
+            "value": {
+              "type": "number"
+            }
+          },
+          "required": [
+            "value",
+            "unit"
+          ],
+          "type": "object"
+        },
+        "glycemiaMmolL": {
+          "type": "number"
+        },
+        "insulinemiaMicroUiMl": {
+          "type": "number"
+        }
+      },
+      "required": [
+        "glycemiaMmolL",
+        "insulinemiaMicroUiMl"
+      ],
+      "type": "object"
+    },
+    "interpretation": {
+      "type": "string"
+    },
+    "thresholds": {
+      "description": "plages d'interprétation publiées (bornes null = non bornées)",
+      "items": {
+        "properties": {
+          "interpretation": {
+            "type": "string"
+          },
+          "max": {
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "maxInclusive": {
+            "type": "boolean"
+          },
+          "min": {
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "minInclusive": {
+            "type": "boolean"
+          }
+        },
+        "required": [
+          "min",
+          "minInclusive",
+          "max",
+          "maxInclusive",
+          "interpretation"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "value": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "index",
+    "value",
+    "interpretation",
+    "thresholds",
+    "inputs",
+    "disclaimer",
+    "calculatorUrl"
+  ],
+  "type": "object"
+}

Changedcalculate_quicki3 fields changed

changedInput schema / properties / glycemiaMmolL / description

Previous value: -"glycémie à jeun, en mmol/l"New value: +"glycémie à jeun, dans l'unité glycemiaUnit (mmol/l par défaut, malgré le nom)"

addedInput schema / properties / glycemiaUnit

Added value: +{
+  "default": "mmol/l",
+  "description": "unité de la glycémie : mmol/l (défaut) ou mg/dl",
+  "enum": [
+    "mmol/l",
+    "mg/dl"
+  ],
+  "type": "string"
+}

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "calculatorUrl": {
+      "format": "uri",
+      "type": "string"
+    },
+    "disclaimer": {
+      "type": "string"
+    },
+    "index": {
+      "enum": [
+        "HOMA",
+        "QUICKI"
+      ],
+      "type": "string"
+    },
+    "inputs": {
+      "properties": {
+        "glycemiaConvertedFrom": {
+          "properties": {
+            "unit": {
+              "enum": [
+                "mg/dl"
+              ],
+              "type": "string"
+            },
+            "value": {
+              "type": "number"
+            }
+          },
+          "required": [
+            "value",
+            "unit"
+          ],
+          "type": "object"
+        },
+        "glycemiaMmolL": {
+          "type": "number"
+        },
+        "insulinemiaMicroUiMl": {
+          "type": "number"
+        }
+      },
+      "required": [
+        "glycemiaMmolL",
+        "insulinemiaMicroUiMl"
+      ],
+      "type": "object"
+    },
+    "interpretation": {
+      "type": "string"
+    },
+    "thresholds": {
+      "description": "plages d'interprétation publiées (bornes null = non bornées)",
+      "items": {
+        "properties": {
+          "interpretation": {
+            "type": "string"
+          },
+          "max": {
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "maxInclusive": {
+            "type": "boolean"
+          },
+          "min": {
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "minInclusive": {
+            "type": "boolean"
+          }
+        },
+        "required": [
+          "min",
+          "minInclusive",
+          "max",
+          "maxInclusive",
+          "interpretation"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "value": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "index",
+    "value",
+    "interpretation",
+    "thresholds",
+    "inputs",
+    "disclaimer",
+    "calculatorUrl"
+  ],
+  "type": "object"
+}

Changedget_article1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "abstract": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "callToActions": {
+      "items": {
+        "properties": {
+          "label": {
+            "type": "string"
+          },
+          "url": {
+            "format": "uri",
+            "type": "string"
+          }
+        },
+        "required": [
+          "label",
+          "url"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "content": {
+      "description": "Markdown, liens absolus",
+      "type": "string"
+    },
+    "dateCreated": {
+      "format": "date-time",
+      "type": "string"
+    },
+    "dateModified": {
+      "format": "date-time",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "faq": {
+      "description": "questions fréquentes publiées sous l'article",
+      "items": {
+        "properties": {
+          "answer": {
+            "description": "Markdown, liens absolus",
+            "type": "string"
+          },
+          "question": {
+            "type": "string"
+          },
+          "url": {
+            "description": "lien direct vers la question",
+            "format": "uri",
+            "type": "string"
+          }
+        },
+        "required": [
+          "question",
+          "answer",
+          "url"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "relatedSlugs": {
+      "items": {
+        "properties": {
+          "slug": {
+            "type": "string"
+          },
+          "title": {
+            "type": "string"
+          },
+          "type": {
+            "enum": [
+              "article",
+              "recipe",
+              "calculator"
+            ],
+            "type": "string"
+          },
+          "url": {
+            "format": "uri",
+            "type": "string"
+          }
+        },
+        "required": [
+          "type",
+          "slug",
+          "title",
+          "url"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "title": {
+      "type": "string"
+    },
+    "url": {
+      "format": "uri",
+      "type": "string"
+    }
+  },
+  "required": [
+    "title",
+    "url",
+    "abstract",
+    "dateCreated",
+    "dateModified",
+    "content",
+    "callToActions",
+    "relatedSlugs",
+    "faq"
+  ],
+  "type": "object"
+}

Changedget_recipe1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "category": {
+      "properties": {
+        "name": {
+          "type": "string"
+        },
+        "slug": {
+          "type": "string"
+        },
+        "url": {
+          "format": "uri",
+          "type": "string"
+        }
+      },
+      "required": [
+        "name",
+        "slug",
+        "url"
+      ],
+      "type": "object"
+    },
+    "cookTime": {
+      "description": "durée ISO 8601",
+      "type": "string"
+    },
+    "description": {
+      "type": "string"
+    },
+    "difficulty": {
+      "minimum": 1,
+      "type": "integer"
+    },
+    "difficultyScale": {
+      "type": "integer"
+    },
+    "equipment": {
+      "description": "Markdown",
+      "type": "string"
+    },
+    "image": {
+      "format": "uri",
+      "type": "string"
+    },
+    "ingredients": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "nutrition": {
+      "description": "valeurs par portion",
+      "properties": {
+        "caloriesKcal": {
+          "type": "integer"
+        },
+        "fatG": {
+          "type": "number"
+        },
+        "netCarbsG": {
+          "type": "number"
+        },
+        "proteinG": {
+          "type": "number"
+        }
+      },
+      "type": "object"
+    },
+    "prepTime": {
+      "description": "durée ISO 8601",
+      "type": "string"
+    },
+    "preparation": {
+      "description": "Markdown",
+      "type": "string"
+    },
+    "recipeYield": {
+      "type": "string"
+    },
+    "title": {
+      "type": "string"
+    },
+    "totalTime": {
+      "description": "durée ISO 8601",
+      "type": "string"
+    },
+    "url": {
+      "format": "uri",
+      "type": "string"
+    },
+    "use": {
+      "description": "Markdown",
+      "type": "string"
+    }
+  },
+  "required": [
+    "title",
+    "url",
+    "difficulty",
+    "difficultyScale",
+    "ingredients",
+    "preparation",
+    "use"
+  ],
+  "type": "object"
+}

Addedlist_recipes

Changedlist_upcoming_events1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "events": {
+      "items": {
+        "properties": {
+          "address": {
+            "type": "string"
+          },
+          "articleTitle": {
+            "type": "string"
+          },
+          "articleUrl": {
+            "format": "uri",
+            "type": "string"
+          },
+          "dateEnd": {
+            "format": "date-time",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "dateStart": {
+            "format": "date-time",
+            "type": "string"
+          },
+          "icsUrl": {
+            "format": "uri",
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          },
+          "summary": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "name",
+          "summary",
+          "address",
+          "dateStart",
+          "dateEnd",
+          "articleTitle",
+          "articleUrl",
+          "icsUrl"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "message": {
+      "type": "string"
+    },
+    "newsUrl": {
+      "description": "actualités, où sont annoncés les prochains événements",
+      "format": "uri",
+      "type": "string"
+    }
+  },
+  "required": [
+    "events"
+  ],
+  "type": "object"
+}

Changedsearch_content3 fields changed

addedInput schema / properties / offset

Added value: +{
+  "default": 0,
+  "description": "nombre de résultats à sauter, pour la page suivante (nextOffset)",
+  "minimum": 0,
+  "type": "integer"
+}

addedInput schema / properties / type

Added value: +{
+  "default": "all",
+  "description": "type de contenu : all (défaut), article ou recipe",
+  "enum": [
+    "all",
+    "article",
+    "recipe"
+  ],
+  "type": "string"
+}

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "message": {
+      "type": "string"
+    },
+    "nextOffset": {
+      "minimum": 0,
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "results": {
+      "items": {
+        "properties": {
+          "dateModified": {
+            "format": "date-time",
+            "type": "string"
+          },
+          "excerpt": {
+            "type": "string"
+          },
+          "slug": {
+            "type": "string"
+          },
+          "title": {
+            "type": "string"
+          },
+          "type": {
+            "enum": [
+              "article",
+              "recipe"
+            ],
+            "type": "string"
+          },
+          "url": {
+            "format": "uri",
+            "type": "string"
+          }
+        },
+        "required": [
+          "type",
+          "title",
+          "slug",
+          "excerpt",
+          "url"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "total": {
+      "minimum": 0,
+      "type": "integer"
+    }
+  },
+  "required": [
+    "results",
+    "total",
+    "nextOffset"
+  ],
+  "type": "object"
+}

Addedsearch_faq

6 tool updatesOct 9, 2026
- First observedcalculate_homa
- First observedcalculate_quicki
- First observedget_article
- First observedget_recipe
- First observedlist_upcoming_events
- First observedsearch_content

Related MCP Connectors

Mon Batch Cooking A
fr.monbatchcooking
Recettes de batch cooking en français : recherche, idées avec vos placards, sessions de cuisine.
Search
41
https://api.monbatchcooking.fr/mcp
tax-retirement A
io.github.herve-coulon
Calcul fiscal (IR, IFI, PER, plus-value) et retraite français — 32 régimes, sourcé et daté.
Finance Legal & Compliance
3811
https://app.qotien.fr/api/fiscal/v1/mcp
artemis AOAuth
ai.sydera
Les chiffres de votre officine (ventes, stock, marges) dans votre IA, en lecture seule.
ERP Systems Finance Databases
111
https://artemis.sydera.ai/mcp
WPFormation : WordPress en français A
com.wpformation
Articles WordPress en français et outils d'analyse de sites, de domaines et de plugins.
Developer Tools Documentation Access Education & Learning Tools
71
https://wpformation.com/api/mcp/

Related MCP Servers

NutriBalance
Health & Wellness Fitness Tracking
thenutritrackerapp-creator
A
license
A
quality
D
maintenance
Calculate TDEE & macro targets, look up food nutrition data, generate meal plans, fix nutrient deficiencies, and score a day's eating from 0–100. Free nutrition tools for AI assistants.
Updated 4 months ago (2026-07-05 17:46 UTC)
5
MIT
Personal Agent Glycemic Load
Health & Wellness Biology & Medicine
Alpha-Park
A
license
Not graded
quality
B
maintenance
Enables computing composite glycemic load for multi-ingredient meals, modeling protein and fat attenuation of glucose spikes, and forecasting post-prandial fatigue and stable focus hours to guide meal and task scheduling.
Updated a day ago (2026-10-31 02:23 UTC)
7
MIT
Personal Agent Glycemic Load
Health & Wellness Biology & Medicine
alphaparkinc
A
license
Not graded
quality
B
maintenance
Enables users to aggregate meal glycemic index/load, model protein and fat buffering, forecast post-prandial cognitive crash risk and focus hours, and receive macronutrient stabilization recommendations.
Updated a day ago (2026-10-31 02:21 UTC)
7
MIT
Canada's Food Guide MCP Server
Health & Wellness Research & Data Search
Aryan-Jhaveri
A
license
Not graded
quality
C
maintenance
Provides 42+ specialized tools for nutrition analysis integrating Canada's Food Guide recipes with Health Canada's official databases (CNF, DRI, EER) for recipe discovery, macro calculations, energy requirements, and dietary adequacy assessments.
Updated 8 months ago (2026-03-03 00:32 UTC)
2
MIT

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?