Hedgehog
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| spike_createA | Create a new spike investigation. Initializes a spike with a problem statement, creates the directory structure, and generates the meta-design template for Phase 0. Args: name: Filesystem-safe name (alphanumeric, hyphens, underscores, max 64 chars) problem_statement: The problem this spike investigates |
| spike_listB | List all spike investigations with summary information. |
| spike_deleteA | Permanently delete a spike investigation. Args: name: Spike name to delete confirm: Must be True to confirm deletion |
| spike_archiveB | Archive a spike investigation (move to archive directory). Args: name: Spike name to archive |
| spike_approve_metaA | Approve meta-design and advance spike from Phase 0 to Phase 1. This is a gate: the spike cannot proceed to divergent exploration until the problem framing is approved. Args: name: Spike name |
| spike_update_confidenceA | Record a confidence rating for the spike. All ratings are 0-100. Tracks confidence evolution over time. Args: name: Spike name problem_understanding: How well is the problem understood (0-100) success_criteria_clarity: How clear are the success criteria (0-100) exploration_completeness: How complete is the exploration (0-100) solving_right_problem: Confidence we're solving the right problem (0-100) reason: Optional reason for this assessment |
| spike_add_branchA | Register a new exploration branch for a spike. Branches represent distinct approaches to solving the problem. Can be added during Phase 0 (planning) or Phase 1 (divergent). Args: name: Spike name branch_name: Filesystem-safe branch name description: What this branch explores |
| spike_complete_branchA | Mark a branch as explored and record findings. The findings markdown replaces the branch template content. When enough branches are explored (>=3), the spike automatically advances to Phase 2 (adversarial). Args: name: Spike name branch_name: Branch to mark as explored findings_md: Markdown content with exploration findings |
| spike_mark_dead_endA | Mark a branch as a dead end and document why. Dead-end branches are excluded from synthesis but their documentation is preserved for future reference. Args: name: Spike name branch_name: Branch to mark as dead end reason: Why this branch was abandoned salvageable: Any insights salvageable from this branch |
| spike_add_challengeA | Add adversarial challenge to a branch. Challenges document failure modes, hidden assumptions, and edge cases. When all explored branches are challenged, the spike automatically advances to Phase 3 (synthesis). Args: name: Spike name branch_name: Branch to challenge (must be in EXPLORED status) challenge_md: Markdown content with adversarial challenge |
| spike_synthesizeC | Create synthesis document comparing all explored branches. Args: name: Spike name synthesis_md: Markdown content with synthesis analysis |
| spike_generate_adrB | Generate an Architecture Decision Record from spike artifacts. Builds alternatives from challenged branches and renders the ADR template. Args: name: Spike name title: ADR title context_text: Context/background for the decision decision: The decision being documented |
| spike_approve_adrB | Approve the ADR and mark the spike as completed. This is the final gate. The spike transitions to COMPLETED status. Args: name: Spike name |
| spike_get_stateB | Get the current state of a spike investigation. Args: name: Spike name |
| spike_checkpointA | Create a checkpoint of the current spike state. Checkpoints allow rolling back to a previous state if exploration goes down an unproductive path. Args: name: Spike name label: Human-readable checkpoint label |
| spike_rollbackA | Rollback spike to a previous checkpoint. Restores the full state from the checkpoint snapshot. Args: name: Spike name checkpoint_id: Checkpoint ID to restore from |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| meta_design_template | Generate a meta-design template for starting a spike investigation. This template guides the initial framing phase, helping you define: - Core questions to answer - Success criteria and failure modes - Expertise domains required - Initial confidence assessment |
| branch_template | Generate a branch exploration template for investigating an option. Use this template when exploring a specific approach or solution path. It provides structure for documenting: - Approach details and technical specifics - Pros and cons - Open questions and evidence sources - Confidence assessment |
| challenge_prompt | Generate an adversarial challenge prompt for a branch. Use this to rigorously test a branch approach by identifying: - Failure modes and edge cases - Questionable assumptions - Hidden costs and risks - Gaps in exploration This is Phase 2 of the spike process, designed to reveal weaknesses before committing to a decision. |
| adr_template | Generate an Architecture Decision Record (ADR) template. Generates a blank ADR scaffold for the user to fill in. For a state-aware ADR populated from spike data, use the spike_generate_adr tool instead. Includes sections for: - Context and decision details - Confidence assessment with evidence basis - Alternatives considered and why rejected - Consequences (positive and negative) - Conditions that would change this decision |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/jpalmerr/Hedgehog'
If you have feedback or need assistance with the MCP directory API, please join our Discord server