hve-squad MCP server

Server Quality Checklist

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

Latest release: v0.6.3
Disambiguation4/5
Each stage tool focuses on a distinct phase (research, plan, review, architect) and the descriptions provide clear 'use for' cues. The main overlap risk is between squad_review and squad_architect, or between a stage tool and squad_run, but the intended scope is made explicit enough for an agent to select correctly.
Naming Consistency5/5
All tools follow a consistent squad_<action> pattern in lowercase snake_case. The verbs (research, plan, review, architect, run, federate) are uniform in style, even if 'architect' is used as a verb, and the prefix makes the family relationship obvious.
Tool Count5/5
Six tools is well within the ideal range for a workflow-orchestration server. Each tool covers a distinct stage or meta-operation, and there is no obvious bloat or redundancy; the count feels properly scoped for the stated purpose.
Completeness4/5
The tool set covers research, planning, review, architecture, the full pipeline, and federation setup. However, the squad_run description mentions an 'Implement' stage that has no corresponding standalone tool, which is a minor gap if a caller wants to run only that phase. Overall core workflows are still complete.
Average 4.4/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 95 commits in the last 12 weeks
- Last stable release on August 19, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes routing to a specific reviewer, delegated execution returning Coordinator persona, routing, and dispatch request. Notes tier eligibility. No annotations, so description carries burden; lacks auth or side-effect details but sufficient.
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?
Front-loaded with main purpose, then details. Sentences are efficient; could be slightly tighter but no waste.
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?
Covers purpose, usage, return value, and main parameters. No output schema but explains output conceptually. Adequate for 7-param tool with no annotations.
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 meaning: context param as 'existing design, constraints, IaC', squad param references state directory, and optional profiles listed.
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 the architecture stage, routes to a system architecture reviewer for design review, and lists use cases ('architecture', 'system design', 'components'). It also distinguishes from sibling by mentioning the Azure architect alternate.
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 states when to use ('for architecture, system design, or components requests') and contrasts with an alternate role (Azure HLD/LLD). No explicit when-not, but sibling list provides context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses the routing/classification behavior, the pipeline stages, the council/gate/contract preservation, and the delegated-execution return shape. Minor gaps remain around side effects and failure behavior, but the disclosure is strong for a complex orchestrator 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 dense but reasonably sized for the complexity. Every sentence adds meaningful information: pipeline stages, mode semantics, delegation behavior, and usage boundaries. It is slightly jargon-heavy, but no sentence is wasted.
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 the tool has 8 parameters, no output schema, and no annotations, the description does a good job explaining the overall flow, mode behavior, delegation contract, and when to use it. It could more explicitly describe the return format or conditions for delegated execution, but it covers the primary decision and runtime aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds useful context for mode ('autonomous' vs 'autopilot') and frames the request parameter, but it does not materially enrich the other six parameters beyond what the schema already documents.
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?
Description opens with a specific verb and resource: 'Run the full squad pipeline for any request.' It clearly positions itself as the catch-all entry point and distinguishes it from narrower sibling tools by describing the full Research -> Plan -> Implement -> Review flow.
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?
Explicit guidance is given: 'Use when no narrower squad_* tool fits, or for end-to-end work.' It also explains when each mode should be used, e.g., 'Set mode=autonomous for the bounded validator loop or mode=autopilot for the full gated pipeline.'
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, the description carries the full burden of behavioral disclosure. It reveals key traits: planning is non-parallel, lands no change without confirmation, returns the Coordinator persona, matched routing, and a framed dispatch request. This goes well beyond a minimal statement and tells the agent exactly what to expect.
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 (about three sentences), front-loaded with the primary purpose, and every sentence adds value: what it does, how it behaves, and when to use it. No filler or 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 the tool's complexity (7 parameters, 1 required, no output schema), the description discloses the return format (Coordinator persona, routing, dispatch request) and the non-parallel/confirm behavior. It does not enumerate all optional parameters but the schema covers them. Slightly lacking explicit alternatives for sibling tools, but overall sufficient for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add significant meaning beyond the schema; it mentions 'request' implicitly as the work to plan, but does not elaborate on optional parameters, enums, or formatting. It does not compensate further, so a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool runs the squad's planning stage, with a specific verb ('Run') and resource ('squad's planning stage'). It further specifies the action: route to Squad Lead at 'confirm' tier to break down, sequence, and produce a plan. It distinguishes from siblings by emphasizing planning and non-parallel execution, and lists trigger phrases like 'plan', 'break down', 'sequence', 'design plan'.
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 explicit trigger phrases for when to use the tool ('Use for...'), and implies the context of planning before execution. However, it does not explicitly name alternative tools or state when not to use it, missing a clear exclusion guidance.
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 clearly discloses the delegated execution model: 'returns the Squad Coordinator persona, the matched routing row, and a framed dispatch request; the calling host runs the subagent loop.' It also reveals routing details (researcher role, auto tier, parallel-eligible), which are non-obvious behavioral traits beyond 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each serving a distinct purpose: purpose, routing, execution model, and usage triggers. No redundancy or filler. The density is appropriate for a tool with complex delegation behavior.
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 7 parameters and no output schema, so the description carries the burden of explaining what the caller receives. It does so clearly (persona, routing row, dispatch request) and describes the execution flow. It could add error-handling or prerequisites, but the current description is sufficient for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-specific details beyond the schema's own descriptions; it only broadly frames the request as a 'question or codebase.' No meaningful added semantic 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 opens with a specific verb and resource: 'Run the squad's research stage on a question or codebase.' It distinguishes from siblings by noting this happens 'before any plan or change' and lists concrete trigger phrases ('research', 'investigate', 'explore', 'find out'), making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance via trigger phrases and positions the tool as the precursor to planning/change ('before any plan or change'). It does not explicitly name sibling alternatives, but the 'before' phrasing implies exclusions, and the sibling list provides context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the delegated execution model (returns persona, routing decision, framed dispatch request), the federation registry and meta-routing files it reads, and the scoped state path. It also describes the init and promote modes' effects (propose → confirm → create, relocating state intact). This is substantial behavioral context, though it doesn't detail error conditions or side effects beyond state relocation.
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 dense but well-structured, front-loading the core purpose and then explaining modes and delegation. It's a single paragraph that covers a complex tool without excessive verbosity. The bolded terms help readability, though the length is at the upper end of what's ideal.
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 the tool's complexity (10 params, 4 enums, multiple modes, delegation model) and the absence of annotations and output schema, the description is quite complete. It explains the federation registry, meta-routing, scoped state, init/promote modes, autopilot pipeline, and discovery gate. Minor gaps include not detailing the exact return format or error handling, but the description covers the essential operational context.
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 description coverage is 100%, so the schema already documents all 10 parameters. The description adds value by explaining the interplay between parameters (e.g., init vs promote modes, mode=autopilot with no squad= target, discovery applied per qualifying sub-squad) and how they affect routing. This goes beyond the schema's individual parameter descriptions, though the schema already does most of the work.
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 the squad federation meta layer for repositories with multiple named sub-squads, and distinguishes it from siblings by positioning it as the catch-all federation entry point. It names specific actions (init, promote) and the delegated execution model, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: for cross-sub-squad requests, explicit sub-squad targeting, or federation setup. It also explains the init and promote modes and how they differ, providing clear context for selection. While it doesn't name sibling tools as alternatives, the usage scenarios are well-defined and the tool is positioned as the catch-all entry point, which implicitly differentiates it.
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, the description fully carries the burden and does so richly: it discloses internal routing (Squad Reviewer at 'auto' tier, council row at 'confirm' for go/no-go or cross-domain), and explains delegated execution behavior (returns Coordinator persona, matched routing, framed dispatch request). This provides deep insight beyond 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is 4 sentences, front-loaded with the main purpose, and every sentence contributes meaningful detail without fluff. It efficiently packs routing logic, trigger conditions, and return behavior.
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?
Despite having 7 parameters and no output schema, the description is remarkably complete. It explains the tool's internal logic, delegation behavior, and return value, leaving little ambiguity about what will happen and what the agent will receive.
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%, so the baseline is 3. The description adds some value by explaining how the 'request' parameter influences routing (e.g., go/no-go triggers council), but it does not elaborate on other parameters beyond the schema's existing descriptions.
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 and resource ('Run the squad's review stage') and provides explicit scoping ('review', 'validate', 'check quality', 'council', 'go/no-go'). It distinguishes from siblings by focusing on the review/council workflow rather than planning or execution.
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 lists when to use the tool ('Use for "review", "validate", "check quality", "council", or "go/no-go" requests') and explains conditional council engagement. It does not explicitly state when not to use it or name alternative sibling tools, so it misses the full 5-level guidance.
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:

[![hve-squad-mcp MCP server](https://glama.ai/mcp/servers/Peter-N91/hve-squad-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Peter-N91/hve-squad-mcp)

Score Badge

Copy to your README.md:

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

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