This server lets AI agents search, browse, and read evipedia.ai's evidence reviews on health and longevity interventions, check what's new, pull structured medical metadata, and suggest new interventions for review.
Search reviews — search_reviews(query) finds matching reviews by name, synonym, keyword, or category, ranked by relevance, so you can tell whether a review exists.
Browse the catalogue — list_reviews() returns every review as {topic, slug} pairs for enumeration.
Track changes — list_updates(days?) returns the newest-first change feed as {title, slug, status, date}, flagging newly published (new) or revised (updated) reviews; defaults to the last 7 days, capped at 100.
Read the conclusion — get_conclusion(slug|url) returns just the plain-text bottom line.
Read the full review — get_review(slug|url) returns the complete review as raw Markdown.
Get structured metadata — get_metadata(slug|url) returns JSON with review dates (freshness signal), the typed about entity with alternate names, and an ordered citation list with PubMed PMIDs.
Suggest a new review — suggest_review(intervention, goal?, references?, email?) submits a proposal to evipedia's public suggestion form; the only write path (use only when the user explicitly wants to propose a review).
Check the build — get_version() returns the running server's package name and version.
All read tools accept either a bare slug (e.g. rapamycin) or a full evipedia.ai URL, so search results can be passed straight through.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@evipedia-mcp What's the evidence on rapamycin for longevity?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A small Model Context Protocol server that lets AI agents query evipedia.ai — our continuously-updated encyclopedia of evidence reviews on health & longevity interventions — and suggest new interventions for review.
search_reviews(query) → matching reviews (name/synonym/keyword/category), each with its URL and conclusion
list_reviews() → the full catalogue as {topic, slug} pairs (canonical topic + the slug you pass to get_review/get_conclusion)
list_updates(days?) → the change feed, newest first: {title, slug, status, date} per recently published (new) or revised (updated) review. With no arguments it returns the last 7 days, capped at 100 entries; pass days for a wider window (e.g. days: 30)
get_conclusion(slug|url) → just the review's plain-text conclusion
get_review(slug|url) → the full review as raw Markdown
get_metadata(slug|url) → structured medical metadata as JSON — review dates (datePublished/dateModified/lastReviewed, a freshness signal not in the Markdown), the typed about entity with alternate names, and an ordered citation list with PubMed PMIDs
The read tools accept either a bare slug (e.g. rapamycin) or a full evipedia.ai URL (e.g. https://evipedia.ai/rapamycin) — the URL's last path segment is the slug, so a search result's URL can be passed straight through.
suggest_review(intervention, goal?, references?, email?) → submit a new review for an intervention to evipedia's public suggestion form (the same one at evipedia.ai/suggest)
get_version() → the running server's package name and version
Related MCP server: pubmed-mcp-server
The server is published to npm as evipedia-mcp and runs over stdio via npx — no global install needed. It's also listed in the official MCP Registry as io.github.forever-healthy/evipedia-mcp, so MCP-aware clients can discover and install it automatically.
Client config: Local MCP (Requires Node.js ≥ 18)
{
"mcpServers": {
"evipedia": {
"command": "npx",
"args": ["-y", "evipedia-mcp"]
}
}
}For environments where a local install is not possible or desired, we also provide a hosted MCP server at https://mcp.evipedia.ai/ that can be used over HTTP.
Client config: Remote MCP via HTTP
{
"mcpServers": {
"evipedia": {
"type": "http",
"url": "https://mcp.evipedia.ai/mcp"
}
}
}Claude Code — add to your project's .mcp.json (or run claude mcp add).
Claude Desktop — add to claude_desktop_config.json.
Cursor — add to the MCP settings.
You can use the bundled /demo skill to smoke-test the respective connection.
It walks through the read tools (get_version, search_reviews, list_reviews, list_updates, get_review, get_conclusion, get_metadata) against live evipedia.ai data.
The server is a thin client that only uses evipedia.ai's public endpoints. It does not depend on the evipedia content repo — the public surfaces are the API by design.
Fetches live from https://evipedia.ai with a small in-process cache (both JSON indexes are tiny)
Mostly read-only, no auth required. The one write path is suggest_review, which POSTs to evipedia's public suggestion form (Formspree)
Base URL: https://evipedia.ai
Endpoint | Description |
| Full catalogue: |
| Search index: |
| Change feed, newest first: |
| Complete review as raw Markdown (frontmatter + full body) |
| Flattened medical metadata: |
| Agent/human signpost — includes the stable section anchor list |
| Canonical review URLs |
| RSS feed of latest updates |
Get just the plain-text conclusion of an evidence review — the evidence-based bottom line, without the methodology, findings, or references. Prefer this for 'does X work?' questions; use get_review only when the user needs the full evidence, or get_metadata for dates and citations. Takes a slug from search_reviews, list_reviews, or list_updates; a full https://evipedia.ai/{slug} URL is also accepted and normalised to the slug. Read-only, no authentication required; an unknown slug raises "Review not found: {slug}".
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Review slug, e.g. 'rapamycin' (a full evipedia.ai URL is also accepted) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it does most of it: read-only, no authentication required, and the exact error surfaced for an unknown slug ('Review not found: {slug}'). It does not mention rate limits or any caching/response envelope detail, but for a single-resource read the disclosure is well above adequate.
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, each earning its place: scope, routing, then parameter/auth/error mechanics. The most decision-relevant information (what you get, which sibling to prefer) is front-loaded.
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?
There is no output schema, so the description must describe the return, and it does ('plain-text conclusion... evidence-based bottom line, without methodology, findings, or references'). Combined with the slug source guidance and the documented error case, nothing an agent needs to call this correctly is missing.
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% and the schema already documents the slug format and URL acceptance, so the baseline is 3. The description adds value beyond the schema by specifying the provenance of valid slugs (search_reviews, list_reviews, list_updates) and restating URL normalisation and the failure mode for an unknown slug.
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?
States a specific verb and resource ('get just the plain-text conclusion of an evidence review') and immediately bounds the scope by naming what is excluded: methodology, findings, references. It distinguishes itself from get_review and get_metadata within the same sentence, so an agent can route 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit positive trigger ('does X work?' questions) and explicit alternatives with their conditions ('use get_review only when the user needs the full evidence, or get_metadata for dates and citations'). This is a complete when-to-use / when-not-to-use map against named siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a review's structured medical metadata as JSON: review dates (datePublished/dateModified/lastReviewed — a freshness signal absent from the Markdown), the intervention as a typed about entity with alternate names, and an ordered citation list of primary sources (each with a PubMed pmid when available). Use when you need the review's freshness, machine-readable references/PMIDs, or drug classification rather than prose.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Review slug, e.g. 'rapamycin' (a full evipedia.ai URL is also accepted) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the output format (JSON), the structured nature of the returned metadata, and caveats such as 'pmid when available' and 'freshness signal absent from the Markdown'. It does not mention error behavior or permissions, but for a non-mutating getter this is reasonably transparent.
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 two well-organized sentences. The first opens with the verb+resource and lists the key return elements; the second gives direct use cases. Every clause adds value, with no filler or redundancy.
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 the tool's simplicity (one required parameter) and lack of output schema, the description fully compensates by enumerating the returned fields (dates, about entity, citations) and explaining when to use the tool. The schema handles the parameter semantics, and the description provides sufficient context for correct invocation.
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% for the single parameter, including an example and note that a full URL is accepted. The tool description adds no additional parameter details beyond the schema, so the baseline score of 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 verb 'Get' and the resource 'a review's structured medical metadata as JSON', then enumerates the specific contents (dates, about entity, citations). It distinguishes itself from siblings by emphasizing 'rather than prose' and the freshness signal 'absent from the Markdown', making the tool's unique role clear.
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 explicitly says when to use this tool: 'Use when you need the review's freshness, machine-readable references/PMIDs, or drug classification rather than prose.' It provides clear use cases and an implied exclusion of prose needs, but does not explicitly name an alternative tool like get_review, so it falls just short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full evidence review as raw Markdown — methodology, findings, safety, dosing, and references. Reviews are long (often 10k+ tokens); use get_conclusion when the bottom line is enough, or get_metadata for machine-readable dates and citations. Takes a slug from search_reviews, list_reviews, or list_updates; a full https://evipedia.ai/{slug} URL is also accepted and normalised to the slug. Read-only, no authentication required; an unknown slug raises "Review not found: {slug}".
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Review slug, e.g. 'rapamycin' (a full evipedia.ai URL is also accepted) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden and discharges it: discloses output format (raw Markdown), size risk (often 10k+ tokens), auth profile (read-only, no auth), and the exact error string for an unknown slug. These are the traits an agent needs to plan around token cost and failure handling.
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?
Two tight sentences plus an error clause; content is front-loaded with the resource and return shape before routing advice. No filler or restatement of the tool name.
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?
Complete for a no-auth read tool: call source, format, size, alternatives, and error behavior are all covered. Minor gap: no output schema exists and pagination/truncation behavior for 10k+ token payloads is not addressed.
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 covers the single parameter at 100%, but the description adds real value beyond it: URL acceptance and normalisation to slug ('a full https://evipedia.ai/{slug} URL is also accepted and normalised to the slug') and the provenance of valid slugs. That is semantics the schema only gestures at.
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?
States a specific verb and resource ('Get the full evidence review') and enumerates the returned sections (methodology, findings, safety, dosing, references). Explicitly distinguished from siblings get_conclusion (bottom line) and get_metadata (machine-readable fields), so an agent can route without opening other schemas.
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?
Gives an explicit when-to-use signal ('when the bottom line is enough' selects get_conclusion) and names get_metadata for structured dates/citations. Also routes input source: slug comes from search_reviews, list_reviews, or list_updates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the running evipedia MCP server's package name and version. Useful to confirm which build is loaded.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states that the tool retrieves the 'running' server's package name and version, which implies a read-only operation without side effects. However, it does not explicitly disclose whether any network call or latency is involved, nor does it confirm that the operation is non-destructive. For such a simple query, this is adequate but not richly detailed.
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 two sentences long: the first states what the tool does, and the second adds a practical use case. It is front-loaded with the action, every sentence earns its place, and there is no fluff or redundancy.
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 the tool's simplicity (no parameters, no output schema, no annotations), the description is complete enough. It clearly explains what is returned (package name and version) and why it might be used. There are no complex behaviors or side effects to document, so the description fully satisfies the context needs.
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 tool has zero parameters, so the baseline is 4. The description appropriately adds no parameter-related information since there are no parameters to explain. It focuses on the tool's purpose, which is sufficient.
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's purpose with a specific verb and resource: 'Get the running evipedia MCP server's package name and version.' It is distinct from sibling tools that handle reviews, metadata, and interventions, making its purpose 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 a clear usage context: 'Useful to confirm which build is loaded.' This implies when to use the tool (e.g., verifying the server version). It does not explicitly mention alternatives or when not to use it, but given the tool's unique function, this is adequate and provides clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every evidence review in the evipedia.ai catalogue. Returns a JSON array of {topic, slug}, where topic is the review's canonical topic and slug is its identifier. Pass a slug directly to get_review or get_conclusion; the full review URL is https://evipedia.ai/{slug} (raw Markdown at https://evipedia.ai/{slug}.md). A bare topic (just the intervention name, e.g. 'Rapamycin') implies the default Health & Longevity goal; a topic with an explicit goal (e.g. 'Botox for Skin Rejuvenation') is a review targeting that specific goal. Use to enumerate or browse the full catalogue; use search_reviews to find specific reviews.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return shape (JSON array of {topic, slug}), URL conventions, and the topic naming semantics (bare vs. explicit goal). It does not mention potential pagination or volume, but for a simple listing, the behavior is sufficiently transparent.
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 efficiently structured: the purpose is front-loaded in the first sentence, followed by output details, URL patterns, topic semantics, and usage guidance. Every sentence earns its place without redundancy.
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 parameterless tool with no output schema and no annotations, the description is remarkably complete. It covers return format, field meanings, URL templates, topic nuances, and sibling tool relationships. Nothing critical is missing for an agent to select and invoke this 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?
The input schema is empty (0 parameters), so schema coverage is trivially 100%. The description adds no parameter semantics because there are none, but it enriches the output understanding by explaining the structure and downstream usage, which is more than a baseline for a parameterless tool.
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 'List every evidence review in the evipedia.ai catalogue' with a specific verb and resource. It distinguishes from siblings by name-dropping search_reviews for finding specific reviews and get_review/get_conclusion for consuming the returned slugs.
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 gives explicit guidance: 'Use to enumerate or browse the full catalogue; use search_reviews to find specific reviews.' It also explains how to use the output (pass a slug to get_review or get_conclusion), covering both when to use and how to follow up.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recently published or revised evipedia.ai reviews, newest first — the catalogue's change feed. Returns a JSON array of {title, slug, status, date}, where status is 'new' (first publication) or 'updated' (an existing review revised) and date is YYYY-MM-DD. Called with no arguments it returns the last 7 days, capped at the 100 most recent entries; pass days for a different window (e.g. days: 30) — an explicit days is never capped, so a wide window can return hundreds of entries. The full review is at https://evipedia.ai/{slug}, and get_conclusion/get_review take the slug. Use this for recency ('what's new?'); use list_reviews to enumerate the whole catalogue and search_reviews to find a specific intervention.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Only include reviews dated on or after (today − N days), e.g. 7 for the past week. Omit to use the default 7-day window. The catalogue turns over quickly — a large window returns hundreds of entries. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and delivers: states the output shape ({title, slug, status, date}), explains status values ('new' vs 'updated'), formats the date (YYYY-MM-DD), discloses the default 7-day window and the 100-entry cap, and warns explicitly that providing `days` removes the cap and can return hundreds of entries. This is rich operational context agents need and cannot get elsewhere.
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?
Front-loaded purpose, then output shape, then behavior, then sibling routing in one flow. All sentences earn their place. Slightly dense — the URL template and per-field explanation could be tightened, but nothing is wasted.
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?
No output schema exists, so the description must explain return values — and it does, field by field. For a single-parameter read tool with no annotations, this covers everything an agent needs: purpose, shape, defaults, limits, and call-site routing.
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% so the schema already documents `days`. The description still adds the semantics of the cap interaction ('an explicit days is never capped'), which is behavioral nuance the schema does not convey. While it does not add new syntax, the cap behavior is genuinely extra meaning.
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 gives a precise verb+resource ('List recently published or revised evipedia.ai reviews') and a memorable framing ('the catalogue's change feed'), immediately distinguishing it from the static list_reviews and search_reviews siblings.
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?
Explicit routing: 'Use this for recency; use list_reviews to enumerate the whole catalogue and search_reviews to find a specific intervention.' It also points to get_conclusion/get_review for retrieving a full review once a slug is known. This covers when-to-use, when-not, and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search evipedia.ai evidence reviews by name, synonym, keyword, or category. A discovery tool: returns the matching reviews (goal-qualified topic + URL) ranked by relevance so you can tell whether a review exists. To read one, pass its slug to get_conclusion (quick bottom line) or get_review (full Markdown).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query — intervention name, synonym, drug class, or category |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility. It discloses that results are ranked by relevance, include goal-qualified topic and URL, and that the tool only tells whether a review exists. This is meaningful behavioral context beyond a simple 'search' statement.
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 compact and front-loaded with the verb and resource. Three sentences each add distinct value: what it searches, what it returns, and how to proceed after finding a match. There is no redundant or filler content.
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 a simple one-parameter tool with no output schema or annotations, the description is sufficiently complete. It covers purpose, result format, and follow-up actions, leaving little ambiguity about expected behavior. Minor omissions like pagination or result limits are not critical for this discovery tool.
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 schema already provides 100% coverage for the single 'query' parameter with a clear description. The tool description adds context about search dimensions (name, synonym, keyword, category) and return behavior, but does not fundamentally alter or deepen the parameter meaning beyond what the schema states.
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 searches evidence reviews by name, synonym, keyword, or category. It is explicitly described as a discovery tool that returns matching reviews with topic and URL, distinguishing it from read tools like get_conclusion and get_review.
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 tells the agent when to use the tool (to check if a review exists) and provides explicit next steps by mentioning get_conclusion for quick bottom line and get_review for full Markdown. It does not explicitly contrast with list_reviews, but the search-oriented behavior is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Suggest a new review for evipedia.ai — propose an intervention the catalogue doesn't cover yet. Submits to evipedia's public suggestion form (the same one at evipedia.ai/suggest). Use only when the user explicitly wants to propose a new review — this sends a message to the evipedia team. Search first with search_reviews to confirm the catalogue doesn't already cover it. Only intervention is required; goal, references, and email are optional and are forwarded verbatim. Returns a plain-text confirmation on success and raises "Suggestion failed: HTTP {status}" otherwise. Not idempotent — calling it twice files two separate suggestions.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | No | Optional health or longevity goal the intervention targets | |
| No | Optional submitter email, so the evipedia team can follow up | ||
| references | No | Optional supporting references or links | |
| intervention | Yes | Name of the intervention to suggest (e.g. 'Urolithin A') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so: it discloses that a message is sent to the evipedia team via a public form, the success return format (plain-text confirmation), the failure format ('Suggestion failed: HTTP {status}'), and non-idempotency ('calling it twice files two separate suggestions'). These are exactly the side-effect traits an agent needs before invoking a write/submit 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?
Purpose and submission target are front-loaded, followed by usage constraints, required params, and return/error semantics in a tight sequence. Each sentence adds a distinct, necessary fact with no filler.
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 non-idempotent submit tool with no annotations and no output schema, the description covers everything an agent needs: when to call it, the gating precondition, the alternative to check first, required vs optional params, and both success and failure outcomes.
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%, so the baseline is 3, but the description adds meaning beyond the schema by clarifying that only `intervention` is required, that goal/references/email are optional, and that optional values are forwarded verbatim to the team. That forwarding behavior is not expressed in the schema.
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?
It names a specific verb (suggest/propose) and resource (a new review/intervention not in the catalogue) and explicitly identifies the submission target. It is clearly distinguishable from siblings like search_reviews, list_reviews, and get_review.
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?
It states the exact precondition ('use only when the user explicitly wants to propose a new review') and the exclusion implied by that. It also prescribes the alternative workflow: search first with search_reviews to confirm the catalogue doesn't cover it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.29suggest_interventionsuggest_reviewv0.1.28list_updatesv0.1.26get_conclusionget_metadataget_reviewget_versionlist_reviewssearch_reviewssuggest_interventionScored across 8 tools
Each tool has a clearly distinct purpose: catalog listing, discovery search, change feed, conclusion retrieval, full review, suggestion submission, and metadata. The descriptions explicitly differentiate similar tools (e.g., get_conclusion vs get_review vs get_metadata), making misselection unlikely.
All tools follow a consistent snake_case verb_noun pattern (get_version, list_reviews, search_reviews, etc.), with clear and predictable names matching their actions.
8 tools is well-scoped for an evidence review server, covering retrieval, discovery, metadata, and suggestion submission without redundancy or bloat.
The surface covers the full lifecycle: browsing, searching, reading conclusions, full reviews, metadata, recent updates, version check, and even proposing new reviews. No obvious gaps for the stated domain.
Shared, peer-validated knowledge archive for AI agents — search, contribute, and validate via MCP
MCP server for building and testing AI agents with multi-model experimentation and insights.
MCP-native web evidence and claim verification: cited, source-grounded evidence for AI agents.
