EvalView

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct operation: creating tests, running different types of checks, comparing agents, generating reports, listing, replaying diffs, and validating skills. No overlapping functionality.
Naming Consistency4/5
Nine of ten tools follow a clear verb_noun pattern (e.g., create_test, run_check). The exception is 'replay', which is a single verb but still unambiguous.
Tool Count5/5
10 tools cover the evaluation workflow without being excessive. Each tool serves a specific purpose, and the count is well-suited for the domain.
Completeness4/5
Core workflows are covered: test creation, execution, comparison, reporting, and validation. Minor gap: no explicit tool for deleting or updating tests, but users can manage files directly.
Average 4.1/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 59 of 62 community issues answered or closed in the last 6 months
- 14 commits in the last 12 weeks
- Last stable release on July 26, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
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.
This repository includes a glama.json configuration file.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits (e.g., read-only, side effects, rate limits). It only describes the output, leaving the agent uninformed about potential impacts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-loading the action and output details. No extraneous words; every sentence serves a purpose.
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 zero parameters and no output schema, the description fully explains the tool's behavior and output. It covers what is listed and the nature of the data, making it complete for a simple list operation.
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?
There are zero parameters, so per baseline rule the score is 4. The description adds value by detailing the output contents (test names, variant counts, last updated), which compensates for the lack of parameter info.
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 lists all golden baselines in the project, specifying the resource and details shown (test names, variant counts, last updated). It distinguishes from sibling tools like create_test or run_skill_test, which are write or run operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as compare_agents or generate_visual_report. It simply states what it does without specifying scenarios or exclusions.
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 must cover behavioral traits. It mentions returns (deltas, diffs, HTML) but does not disclose side effects, permissions, or error conditions. It is adequate but not 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, front-loaded with the core action and followed by use cases. Every word adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main workflow and outputs but lacks details on prerequisites (e.g., running agents) and output format specifics. Given 7 parameters and no output schema, it is mostly complete.
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 baseline is 3. The description adds context about A/B testing but does not elaborate on individual parameters beyond what the schema already provides.
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: compare two agent endpoints on the same test suite, returning score deltas and diffs. It distinguishes itself from sibling tools like run_snapshot or create_test by focusing on A/B testing.
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 mentions use cases like A/B testing new models or prompt changes, providing clear context. However, it does not specify when not to use it or mention alternatives among sibling tools.
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, the description carries the full burden. It explains the creation process, auto-detection of test_path, and the need to call run_snapshot. However, it does not disclose whether existing files are overwritten, any side effects, or required permissions, which is a gap for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and usage. It is well-structured but could be slightly more concise; the test_path auto-detection detail could be integrated more tightly without losing clarity.
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?
Given 8 parameters, no output schema, and no annotations, the description covers creation workflow and post-action (run_snapshot). However, it lacks information on what happens if the test already exists (overwrite? abort?), which is crucial for agents. This omission weakens completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds significant value: it explains auto-detection logic for test_path and details the hard-fail semantics of forbidden_tools (case-insensitive, immediate failure). These clarifications go beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Create a new EvalView test case YAML file for an agent.' It distinguishes from sibling tools like compare_agents, run_snapshot, and list_tests, which do not create tests.
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?
Explicit when-to-use guidance: 'Call this when the user asks to add a test, or when you want to capture expected agent behavior.' Also provides workflow: 'After creating a test, call run_snapshot to establish the baseline.' Does not explicitly mention alternatives, but context is clear.
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?
Without annotations, the description partially covers behavior: it reads a file and generates a test suite. However, it omits details on whether it modifies existing files, error handling on invalid paths, or permission requirements. The mention of 'ready-to-run' implies creation but not side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey purpose, usage context, and follow-up action with no redundancy. Every sentence earns its place, making it highly concise and structured.
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 3 parameters, no annotations, and no output schema, the description adequately covers the tool's function and workflow. It mentions test categories and suggests next steps, but lacks details on validation, error handling, or prerequisites.
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 does not add extra meaning beyond the schema; defaults mentioned in the description are also present in schema parameter descriptions, providing no additional value.
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 auto-generates test cases from a SKILL.md file, specifying categories like explicit, implicit, contextual, and negative. This distinguishes it from siblings like 'create_test' or 'run_skill_test' by linking it directly to skill auto-test generation.
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?
Explicitly advises to call when the user asks to create tests for a skill, and recommends subsequent use of 'run_skill_test'. This provides clear context, though it does not explicitly mention when not to use or compare with alternatives like 'create_test'.
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 present, so the description fully discloses key behaviors: generates a self-contained HTML file, auto-opens browser, returns absolute path. It could mention potential side effects or cleanup, but adequately covers behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core purpose, each sentence earning its place. Could be slightly more concise, but structure is clear and efficient.
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 4 parameters, no output schema, and no annotations, the description explains prerequisites (after run_check/run_snapshot), behavior, and return value. It is complete for an agent to decide when and how to invoke.
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 baseline is 3. The description does not add meaning beyond the schema for the four parameters; it only repeats their purpose. For a tool with 0 required parameters, this is adequate but not extra.
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 'generate', the resource 'visual report', and the context 'from the latest evalview check or run results', distinguishing it from sibling tools like run_check and run_snapshot.
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 'Call this after run_check or run_snapshot', providing clear when-to-use guidance. It does not list when not to use or alternatives, but the context signals with sibling tools fill that gap.
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, description carries full burden. States it returns a list of issues and a valid flag. Lacks details on side effects (none expected), permissions, or performance, but adequate for a simple validation 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?
Two sentences, no fluff. Front-loaded with purpose and usage, then return details. Every sentence earns its place.
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?
Complete for a simple one-parameter tool with no output schema. Explains what it validates, when to call, and what it returns. No missing information given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter described as 'Path to the SKILL.md file or directory...' and an example. Description adds no further parameter meaning beyond that, but baseline 3 is appropriate given full schema coverage.
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?
Clearly states the verb (validate) and resource (SKILL.md file), and specifies aspects checked: structure, naming conventions, completeness. Distinguishes from siblings like run_skill_test which runs tests instead of validating structure.
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?
Explicitly tells when to use: 'after writing or editing a SKILL.md before running tests.' Provides clear timing context, though doesn't explicitly list exclusions or alternatives beyond the implied sequencing.
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 full burden. It discloses that the tool opens a browser with an HTML diff report, which is non-destructive. It does not mention any permissions or side effects, but the behavior is well-described and consistent with a read-only viewer.
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 three sentences, each adding distinct information: purpose, content of viewer, and browser behavior. No unnecessary words, front-loaded with the key action, and well-structured.
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 no output schema and no annotations, the description covers the core functionality and parameter behavior. It does not explain return values or error cases, but as a viewer tool that opens a browser, the output is self-evident. Slight gap in explaining prerequisites (e.g., requires prior test run), but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for all three parameters: test_name (optional), test_path (default), no_browser (controls auto-open). The description adds context about 'specific test' and 'opens automatically', aligning with parameters but adding minimal value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it opens a trajectory diff viewer for a specific test, showing side-by-side HTML comparison of baseline vs current behavior. This differentiates it from siblings like compare_agents (compares agents) or run_check (runs checks), as it focuses on viewing diffs for a specific test.
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 implies usage for viewing diffs after running a test, and mentions automatic browser opening. However, it does not explicitly state when to use this tool versus alternatives, such as when to use compare_agents instead. The purpose is clear but guidance on exclusion is lacking.
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 full burden. It discloses that only passing tests are saved (failing tests are skipped with a warning), and it explains the auto-detection of 'test_path'. However, it does not explicitly warn about the destructive nature of the 'reset' parameter, though this is documented in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and then provides structured usage guidelines. It is about 120 words, efficient but with minor redundancy (e.g., repeating auto-detect from schema). Overall well-organized.
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 8 parameters with full schema descriptions and no output schema, the description integrates well with 'run_check' and 'create_test', covers key behavioral aspects, and provides actionable guidance. It lacks edge-case details but is sufficient for an agent to understand and invoke the tool correctly.
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 baseline is 3. The description repeats the auto-detection logic for 'test_path' that is already in the schema, but adds no new parameter-specific insights beyond what the schema provides.
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 'Run tests and save passing results as the new golden baseline,' which is a specific verb-resource combination. It distinguishes from sibling 'run_check' by noting that future calls compare against the snapshot, and it lists explicit use cases.
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 provides explicit, numbered usage guidelines: after creating a test, after confirming a change is intentional, and before large refactors. It also contrasts with 'run_check' and mentions prerequisites like having tests created.
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?
Given no annotations, the description fully discloses the two-phase execution, detailing what each phase checks (tool calls, file ops, etc. in Phase 1; LLM-as-judge for rubric in Phase 2) and notes the cost implication of Phase 2. This is transparent about behavior and resource usage.
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 concise, using only four sentences with no unnecessary words. It front-loads the core action and phases, then provides usage timing and an optimization tip. Every sentence serves a clear 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?
The tool has 5 parameters, 1 required, and no output schema. The description adequately covers the two-phase process and the optional rubric skip. While it doesn't explain output format or logging, the description is sufficient given the tool's complexity and the presence of sibling tools for other tasks.
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 schema covers all 5 parameters with descriptions (100% coverage). The description adds value by explaining the 'no_rubric' parameter's purpose and effect beyond the schema description, clarifying it enables faster checks without LLM cost. This extra context aids selection and invocation.
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 runs a skill test suite against a SKILL.md and distinguishes between two evaluation phases. The verb 'run' plus the noun 'skill test suite' specifically identifies the purpose, and the two-phase detail sets it apart from sibling tools like 'validate_skill' or 'run_check'.
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 includes explicit guidance on when to call the tool: 'after writing skill tests or after any change to the skill or agent.' It also provides a conditional use case with '--no-rubric' for fast checks. However, it does not mention when not to use it or suggest specific alternatives from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden. It describes the return statuses and their meanings, observability signals, auto-detection of test_path, behavior of heal=true, and the recommendation to treat REGRESSION as blocking. It also explains flaky failure handling and the strict flag's effect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat lengthy but well-structured: it starts with the core result summary, then usage guidelines, then important notes like test_path detection. Every sentence adds value, though it could be slightly more concise without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 parameters, no output schema, 0 required params), the description covers return values, usage context, parameter behavior, and includes an important automated behavior (test_path detection). This provides sufficient context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have schema descriptions (100% coverage). The description adds extra context beyond the schema, such as auto-detection logic for test_path and the purpose of heal for distinguishing non-determinism. This adds value but does not compensate for missing schema descriptions since none are missing.
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 checks for regressions against a golden baseline and returns diff summaries with specific statuses (PASSED, REGRESSION, etc.). It also lists observability signals. This distinguishes it from sibling tools like run_skill_test (which likely runs tests without baseline comparison) and replay (which replays interactions).
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 advises using this tool 'after any code change (prompt, model, tools) to confirm nothing broke.' It also instructs to show diff and offer to fix if regression is found. However, it does not explicitly contrast with alternatives among sibling tools, such as when to use run_skill_test instead.
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:

[![eval-view MCP server](https://glama.ai/mcp/servers/hidai25/eval-view/badges/card.svg)](https://glama.ai/mcp/servers/hidai25/eval-view)

Score Badge

Copy to your README.md:

[![eval-view MCP server](https://glama.ai/mcp/servers/hidai25/eval-view/badges/score.svg)](https://glama.ai/mcp/servers/hidai25/eval-view)

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/hidai25/eval-view'

If you have feedback or need assistance with the MCP directory API, please join our Discord server