QVAC-MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PUBMED_EMAIL | Yes | Your email address (required by NCBI) | |
| PUBMED_API_KEY | No | Optional API key for higher rate limits |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| qvac_indexA | Curated map of WHAT QVAC does + WHERE to read. Call first, then qvac_fetch(url). |
| qvac_fetchB | Fetch one allowlisted QVAC page as plain text. Use URLs from qvac_index. |
| qvac_searchB | Keyword filter over the QVAC index (e.g. 'rag', 'transcription', 'fine-tune', 'models'). |
| track_briefC | ONE-PARAGRAPH summary only. For full spec call track_detail(which). |
| track_detailC | ENTIRE track brief, verbatim full file. Track 1 = ~9k chars transcribed docx. |
| hackathon_rulesA | Bases/rules of the whole hackathon (TyC+Reglas digest). Call when AI needs event rules. |
| qvac_compliance_checkB | DQ guardrail: scans design/code notes for cloud-inference patterns. |
| hackathon_planA | How it works: input track+idea → returns a concrete 48h task breakdown + checklist. It does NOT code; it forces the plan to cover jury weights so nothing scores 0. Example: hackathon_plan('track1','Teams bot extracting MR/CT observations') → day-by-day tasks mapped to Technical/Innovation/Impact/Design/Completion + video script slot. |
| judge_feedbackA | How it works: paste design/code summary → returns a scoring rubric the agent must self-fill 0-10 per criterion with one concrete fix each, plus compliance verdict. Run BEFORE coding and BEFORE delivery. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| skill_planner | |
| skill_builder | |
| skill_reviewer |
TDQS
Scored across 9 tools
Each tool has a clearly distinct role: qvac_index/fetch/search form a browse-retrieve-filter flow, track_brief/track_detail are explicitly tiered summaries, and the remaining tools (rules, compliance, planning, feedback) target separate workflow stages. Even the two discovery-ish tools (qvac_index and qvac_search) are differentiated by map vs. keyword filter.
All names use snake_case and are readable, but they follow multiple conventions: qvac_* for one group, track_* for another, hackathon_* for another, and a lone judge_feedback. There is no uniform verb_noun pattern, though the prefix grouping helps orient an agent.
Nine tools is well within the ideal 3-15 range and each tool earns its place. The count covers knowledge retrieval, track details, hackathon rules, compliance checking, planning, and self-assessment without redundancy or bloat.
The surface is complete for its apparent purpose: an agent can discover QVAC resources, fetch content, search, get track summaries/details, access rules, verify compliance, generate a plan, and run a final judging self-evaluation. There are no dead ends, and the tool chain supports a full hackathon workflow.