How do I use VA Form Generation MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@VA Form Generation MCP Server audit form 21p-0516 in /Users/aponce/Workspaces/vets-website" 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.

VA Form Generation MCP Server

by agilesix

Overview Schema Related Servers Score Discussions

JavaScript

Local

VA Form Generation MCP Server

External MCP server for VA form generation automation - completely separate from the VA codebase, works with any vets-website workspace.

🎯 Purpose

This MCP server provides tools and resources for auditing and fixing scaffolded VA forms to ensure they follow 21P-601 best practices and VA.gov content standards.

Key Benefits:

✅ External - Lives outside VA repo, no code review needed
✅ Reusable - Works with ANY vets-website workspace
✅ Team-friendly - Share across your entire team
✅ Version controlled - Track improvements separately

Related MCP server: Components Build MCP

🚀 Quick Start

1. Install

cd ~/va-form-generation-mcp
npm install

2. Configure Your Claude Environment

Choose the platform(s) you use:

🖥️ Claude Desktop

Add to your ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "va-form-generation": {
      "command": "node",
      "args": [
        "/Users/YOUR_USERNAME/va-form-generation-mcp/index.js"
      ]
    }
  }
}

Replace YOUR_USERNAME with your actual username!

Then restart Claude Desktop - the MCP server will automatically connect.

💻 Claude Code (VS Code Extension)

Create or update .mcp.json in your vets-website workspace root:

{
  "mcpServers": {
    "va-form-generation": {
      "command": "node",
      "args": ["/Users/YOUR_USERNAME/va-form-generation-mcp/index.js"]
    }
  }
}

Also update .claude/settings.local.json to enable the MCP server:

{
  "permissions": {
    "allow": [
      "Read(//Users/YOUR_USERNAME/va-form-generation-mcp/**)"
    ]
  },
  "enableAllProjectMcpServers": true
}

Then reload your VS Code window - Claude Code will detect and load the MCP server.

🔍 Cursor (Claude Code in Cursor)

Same as Claude Code above - create .mcp.json in your workspace root and update .claude/settings.local.json.

Then reload Cursor to activate the MCP server.

💬 ChatGPT

ChatGPT does not currently support MCP servers. However, you can:

Copy the templates from ~/va-form-generation-mcp/templates/
Paste them directly into ChatGPT conversations
Or use GPT Actions (requires custom GPT with API access)

3. Verify Setup

In Claude Desktop, Claude Code, or Cursor:

Show me all available tools from the va-form-generation MCP server

You should see 5 tools listed.

4. Use It!

Use the va-form-generation MCP server to audit form 21p-0516 in /Users/aponce/Workspaces/vets-website

🛠️ Available Tools

`audit_form`

Generate comprehensive audit report for a scaffolded form.

Usage:

Audit form 21p-0516 using the MCP server
Workspace: /Users/aponce/Workspaces/vets-website

Returns:

Form information
Agent execution plan
Expected fixes
Quick start commands

`get_agent_prompt`

Get customized prompt for a specific agent (1-4).

Usage:

Get Agent 2 prompt for form 21p-0516

Returns:

Specialized prompt for that agent
Customized with form-specific paths
Ready to execute

`validate_form`

Run validation checks (schema, syntax, apostrophes, imports).

Usage:

Validate form at /path/to/form checking schema and apostrophes

Returns:

Bash commands to run validation
Expected issues to find

`get_fix_reference`

Get quick reference for common fixes.

Usage:

Show me the yesNoUI fix reference

Options:

yesNoUI - How to fix yesNoUI patterns
radioSchema - How to fix radioSchema calls
apostrophes - How to fix apostrophe syntax
transformers - How to fix submit/prefill transformers
fullNamePath - How to add fullNamePath (critical!)
all - Show all fixes

`generate_orchestration_prompt`

Generate the complete orchestration prompt to launch all 4 agents.

Usage:

Generate orchestration prompt for form 21p-0516

Returns:

Complete prompt to launch all 4 agents
Phase-by-phase execution plan
Expected results

📚 Available Resources

`checklist://master`

Complete master checklist for form generation.

`template://agent-1` through `template://agent-4`

Specialized prompts for each of the 4 agents.

`reference://fixes`

Before/after examples for all 16 fixes.

🎯 Typical Workflow

Option 1: Full Automation

Use the va-form-generation MCP server to:
1. Audit form 21p-0516 in /Users/aponce/Workspaces/vets-website
2. Generate the orchestration prompt
3. Execute all 4 agents

Option 2: Step by Step

1. Audit form 21p-0516 using MCP server

2. Get Agent 1 prompt from MCP server

3. Get Agent 2 prompt from MCP server

4. Get Agent 3 prompt from MCP server

5. Get Agent 4 prompt from MCP server

Option 3: Validation Only

Use MCP server to validate form 21p-0516 for all check types

🏗️ Architecture

┌─────────────────────────────────────┐
│   Claude Desktop / Claude Code      │
└──────────────┬──────────────────────┘
               │ MCP Protocol
┌──────────────▼──────────────────────┐
│  VA Form Generation MCP Server      │
│  (External - ~/va-form-generation)  │
│                                     │
│  Tools:                             │
│  ✓ audit_form                       │
│  ✓ get_agent_prompt                 │
│  ✓ validate_form                    │
│  ✓ get_fix_reference                │
│  ✓ generate_orchestration_prompt    │
│                                     │
│  Resources:                         │
│  ✓ Master checklist                 │
│  ✓ Agent prompts (1-4)              │
│  ✓ Fix references                   │
└──────────────┬──────────────────────┘
               │ File System Access
┌──────────────▼──────────────────────┐
│     vets-website Workspace          │
│  /Users/aponce/Workspaces/...       │
└─────────────────────────────────────┘

📦 What Gets Fixed

Component Patterns (6 fixes)

✅ yesNoUI simplified to yesNoUI('question') ✅ Import paths corrected ✅ radioSchema called with enum values ✅ Duplicate imports removed

Architecture (5 fixes)

✅ IntroductionPage rewritten ✅ ConfirmationPage uses ConfirmationView ✅ submit-transformer follows 21P-601 ✅ prefill-transformer accesses profile ✅ form.js has fullNamePath

Content (3 fixes)

✅ Plain language (you/we, contractions) ✅ Person-centered titles ✅ PDF-accurate labels

Syntax (2 fixes)

✅ Apostrophe errors ✅ Schema validation

Total: 16+ automated fixes

🔧 Development

Run in Dev Mode

npm run dev

Add New Tools

Edit index.js and add to the tools array in ListToolsRequestSchema handler.

Add New Resources

Edit index.js and add to the resources array in ListResourcesRequestSchema handler.

Update Templates

Edit files in templates/ directory.

📖 Examples

Example 1: Quick Audit

I'm working on form 21p-0516. Use the MCP server to audit it and tell me what needs to be fixed.

Workspace: /Users/aponce/Workspaces/vets-website

Example 2: Get Specific Fix

Use the MCP server to show me how to fix the radioSchema pattern

Example 3: Full Automation

Use the MCP server to:
1. Audit form 21p-527ez
2. Generate the orchestration prompt
3. Launch all 4 agents in the correct order

Workspace: /Users/aponce/Workspaces/vets-website

Example 4: Validation

Use the MCP server to validate form 21p-0516 for schema errors and apostrophe syntax

Form path: /Users/aponce/Workspaces/vets-website/src/applications/simple-forms/21p-0516

🎓 Learn More

Master Checklist: templates/master-checklist.md
Agent Prompts: templates/agent-{1-4}-prompt.md
MCP Protocol: https://modelcontextprotocol.io/

Method 1: Git Repository

cd ~/va-form-generation-mcp
git init
git add .
git commit -m "Initial MCP server"
git remote add origin YOUR_REPO_URL
git push -u origin main

Team members clone and configure:

git clone YOUR_REPO_URL ~/va-form-generation-mcp
cd ~/va-form-generation-mcp
npm install
# Add to claude_desktop_config.json

Method 2: npm Package (Private Registry)

npm publish --registry YOUR_PRIVATE_REGISTRY

Team members install:

npm install -g va-form-generation-mcp --registry YOUR_PRIVATE_REGISTRY

❓ FAQ

Q: Does this modify the vets-website repo?

A: No! The MCP server lives completely outside the VA repo. It only provides tools and prompts - Claude does the actual modifications.

Q: Can multiple people use this?

A: Yes! Each team member installs it separately and points it to their own vets-website workspace.

Q: What if the VA changes their patterns?

A: Update the templates in this repo. Everyone pulls the updates. No VA PR needed!

Q: Can I customize it?

A: Absolutely! Edit the templates or add new tools specific to your needs.

Q: Does it work with Claude Code in VS Code?

A: Yes! As long as Claude Code supports MCP servers, it will work.

📝 License

MIT

Questions? Open an issue or ask Claude: "Explain the va-form-generation MCP server"

Available Tools

5 tools

audit_formC

Audit a scaffolded VA form and generate comprehensive fix report following 21P-601 best practices

ParametersJSON Schema

Name	Required	Description
`form_number`	Yes	VA form number (e.g., "21p-0516")
`workspace_path`	Yes	Path to vets-website workspace
`pdf_path`	No	Optional: Path to form PDF for accuracy verification

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It states the tool audits and generates a fix report, implying a read-only analysis, but doesn't disclose behavioral traits like whether it modifies files, requires specific permissions, has rate limits, or what the output format entails. For a tool with no annotations, this leaves significant gaps in understanding its behavior.

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 a single, efficient sentence that front-loads key actions ('Audit' and 'generate'). It avoids redundancy and wastes no words, though it could be slightly more structured by separating purpose from output details.

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 no annotations and no output schema, the description is incomplete. It doesn't explain what a 'comprehensive fix report' includes, how results are returned, or any error handling. For a tool with 3 parameters and complex auditing functionality, more context is needed to guide the agent effectively.

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 schema fully documents parameters. The description adds no additional meaning beyond implying 'form_number' and 'workspace_path' are used for auditing, and 'pdf_path' for 'accuracy verification'. This meets the baseline of 3 since the schema handles parameter documentation adequately.

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?

The description clearly states the action ('Audit') and resource ('scaffolded VA form'), and specifies the output ('comprehensive fix report') and standard ('21P-601 best practices'). It distinguishes from siblings like 'validate_form' by focusing on auditing and generating fix reports rather than just validation. However, it doesn't explicitly contrast with all siblings (e.g., 'get_fix_reference').

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?

The description provides no guidance on when to use this tool versus alternatives like 'validate_form' or 'get_fix_reference'. It mentions 'scaffolded VA form' but doesn't clarify prerequisites, exclusions, or specific contexts. Without usage context, the agent must infer based on tool names alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_orchestration_promptC

Generate the full orchestration prompt to launch all 4 agents

ParametersJSON Schema

Name	Required	Description
`form_number`	Yes	VA form number
`workspace_path`	Yes	Path to vets-website workspace
`pdf_path`	No	Path to PDF file

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions generating a prompt but doesn't explain what the prompt does, how it's used, or any side effects like permissions needed, rate limits, or output format. This leaves significant gaps for a tool that likely orchestrates complex agent workflows.

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, efficient sentence that directly states the tool's purpose without any wasted words. It is appropriately sized and front-loaded, making it easy to understand at a glance.

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 the complexity implied by orchestrating multiple agents and the lack of annotations or output schema, the description is insufficient. It doesn't explain what the generated prompt contains, how it's structured, or what happens after generation, leaving critical context gaps for effective tool use.

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 schema already documents all three parameters (form_number, workspace_path, pdf_path) with descriptions. The tool description adds no additional meaning or context about these parameters beyond what the schema provides, meeting the baseline for high coverage.

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?

The description clearly states the tool's purpose: 'Generate the full orchestration prompt to launch all 4 agents.' It specifies the action ('generate') and the resource ('orchestration prompt'), though it doesn't explicitly differentiate from sibling tools like 'get_agent_prompt' or 'audit_form'.

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 is provided on when to use this tool versus alternatives. The description lacks context about prerequisites, timing, or comparisons to sibling tools such as 'get_agent_prompt' or 'validate_form', leaving usage unclear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_agent_promptC

Get the specialized prompt for a specific agent (1-4)

ParametersJSON Schema

Name	Required	Description
`agent_number`	Yes	Agent number (1-4)
`form_number`	Yes	VA form number to customize prompt
`form_path`	Yes	Path to form directory
`pdf_path`	No	Path to PDF file

TDQS

C2.9/5.0

Behavior2/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 it 'gets' a prompt, implying a read operation, but doesn't disclose behavioral traits such as whether it requires authentication, has rate limits, returns structured data, or handles errors. The description is minimal and misses key operational details.

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, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and every part contributes to understanding the action and scope, making it highly concise and well-structured.

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 no annotations and no output schema, the description is incomplete. It lacks information on what the tool returns (e.g., prompt text, format), error handling, or any behavioral context. For a tool with 4 parameters and no structured output, more detail is needed to guide effective use.

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 schema fully documents all parameters. The description adds no additional meaning beyond implying the agent number is 1-4, which is already covered by the enum in the schema. Baseline score of 3 is appropriate as the schema handles parameter documentation effectively.

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?

The description clearly states the action ('Get') and resource ('specialized prompt for a specific agent'), specifying the agent number range (1-4). It distinguishes from sibling tools like 'audit_form' or 'validate_form' by focusing on prompt retrieval rather than form validation or auditing. However, it doesn't explicitly differentiate from 'generate_orchestration_prompt' which might also involve prompts.

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 is provided on when to use this tool versus alternatives like 'generate_orchestration_prompt' or other sibling tools. The description implies usage when needing a prompt for a specific agent, but lacks context on prerequisites, dependencies, or scenarios where this is preferred over other methods.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_fix_referenceC

Get quick reference for common fixes

ParametersJSON Schema

Name	Required	Description	Default
`fix_type`	Yes	Type of fix to get reference for

TDQS

C2.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. 'Get quick reference' suggests a read-only operation, but the description doesn't clarify what format the reference takes (text, structured data, examples), whether it's cached, if there are rate limits, or what happens with the 'all' option. Minimal behavioral context is provided beyond the basic operation.

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 extremely concise at just 6 words, which is appropriate for a simple lookup tool. It's front-loaded with the core purpose. However, it's arguably too terse given the lack of context about what 'fixes' and 'reference' mean in this domain.

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?

For a tool with no annotations and no output schema, the description is incomplete. It doesn't explain what constitutes a 'fix' in this context, what format the reference takes, or what value this provides compared to sibling tools. The agent must guess the tool's role in the broader system of form/prompt tools.

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% with a well-documented enum parameter, so the schema already provides complete parameter documentation. The description doesn't add any meaning beyond what the schema provides - it doesn't explain what 'fixes' are, what the reference contains, or how different fix_type values affect the output. Baseline 3 is appropriate when schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get quick reference for common fixes' states a general purpose but lacks specificity about what resource is being referenced or what 'fixes' means in this context. It doesn't distinguish this tool from its siblings (audit_form, generate_orchestration_prompt, get_agent_prompt, validate_form) which all seem to relate to forms/prompts/validation. The description is vague rather than tautological.

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 is provided about when to use this tool versus alternatives. The description doesn't mention any prerequisites, context for usage, or relationship to sibling tools. The agent must infer usage from the tool name and parameter alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

validate_formB

Run validation checks on a form (schema, syntax, apostrophes)

ParametersJSON Schema

Name	Required	Description	Default
`form_path`	Yes	Path to form directory
`check_types`	Yes	Types of checks to run

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the types of checks but doesn't cover critical aspects like whether this is a read-only operation, potential side effects, error handling, or performance implications. This leaves significant gaps for a 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?

The description is a single, efficient sentence with no wasted words. It front-loads the core action and lists key check types, making it easy to scan and understand quickly.

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 tool's moderate complexity (validation with multiple check types), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavior, results, or integration with siblings, leaving room for improvement in completeness.

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 schema fully documents both parameters. The description lists check types (schema, syntax, apostrophes), which partially aligns with the 'check_types' enum but omits 'imports' and 'all'. It adds minimal value beyond the schema, meeting the baseline for high coverage.

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?

The description clearly states the tool's purpose with a specific verb ('Run validation checks') and resource ('on a form'), and lists the types of checks (schema, syntax, apostrophes). It distinguishes the tool's function well, though it doesn't explicitly differentiate from sibling tools like 'audit_form'.

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?

The description provides no guidance on when to use this tool versus alternatives like 'audit_form' or other siblings. It lacks context on prerequisites, typical use cases, or exclusions, leaving the agent with no usage direction beyond the basic function.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesv1.0.0Mar 23, 2026
- First observedaudit_form
- First observedgenerate_orchestration_prompt
- First observedget_agent_prompt
- First observedget_fix_reference
- First observedvalidate_form

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.2/5.0

Disambiguation4/5

Most tools have distinct purposes: audit_form and validate_form both check forms but focus on different aspects (comprehensive fixes vs. basic validation), while the other three tools handle orchestration and reference tasks. There is some potential overlap between audit_form and validate_form, but their descriptions clarify different scopes, preventing major confusion.

Naming Consistency4/5

Tool names follow a consistent verb_noun pattern (e.g., audit_form, validate_form, get_agent_prompt), with all using snake_case. The only minor deviation is generate_orchestration_prompt, which is longer but still fits the pattern, maintaining overall readability and predictability.

Tool Count5/5

With 5 tools, this server is well-scoped for VA form generation, covering key tasks like auditing, validation, orchestration, and reference retrieval. Each tool appears to earn its place without redundancy or excessive complexity, making it manageable and focused.

Completeness3/5

The toolset covers validation and auditing well but lacks obvious CRUD operations for forms, such as creating or updating forms. While orchestration and reference tools support the workflow, the absence of core form manipulation tools leaves notable gaps in the domain coverage, which agents might need to work around.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Synapse — GEO Growth Layer A
io.github.calvinling2021-star
Lints + auto-fixes how AI coding agents discover any new product. 24 rules, 6 tools, score 0-100.
Developer Tools Coding Agents
2
Venture Foundry QA A
io.github.ventureagent-ai
Preflight QA for AI-agent deliverables with structured verdicts and repair guidance.
Testing & QA Tools Autonomous Agents AI & Machine Learning
51
mcp A
ai.promptarch
Research-backed linting + generation for agent context files (CLAUDE.md, AGENTS.md, Cursor rules).
Agent Orchestration Developer Tools
32
AI Design Blueprint A
com.aidesignblueprint
Public agentic AI doctrine tools plus authenticated architecture, design, and spec validators.
AI & Machine Learning Autonomous Agents
292

Related MCP Servers

AI Code Toolkit
Developer Tools Coding Agents Code Execution
AgiFlow
A
license
Not graded
quality
A
maintenance
Enables AI coding agents to generate standardized code using scaffolding templates, enforce architectural patterns, and validate outputs programmatically. Supports creating projects from boilerplates and adding features to existing codebases while maintaining team conventions.
Updated a month ago (2026-07-28 10:16 UTC)
161
AGPL 3.0
Components Build MCP
Developer Tools Documentation Access Code Analysis
getlokiui
A
license
B
quality
D
maintenance
Provides AI assistants with tools to grade, generate, and validate UI components against the components.build specification. Supports searching documentation, checking compliance, and generating framework-agnostic accessible components.
Updated 9 months ago (2025-12-03 07:48 UTC)
11
19
Apache 2.0
AIReady MCP Serverofficial
Code Analysis Developer Tools
getaiready
A
license
Not graded
quality
D
maintenance
Enables AI agents to assess AI-readiness and improve AI leverage through analysis tools, resources, and prompts for project scanning and remediation.
Updated 4 months ago (2026-05-10 12:55 UTC)
26
MIT
policy-gate-mcp
CI/CD & DevOps Code Analysis Developer Tools
iestarks
F
license
Not graded
quality
B
maintenance
Policy-as-code gate for AI-SDLC, providing MCP tools to review prompts, diff tool manifests, vet MCP servers, and run evaluation suites for LLM agent repos.
Updated 5 days ago (2026-09-01 20:29 UTC)
1
-

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/agilesix/va-form-generation-mcp'

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

VA Form Generation MCP Server

🎯 Purpose

🚀 Quick Start

1. Install

2. Configure Your Claude Environment

🖥️ Claude Desktop

💻 Claude Code (VS Code Extension)

🔍 Cursor (Claude Code in Cursor)

💬 ChatGPT

3. Verify Setup

4. Use It!

🛠️ Available Tools

audit_form

get_agent_prompt

validate_form

get_fix_reference

generate_orchestration_prompt

📚 Available Resources

checklist://master

template://agent-1 through template://agent-4

reference://fixes

🎯 Typical Workflow

Option 1: Full Automation

Option 2: Step by Step

Option 3: Validation Only

🏗️ Architecture

📦 What Gets Fixed

Component Patterns (6 fixes)

Architecture (5 fixes)

Content (3 fixes)

Syntax (2 fixes)

🔧 Development

Run in Dev Mode

Add New Tools

Add New Resources

Update Templates

📖 Examples

Example 1: Quick Audit

Example 2: Get Specific Fix

Example 3: Full Automation

Example 4: Validation

🎓 Learn More

🚢 Sharing with Team

Method 1: Git Repository

Method 2: npm Package (Private Registry)

❓ FAQ

Q: Does this modify the vets-website repo?

Q: Can multiple people use this?

Q: What if the VA changes their patterns?

Q: Can I customize it?

Q: Does it work with Claude Code in VS Code?

📝 License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

AIReady MCP Serverofficial

Latest Blog Posts

MCP directory API

`audit_form`

`get_agent_prompt`

`validate_form`

`get_fix_reference`

`generate_orchestration_prompt`

`checklist://master`

`template://agent-1` through `template://agent-4`

`reference://fixes`