vaglio-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose: vaglio_search finds works, vaglio_read retrieves full text, vaglio_status shows budget/blocked hosts, vaglio_sources catalogues sources, vaglio_appraise attaches evidence tiers, vaglio_inscribe archives runs. No ambiguity.
Naming Consistency5/5
All tool names follow a consistent 'vaglio_<verb>' pattern with lowercase and underscores. Verbs are descriptive and match the action (search, read, status, sources, appraise, inscribe).
Tool Count5/5
Six tools is well-scoped for the server's purpose of searching, reading, appraising, and archiving bibliographic works. Each tool earns its place without unnecessary overlap.
Completeness5/5
The tool set covers the full logical workflow: search, retrieve full text, check system status, list sources, appraise evidence, and archive results. No obvious gaps for the intended domain.
Average 3.9/5 across 6 of 6 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- No stable releases found
- 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?
No annotations provided, so description carries full burden. Discloses that Tier D leaves a trace (refused_reason) and that Tier A requires abstract. However, does not explain if the tool is idempotent, destructive, or any 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured with line breaks. Every sentence adds value. Not excessively verbose, though could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters (3 required), no output schema, and no annotations, the description covers high-level behavior but lacks detail on many parameters and return value. Incomplete for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only explains abstract and refused_reason semantics. With 0% schema coverage, few parameters (doi, transfer, mechanism, fulltext_path) are left unexplained. Description does not compensate for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool attaches an evidence tier to a claim, with specific context for Tier A and Tier D. Distinguishes from siblings implicitly through action (appraise vs search/read/status/sources/inscribe).
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?
Provides guidance on when to use Tier A (abstract required) and Tier D (requires refused_reason). Does not compare to sibling tools, but the difference in action 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 fully bears the burden of behavioral disclosure. It explains the retrieval strategy (native readers then Unpaywall), storage behavior, the 'read_depth' reporting logic, and the honest failure mode (returns metadata-only depth). It adds valuable transparency beyond the structured fields.
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: first states the core purpose, second outlines the process, third clarifies the outcome. Every sentence adds value, and the key information is front-loaded.
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 the complexity of the tool (6 parameters, no output schema, no annotations), the description adequately covers workflow and behavior but lacks parameter details and return value structure. It is minimally complete for an agent to understand the tool's main function but incomplete for correct parameter usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning no parameter descriptions exist in the schema. The description does not explain any of the 6 parameters (doi, pmcid, title, oa_url, source, arxiv_id), leaving the agent without necessary context for correct 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 it retrieves and stores the body of a work, with a specific verb-resource pair. It distinguishes from sibling tools (search, status, sources, appraise, inscribe) by focusing on full-text retrieval and storage.
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 usage when full-text retrieval is needed, but does not explicitly state when to use or not use this tool versus alternatives. It provides context of the fallback process but lacks clear exclusions or alternative tool references.
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 discloses key behaviors: copies full text, regenerates index, and refuses status='falsified'. It does not cover all aspects (e.g., error handling, idempotency) but is notably transparent about side effects and constraints.
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 five sentences, each adding value: core action, context, side effects, refusal rule. No redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, no annotations, and no output schema, the description is insufficient. It explains the main function and a key constraint, but the bulk of parameters are unelaborated, leaving agents to infer meaning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only mentions the 'status' parameter (via refusal) and implicitly 'body' (as full text). The other 9 parameters (kin, tier, method, session, disclosure, etc.) remain unexplained, providing minimal semantic help.
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 'write' and the resource 'archive as a versioned, schema-valid record'. It distinguishes from siblings (search, read, status, sources, appraise) by detailing the inscribing action.
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 usage for finalizing a run into the archive ('closes the loop'), but lacks explicit when-to-use vs alternatives or when-not-to-use. No direct comparison to siblings.
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 failover across sources, rate limit skipping, and response reporting of refusals. It does not mention destructive behavior (none expected) or return format, but the core behavior is well explained.
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: two short paragraphs plus an Args list. The first sentence front-loads the purpose, and every sentence adds value without 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?
Given no output schema, the description covers the failover and response reporting. However, it could specify the return value structure (e.g., list of works) for full completeness. Still, it provides essential context for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explicitly documents all three parameters: query (search terms), limit (max results with budget hint), and prefer (force source). This adds significant meaning beyond the raw schema, making the tool usable.
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 'Find works across the open bibliographic sources,' specifying the verb 'find' and the resource 'works'. It also mentions the failover behavior, distinguishing it from sibling tools like vaglio_read or vaglio_status.
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 explains the failover behavior and the optional prefer parameter, implying when to use it (searching across multiple sources). However, it does not explicitly mention when not to use this tool or provide direct comparisons to sibling tools, leaving usage guidance mostly implied.
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 exist, so the description carries full burden. It describes the conceptual behavior (roles and failover) but does not disclose operational traits like read-only nature, external calls, or safety. For a simple catalogue tool, this is adequate but could be more explicit.
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 with two short paragraphs. The first sentence is front-loaded with purpose. Every sentence adds unique information (catalogue, role explanation, failover). No wasted words.
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 zero-parameter tool with no output schema, the description adequately conveys the tool's value and output concept. It lacks explicit mention of output format (list, dictionary) but the role context is sufficient for an agent to infer usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so schema coverage is 100%. The description adds value beyond the schema by explaining the output structure (roles). Baseline for 0 params is 4, but the role explanation justifies a 5.
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 is a 'catalogue of sources' explaining what each is good for, with specific roles like finders, opener, readers. This verb-resource combination is precise and distinguishes it from siblings which likely handle different actions (search, read, etc.).
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 explains that roles are not interchangeable and selecting by role makes failover work, implying the tool helps choose the right source for a task. However, it lacks explicit instructions on when to use this tool versus siblings, and no negative guidance is provided.
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 the tool is read-only (show), explains the meaning of output fields (blocked_hours), and implies no destructive behavior. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded purpose, no extraneous information. Every sentence adds value.
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 status tool with no output schema, the description adequately covers return concepts (usable hosts, cooling down, blocked_hours). No missing critical details.
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?
No parameters exist, so description is not required to add parameter info. The baseline is 4 for zero-parameter tools.
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 shows the shared request budget and fleet view of usable/cooling down hosts, with a specific verb 'show' and resource. It distinguishes from sibling tools which are search, read, sources, appraise, inscribe.
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?
Provides clear context about when to use (to check budget) and gives actionable advice ('switch source instead of waiting') when blocked_hours appears. Lacks explicit exclusions but covers key usage context.
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:

[![vaglio-mcp MCP server](https://glama.ai/mcp/servers/Alemusica/vaglio-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Alemusica/vaglio-mcp)

Score Badge

Copy to your README.md:

[![vaglio-mcp MCP server](https://glama.ai/mcp/servers/Alemusica/vaglio-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Alemusica/vaglio-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/Alemusica/vaglio-mcp'

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