evipedia-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.26
Disambiguation5/5
Each tool has a distinct purpose: search vs. list for discovery, get_conclusion/get_review/get_metadata for different retrieval formats, suggest_intervention for the only write action, and get_version for server info. There is no overlap or potential for misselection.
Naming Consistency5/5
All tools follow a consistent snake_case verb_noun pattern (search_, list_, get_, suggest_). Verbs are uniform and predictable, making the API easy to navigate.
Tool Count5/5
Seven tools is ideal for the server's purpose, covering discovery, reading, metadata, suggestion, and version checking without redundancy or bloat. The scope is well-balanced.
Completeness5/5
The tool surface covers the complete lifecycle of an evidence review database: find reviews (list, search), read them (full, conclusion, metadata), and propose new reviews (suggest). There are no obvious gaps or dead ends.
Average 4.2/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 35 commits in the last 12 weeks
- Last stable release on July 16, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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 tool sends a message to the evipedia team via a public form, which is a key side effect. However, it does not mention whether the action is reversible, requires authentication, or what the tool returns after submission. The disclosed context is helpful but incomplete for a side-effecting write tool.
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?
The description is compact and effective: three sentences. The first sentence states the core purpose, the second adds the submission form detail, and the third clarifies the intended usage restriction. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 4-parameter tool with no output schema and no annotations, the description covers purpose, the external endpoint, and usage restriction. However, it omits what happens after submission (e.g., success message, errors) and does not address whether the email is required for follow-up. These details would help an agent set expectations for the user.
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 baseline is 3. The description adds context about the form ('the same one at evipedia.ai/suggest') but does not add meaning to the individual parameters beyond what the schema already provides. The schema descriptions for params (goal, email, references, intervention) are already clear.
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 clearly states the tool's purpose: 'Suggest a new intervention for evipedia.ai to review' and 'Submits to evipedia's public suggestion form'. It names the specific resource (evipedia.ai) and distinguishes itself from the sibling read-only tools (search_reviews, list_reviews, etc.) by being a submission/write action.
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 explicitly states when to use: 'Use only when the user explicitly wants to propose a new intervention'. It implies not to use for other purposes, and the sibling tools cover reading/reviewing, making the context clear. However, it does not explicitly name alternatives or mention when not to use beyond the stated restriction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![evipedia-mcp MCP server](https://glama.ai/mcp/servers/forever-healthy/evipedia-mcp/badges/card.svg)](https://glama.ai/mcp/servers/forever-healthy/evipedia-mcp)

Score Badge

Copy to your README.md:

[![evipedia-mcp MCP server](https://glama.ai/mcp/servers/forever-healthy/evipedia-mcp/badges/score.svg)](https://glama.ai/mcp/servers/forever-healthy/evipedia-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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