Click on "Install 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.
| 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, the description carries the burden. It discloses that the output is plain-text (behavioral detail) and that it is just the conclusion, not the full review. It does not mention error handling or side effects, but for a simple read operation, the transparency is adequate and adds value beyond the tool name.
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 a single, front-loaded sentence with no wasted words. It is concise and immediately conveys the tool's purpose.
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 one parameter and no output schema, the description sufficiently explains the return value ('plain-text conclusion'). It does not detail error cases, but given the simplicity, it is complete enough for an agent to understand the tool's function.
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 provides 100% coverage for the single parameter 'slug' including type, description, and example. The tool description adds no additional parameter detail, so the baseline 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 specifies a clear verb ('Get') and resource ('conclusion of an evidence review'), and the qualifier 'just the plain-text' distinguishes it from related tools like get_review or get_metadata. It is unambiguous about what the tool returns.
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 clearly implies when to use this tool: when only the conclusion is needed, not the full review or metadata. However, it does not explicitly name alternatives or state when not to use it. The context is clear but lacks explicit exclusion guidance.
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.
| 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 that the output is 'raw Markdown', which is useful, but it does not mention error behavior, authentication, or whether the tool performs any transformations. This is minimal but not misleading.
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 a single, focused sentence with no filler or redundancy. Every word contributes to explaining what the tool does, making it highly concise.
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 one-parameter tool with no output schema, the description is sufficient: it names the resource, the return format, and implies the lookup mechanism. It could mention that the slug identifies a specific review, but the schema covers this. Overall, the tool is adequately specified within context.
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 already fully documents the 'slug' parameter with an example and the acceptance of a full URL, so schema coverage is 100%. The description adds no additional parameter context, but the schema does the heavy lifting, warranting the baseline score.
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'), the resource ('full evidence review'), and the format ('raw Markdown'). It distinguishes from sibling tools like get_conclusion and get_metadata by emphasizing 'full' review, making its purpose 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 implies use when you need the complete review in Markdown format, but it does not explicitly mention when not to use it or point to alternatives. For a simple get tool, this is adequate but lacks explicit guidance about choosing among siblings.
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 (at most 100 entries); pass days for a different window, e.g. days: 30. 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 the transparency burden and covers output shape, status semantics, date format, default window, ordering, and URL pattern. It is docked because 'at most 100 entries' ambiguously contradicts the schema's statement that a large window returns 'hundreds of entries', leaving the actual cap unclear.
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 five dense sentences, each adding distinct value: purpose, return format, defaults/limits, URL/related tools, and selection guidance. The action is front-loaded in the first clause, and there is no wasted wording.
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 one-parameter list endpoint with no output schema and no annotations, this is nearly complete: it covers input, output schema, defaults, limits, related tools, and use cases. The only gap is the ambiguous cap/volume statement, which slightly weakens an otherwise comprehensive spec.
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 single parameter `days` is already fully described in the schema, including default behavior and window semantics. The description adds only an example ('days: 30') and restates the default, so it satisfies the high-coverage baseline without meaningfully extending 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 opens with 'List recently published or revised evipedia.ai reviews, newest first — the catalogue's change feed', giving a specific verb, resource, and scope. It also distinguishes itself from sibling tools by explicitly contrasting with list_reviews for the whole catalogue and search_reviews for specific interventions.
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 usage guidance: 'Use this for recency ("what's new?")' and names alternatives for other goals. It also states that get_conclusion/get_review take the returned slug, which helps the agent understand downstream tool interactions.
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.
| 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 present, the description carries the full behavioral disclosure burden. It explicitly states that the tool 'submits to evipedia's public suggestion form' and that it 'sends a message to the evipedia team,' making the external side effect clear. It does not mention confirmation behavior, idempotency, or failure modes, but for a simple suggestion-submission tool these are minor gaps.
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 three sentences with no filler: it states the purpose, explains the mechanism (public form at evipedia.ai/suggest), and adds a usage condition. The key side-effect warning is front-loaded near the end of the third sentence, and every clause earns its place.
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 tool is simple: one required string parameter and three optional fields, all documented in the schema. The description provides the essential context for selecting it (new/uncovered intervention, user intent, team notification) and the submission mechanism. It does not explain expected confirmation or response behavior, but that is not critical for invoking a suggestion form.
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 already provides 100% coverage with descriptions for all four parameters. The tool description adds little beyond framing 'intervention' as the main proposal target, so the baseline of 3 applies.
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 action: 'Suggest a new review' with a specific target (evipedia.ai) and defines its scope: 'propose an intervention the catalogue doesn't cover yet.' This immediately distinguishes it from the read-oriented sibling tools like search_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 gives explicit when-to-use guidance: 'Use only when the user explicitly wants to propose a new review.' It also warns about the side effect of sending a message to the evipedia team. However, it does not explicitly name alternative sibling tools for cases like searching or reading existing reviews, so the exclusion is implied rather than fully spelled out.
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. Dates show when Glama detected each change.
v0.1.29suggest_interventionsuggest_reviewv0.1.28list_updatesv0.1.26get_conclusionget_metadataget_reviewget_versionlist_reviewssearch_reviewssuggest_interventionScored across 8 tools
Each tool targets a distinct operation: discovery (search_reviews), enumeration (list_reviews), recency (list_updates), and three retrieval modes (conclusion, full Markdown, structured metadata). Even the similar get_* tools are clearly separated by output format and purpose.
All tool names follow a consistent lowercase snake_case verb_noun pattern: search_reviews, list_reviews, list_updates, get_conclusion, get_review, get_metadata, suggest_review, get_version. The verbs are simple and semantically aligned with each action.
Eight tools is well-scoped for a review catalogue service. Each tool covers a distinct workflow step—discovery, listing, updates, reading content, metadata, and suggestions—without redundancy or bloat.
The tool surface provides full coverage for browsing and retrieving evidence reviews: finding, listing, checking updates, reading conclusions or full reviews, accessing structured metadata with citations, and proposing new reviews. No obvious dead ends or missing lifecycle operations 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 server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/forever-healthy/evipedia-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
