Skip to main content
Glama
vaibhavkkk

GalaxyMCP Server

by vaibhavkkk
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

GalaxyMCP Server

🌌 A Model Context Protocol (MCP) server for AI persona management with Galaxy theme. Built with TypeScript and designed for seamless integration with AI assistants like Claude and Augment AI.

Features

  • 🎭 Persona Management: Activate different AI personalities for specialized tasks

  • 🛠️ 6 MCP Tools: Complete persona lifecycle management

  • 🎫 JIRA Integration: Full JIRA API support with 8 additional tools for ticket management

  • 📝 Markdown-Based Personas: Easy-to-edit persona definitions with YAML frontmatter

  • 🔧 TypeScript: Type-safe development with modern ES modules

  • 🌟 Galaxy Theme: Space-themed indicators and branding

  • 🚀 Simplified Architecture: Streamlined codebase for easy understanding and extension

  • 📦 Self-Contained: All persona logic in a single main file for clarity

Related MCP server: Jira MCP Server

Available Tools

Persona Management Tools

Tool

Description

list_personas

List all available personas with details

activate_persona

Activate a specific persona by name or filename

get_active_persona

Get currently active persona information

deactivate_persona

Return to default mode

get_persona_details

View detailed persona information and content

reload_personas

Refresh personas from filesystem

JIRA Integration Tools (Optional)

Available when JIRA is configured with required environment variables

Tool

Description

get_jira_ticket

Retrieve JIRA ticket information by ticket key

create_jira_ticket

Create a new JIRA ticket (story) with workspace intelligence

create_jira_epic

Create a new JIRA epic for organizing multiple related stories

update_jira_ticket

Update an existing JIRA ticket with new information

add_jira_comment

Add a comment to an existing JIRA ticket

link_jira_story_to_parent

Link a JIRA story to its parent ticket

link_jira_epic_to_parent

Link a JIRA epic to its parent ticket

attach_file_to_jira

Attach a file to an existing JIRA ticket

Built-in Personas

  • Technical Analyst - Systematic problem-solver for deep technical analysis and architectural decisions

Prerequisites

  • Node.js: v20.0.0 or higher

  • npm: v10.0.0 or higher

  • TypeScript: v5.0.0 or higher

Quick Start

1. Installation

# Navigate to the project directory
cd /Users/vkakkar/Documents/self/Projects/AI_MCP/galaxymcp-server

# Install dependencies
npm install

# Build the TypeScript code
npm run build

2. Environment Setup (Optional)

# Set user identity for persona attribution
export GALAXY_USER="your-username"

# Custom personas directory (optional)
export GALAXY_PERSONAS_DIR="/path/to/custom/personas"

# JIRA Integration (optional)
export JIRA_BASE_URL="https://your-company.atlassian.net"
export JIRA_EMAIL="your-email@company.com"
export JIRA_TOKEN="your-jira-api-token"
export JIRA_SUB_COMPONENT="Galaxy-Core"

JIRA Configuration

To enable JIRA integration, you need to set up the following environment variables:

  1. JIRA_BASE_URL: Your JIRA instance URL (e.g., https://company.atlassian.net)

  2. JIRA_EMAIL: Your JIRA account email

  3. JIRA_TOKEN: Your JIRA API token (How to create)

  4. JIRA_SUB_COMPONENT (optional): Default component for created tickets

Creating a JIRA API Token:

  1. Go to Atlassian Account Settings

  2. Click "Create API token"

  3. Give it a label (e.g., "GalaxyMCP")

  4. Copy the generated token

3. Test the Server

# Start the server
npm start

# Or with environment variables
GALAXY_USER="vaibhavkkk" npm start

Expected Output:

GalaxyMCP server running on stdio
Loaded persona: Technical Analyst (technical-analyst_20250714-130000_galaxymcp)

Integration with Augment AI

Step 1: Get Absolute Path

# Get the absolute path to your GalaxyMCP installation
cd /Users/vkakkar/Documents/self/Projects/AI_MCP/galaxymcp-server
pwd
# Copy this path: /Users/vkakkar/Documents/self/Projects/AI_MCP/galaxymcp-server

Step 2: Configure MCP Server in Augment AI

  1. Open IntelliJ IDEA

  2. Go to Preferences (⌘ + ,)

  3. Navigate to Tools → Augment AI → MCP Servers (or similar)

  4. Add new MCP server with these settings:

Configuration:

{
  "mcpServers": {
    "galaxymcp": {
      "command": "node",
      "args": ["/Users/vkakkar/Documents/self/Projects/AI_MCP/galaxymcp-server/dist/index.js"],
      "env": {
        "GALAXY_USER": "vaibhavkkk",
        "JIRA_BASE_URL": "https://your-company.atlassian.net",
        "JIRA_EMAIL": "your-email@company.com",
        "JIRA_TOKEN": "your-jira-api-token",
        "JIRA_SUB_COMPONENT": "Galaxy-Core"
      }
    }
  }
}

Note: JIRA environment variables are optional. If not provided, only persona management tools will be available.

Step 3: Restart and Test

  1. Restart IntelliJ IDEA completely

  2. Open Augment AI panel

  3. Look for GalaxyMCP tools in available tools

  4. Test with: list_personas

Usage Examples

Basic Persona Management

# List all available personas
list_personas

# Activate the Technical Analyst persona
activate_persona "Technical Analyst"

# Get details about current persona
get_active_persona

# View full persona details
get_persona_details "Technical Analyst"

# Deactivate persona
deactivate_persona

Working with Technical Analyst

Once activated, the Technical Analyst persona will:

  • Provide systematic technical analysis

  • Focus on architectural decisions

  • Consider scalability and performance

  • Offer detailed debugging approaches

  • Suggest concrete implementation steps

JIRA Integration Examples

Available when JIRA is configured

# Get ticket information
get_jira_ticket "ENG-12345"

# Create a new story
create_jira_ticket {
  "summary": "Implement user authentication",
  "description": "Add JWT-based authentication to the API",
  "issue_type": "Story",
  "labels": ["backend", "security"]
}

# Create an epic
create_jira_epic {
  "summary": "User Management System",
  "description": "Complete user management functionality",
  "labels": ["epic", "user-management"]
}

# Add a comment
add_jira_comment {
  "ticket_key": "ENG-12345",
  "comment_text": "Implementation completed and ready for review"
}

# Link a story to an epic
link_jira_story_to_parent {
  "story_key": "ENG-12346",
  "parent_key": "ENG-12345",
  "link_type": "Blocks"
}

Project Structure

galaxymcp-server/
├── src/
│   ├── index.ts                 # Main MCP server with all logic
│   ├── types/
│   │   ├── persona.ts          # Persona type definitions
│   │   ├── mcp.ts              # MCP-related types
│   │   └── index.ts            # Type exports
│   ├── persona/
│   │   └── PersonaManager.ts   # Persona loading and management (unused in current impl)
│   └── utils/
│       └── filesystem.ts       # Utility functions (unused in current impl)
├── personas/
│   └── technical-analyst.md    # Technical Analyst persona
├── dist/                       # Compiled JavaScript (auto-generated)
├── package.json               # Project configuration
├── tsconfig.json              # TypeScript configuration
├── README.md                  # This file
├── LICENSE                    # MIT License
└── .gitignore                 # Git ignore rules

Note: The current implementation uses a simplified architecture where all logic is contained in src/index.ts for clarity and ease of understanding.

Development

Available Scripts

npm run build      # Compile TypeScript
npm run start      # Run the server
npm run dev        # Watch mode for development
npm run clean      # Remove compiled files
npm run rebuild    # Clean and rebuild
npm run setup      # Install deps and build

Adding New Personas

  1. Create a new .md file in the personas/ directory

  2. Follow the YAML frontmatter format:

---
name: "Your Persona Name"
description: "Brief description"
triggers: ["keyword1", "keyword2"]
version: "1.0"
author: "your-username"
category: "professional"
unique_id: "your-persona_20250714-130000_your-username"
---

# Your Persona Name

Your persona instructions go here...

  1. Reload personas: reload_personas

Troubleshooting

Common Issues

"Cannot find module" errors:

npm install
npm run build

Personas not loading:

# Check personas directory exists
ls -la personas/

# Reload personas
reload_personas

Augment AI doesn't see tools:

  • Restart IntelliJ completely

  • Verify absolute paths in MCP configuration

  • Check Augment AI plugin version supports MCP

Debug Mode

# Run with debug output
DEBUG=galaxymcp:* npm start

# Check server compilation
node --version  # Should be v20+
npm run build   # Should complete without errors

Environment Variables

Variable

Description

Default

GALAXY_USER

User identity for persona attribution

null

GALAXY_PERSONAS_DIR

Custom personas directory

./personas

Architecture Notes

This implementation uses a simplified architecture compared to DollhouseMCP:

  • Single File Logic: All MCP server logic is in src/index.ts

  • Inline Persona Management: Persona loading and management is built into the main server class

  • Direct Tool Handling: Tools are handled directly in the main server without separate tool registry

  • Simplified Types: Minimal type definitions for clarity

This approach makes the codebase easier to understand and modify while maintaining full MCP compatibility.

License

MIT License - see LICENSE file for details.

Contributing

  1. Fork the repository

  2. Create a feature branch

  3. Make your changes

  4. Test thoroughly

  5. Submit a pull request

🌌 Transform your AI interactions with the power of Galaxy personas!

Available Tools

6 tools
activate_personaA

Activate a specific persona by name or filename

ParametersJSON Schema
NameRequiredDescriptionDefault
personaYesThe persona name or filename to activate

TDQS

A3.5/5.0
Behavior2/5

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

No annotations are provided, so the description must carry full burden. It only states 'activate' without disclosing side effects, permission requirements, or what happens to the current state. This is insufficient for an agent to understand behavioral implications.

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 sentence of 7 words, extremely concise and front-loaded with the action 'Activate'. Every word serves a purpose.

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 simple parameter and no output schema, the description is minimally adequate. However, it lacks context on what 'activate' does, preconditions, or return values, leaving gaps for an agent.

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 the parameter 'persona' described as 'The persona name or filename to activate'. The description adds little beyond the schema, so baseline 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?

The description 'Activate a specific persona by name or filename' clearly identifies the verb (activate) and resource (persona). It distinguishes from siblings like deactivate_persona and get_active_persona by specifying the action and input type.

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 activating a persona but does not provide explicit guidance on when to use this tool versus alternatives, such as when a persona is already active or how it differs from reload_personas.

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

deactivate_personaA

Deactivate the current persona

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.6/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 'Deactivate the current persona' but does not explain side effects, reversibility (though implied by sibling activate_persona), or what 'deactivate' entails (e.g., does it delete or just disable?).

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?

A single, front-loaded sentence with no redundancy. Every word is necessary and earns its place.

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 parameters, no output schema, and low complexity, the description is mostly adequate. It covers the core action, though more detail on behavioral effects would improve completeness.

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?

There are no parameters (schema coverage 100%), so baseline is 3. The description adds value by specifying 'current persona', which clarifies the scope of deactivation beyond the empty schema.

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 specifies the verb 'Deactivate' and the resource 'current persona', distinguishing it from siblings like activate_persona and get_active_persona. The purpose is unambiguous.

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 (e.g., when to deactivate vs. activate), no prerequisites, and no exclusions. It is a minimal statement without context.

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

get_active_personaB

Get information about the currently active persona

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.2/5.0
Behavior2/5

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

No annotations provided. Description does not disclose any behavioral aspects such as side effects, permissions, or state changes. For a read-only query, it is minimally descriptive.

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?

Single sentence, no unnecessary words. Perfectly front-loaded with core purpose.

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?

No output schema and no description of return value structure. Vague 'information'. However, for a simple query with no params, it is functional but could benefit from specifying what fields are returned.

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; schema coverage is 100% by default. Description adds meaning by specifying 'currently active persona', clarifying what is returned.

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?

Clear verb and resource: 'Get information about the currently active persona'. However, it does not differentiate from sibling 'get_persona_details', which could also return persona information.

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 on when to use this tool versus alternatives like 'get_persona_details'. Lacks context about prerequisites or typical use cases.

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

get_persona_detailsB

Get detailed information about a specific persona

ParametersJSON Schema
NameRequiredDescriptionDefault
personaYesThe persona name or filename to get details for

TDQS

B3.2/5.0
Behavior2/5

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

No annotations exist, so the description must disclose behavioral traits. It only states the purpose without mentioning if the tool is read-only, required permissions, error behavior, or response format.

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 sentence with no unnecessary words, efficiently conveying the tool's purpose.

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 tool returns 'detailed information' but lacks an output schema, the description should explain what 'details' includes (e.g., fields, structure). Without that, it is incomplete for an AI agent to understand the return value.

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% (the single parameter 'persona' is described in the schema). The description adds no additional meaning beyond the schema, so baseline score of 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?

The description 'Get detailed information about a specific persona' clearly states the tool's action (getting details) and resource (persona), distinguishing it from sibling tools like activate, deactivate, list, and reload.

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 such as list_personas or get_active_persona. The description lacks any context about prerequisites or appropriate usage scenarios.

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

list_personasB

List all available personas in GalaxyMCP

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.2/5.0
Behavior2/5

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

No annotations provided, so description must carry burden. It only states a listing operation, but does not disclose return format, pagination, or any side effects. Minimal behavioral info.

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?

Single sentence, no fluff. Efficient and front-loaded with the core action.

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 output schema and simple function, description is too brief. Lacks details on what 'available' means, what data is returned, and how it relates to sibling tools like get_persona_details.

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?

Input schema has no parameters with 100% coverage, so description need not add param info. No param details are required; baseline score of 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?

The description clearly states the tool lists all available personas, with a specific verb and resource. It distinguishes from siblings like activate_persona or get_persona_details.

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 on when to use this tool versus alternatives. No mention of typical use cases or scenarios where listing is appropriate.

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

reload_personasB

Reload all personas from the personas directory

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.4/5.0
Behavior2/5

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

No annotations provided. The description does not disclose side effects (e.g., does it replace current personas? Does it affect active persona?) or safety implications. It only states the action without behavioral context.

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?

Extremely concise single sentence. No wasted words. Front-loaded with action and resource.

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?

With no output schema, no annotations, and zero parameters, the description is insufficient. It lacks information about return values, side effects, or any pre/post conditions.

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, so schema coverage is complete. The description adds scope ('all personas') but no further param detail needed. Baseline 4 applies with zero parameters.

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 'Reload' and the resource 'all personas from the personas directory'. This distinguishes it from sibling tools that activate, deactivate, get, or list personas.

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 on when to use this tool versus alternatives or prerequisites. The description does not indicate that this is for refreshing from disk after changes.

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.

  1. 6 tool updatesv1.0.0
    • First observedactivate_persona
    • First observeddeactivate_persona
    • First observedget_active_persona
    • First observedget_persona_details
    • First observedlist_personas
    • First observedreload_personas
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored across 6 tools

Disambiguation5/5

Each tool has a distinct purpose: activate, deactivate, get active, get details, list, and reload personas. No overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., activate_persona, list_personas), ensuring predictability.

Tool Count5/5

With 6 tools focused on persona management, the set is well-scoped and neither too sparse nor excessive for the domain.

Completeness4/5

The tools cover core persona lifecycle operations (activate, deactivate, list, details) and include reload, but lack explicit create or delete functions, which may be handled externally.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Jira MCP Server

    ParasSolanki
    A
    license
    B
    quality
    C
    maintenance
    A Model Context Protocol server that provides integration with Jira, allowing Large Language Models to interact with Jira projects, boards, sprints, and issues through natural language.
    5
    16 npm
    3
    MIT

  • Jira MCP Server

    samuelrizzo
    A
    license
    A
    quality
    D
    maintenance
    A Model Context Protocol server that enables AI assistants like Claude to interact with Jira, allowing for project management tasks such as listing projects, searching issues, creating tickets, and managing sprints through natural language queries.
    7
    60 npm
    2
    TypeScript
    MIT

  • Jira MCP Server

    maximepeabody
    A
    license
    Not graded
    quality
    D
    maintenance
    A Simple Model Context Protocol server that enables AI assistants to interact with Jira, allowing operations like fetching tickets, adding comments, and updating ticket status.
    1
    Apache 2.0