How do I use engmanager-mcp?

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., "@engmanager-mcp What's the next step in my workflow?" 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.

engmanager-mcp

by scarr7981

Overview Schema Related Servers Score Discussions

Python

Local

Engineering Manager MCP

Python 3.11+ MCP PyPI uvx

An MCP (Model Context Protocol) server that provides LLMs with structured workflow guidance and "next step" instructions for development procedures. Perfect for maintaining consistent development practices across projects without having to repeatedly explain procedures to AI assistants.

This project welcomes contributions from AI/LLM agents! Pull requests from Claude, GPT, and other AI models are actively encouraged.

Guidelines for AI contributors:

Follow existing code patterns and documentation standards
Include comprehensive commit messages explaining changes
Test changes thoroughly before submitting PRs
Update documentation when adding new features

🎯 Purpose

Engineering Manager MCP solves a common problem: LLMs forget your development procedures. Instead of repeatedly reminding your AI assistant about branch naming conventions, commit message formats, PR templates, or deployment steps, let Engineering Manager MCP provide that guidance on demand.

Use Cases:

🔄 Consistent Workflows - Maintain standardized development procedures across projects
📋 Step-by-Step Guidance - LLMs can query "what's next?" at any point in the workflow
🎯 Context-Aware Suggestions - Returns relevant workflow sections based on current task
🔧 Multi-Project Support - Different procedures for different projects
📝 Template Variables - Customize procedures with project-specific values

Related MCP server: Vibe-Coder MCP Server

✨ Quick Start

Installation from PyPI

# Run directly with uvx (recommended)
uvx engmanager-mcp

# Or install with pip
pip install engmanager-mcp

Configure in Claude Code

For project-specific configuration, add to your local .mcp.json in the project directory, or add to your global claude_code_config.json:

{
  "mcpServers": {
    "engmanager": {
      "command": "uvx",
      "args": ["engmanager-mcp"],
      "env": {
        "ENGMANAGER_DEFAULT_PROJECT": "myproject"
      }
    }
  }
}

Create Your First Project

Create a project configuration:

mkdir -p ~/.config/engmanager-mcp
cat > ~/.config/engmanager-mcp/myproject-config.json <<EOF
{
  "project_name": "myproject",
  "procedure_file": "myproject-workflow.md",
  "variables": {
    "REPO_OWNER": "yourname",
    "REPO_NAME": "myproject",
    "DEFAULT_BRANCH": "main"
  }
}
EOF

Create a workflow procedure:

cat > ~/.config/engmanager-mcp/myproject-workflow.md <<EOF
# My Project Workflow

## 1. Branch Creation

Create a feature branch:
\`\`\`bash
git checkout -b feature/my-feature
\`\`\`

## 2. Development

Make your changes and commit:
\`\`\`bash
git add .
git commit -m "feat: description"
\`\`\`

## 3. Push & PR

Push and create a pull request:
\`\`\`bash
git push -u origin feature/my-feature
gh pr create --title "feat: Description"
\`\`\`
EOF

Use in Claude:

You: "What's the first step in the workflow?"
Claude: [calls get_next_step tool]
Engineering Manager MCP: Returns "Step 1: Branch Creation..."

You: "What's next?"
Claude: [calls get_next_step with current_step=1]
Engineering Manager MCP: Returns "Step 2: Development..."

🔧 Available Tools

`get_next_step`

Get the next step in the workflow.

get_next_step(project="myproject", current_step=1)

Parameters:

project (optional): Project name (uses default if not specified)
current_step (optional): Current step number (defaults to 0 for first step)

`get_workflow_section`

Get a specific section from the workflow by name.

get_workflow_section(section="Error Recovery Protocols", project="myproject")

`list_workflow_steps`

Get an overview of all numbered steps.

list_workflow_steps(project="myproject")

`list_available_projects`

List all configured projects.

list_available_projects()

`get_project_info`

Get detailed information about a project's configuration.

get_project_info(project="myproject")

📚 Available Resources

`engmanager://procedures/{project}`

Get the full procedure file with variables substituted.

`engmanager://config/{project}`

Get the project configuration.

`engmanager://templates`

Get documentation about template variables.

`engmanager://projects`

List all available projects with status.

🎨 Template Variables

Procedures support template variables for customization:

## Branch Creation for {PROJECT_NAME}

Create a branch:
\`\`\`bash
git checkout -b feature/my-feature
git push -u origin feature/my-feature
\`\`\`

Your repository: {REPO_OWNER}/{REPO_NAME}
Default branch: {DEFAULT_BRANCH}

Common Variables:

{PROJECT_NAME} - Project name
{REPO_OWNER} - GitHub repository owner
{REPO_NAME} - GitHub repository name
{DEFAULT_BRANCH} - Default branch (main/master)
{ISSUE_NUMBER} - Current issue number
{BRANCH_PREFIX} - Branch prefix (feature/fix/refactor)

Define custom variables in your project's config file.

📁 Project Structure

Important: The procedures/ directory is excluded from the PyPI package. When you install via uvx engmanager-mcp, you need to create your own workflow files in one of these locations:

~/.config/engmanager-mcp/          # Recommended for user-specific workflows
├── myproject-config.json          # Project configuration
├── myproject-workflow.md          # Workflow procedure
├── another-project-config.json
└── another-project-workflow.md

Configuration file locations (searched in order):

./procedures/ (relative to current directory - for local development)
~/.config/engmanager-mcp/ (user config - recommended)
/etc/engmanager-mcp/ (system-wide)

Note: Example files (example-config.json, example-workflow.md) are only available in the GitHub repository for reference, not in the PyPI package.

⚙️ Configuration

Environment Variables

ENGMANAGER_DEFAULT_PROJECT - Default project name
ENGMANAGER_MCP_LOG_LEVEL - Logging level (DEBUG, INFO, WARNING, ERROR)
ENGMANAGER_PROCEDURES_DIR - Custom procedures directory
ENGMANAGER_MCP_TRANSPORT - Transport mode (stdio or http)

Project Configuration Format

{
  "project_name": "myproject",
  "procedure_file": "myproject-workflow.md",
  "variables": {
    "REPO_OWNER": "username",
    "REPO_NAME": "repository",
    "DEFAULT_BRANCH": "main",
    "CUSTOM_VAR": "custom_value"
  }
}

Required Fields:

project_name - Unique project identifier
procedure_file - Filename of the markdown procedure

Optional Fields:

variables - Dictionary of template variables

📖 Example Use Cases

Use Case 1: Consistent Git Workflow

Problem: Different team members follow different git workflows.

Solution: Create a standardized procedure that LLMs can reference:

## 1. Branch Creation
- Always create from main
- Use conventional naming: feature/fix/refactor
- Format: <type>/<description>-issue-<number>

## 2. Commit Messages
- Use conventional commits format
- Include issue reference
- Add "Resolves #N" for auto-close

LLMs can now query these steps and follow them consistently.

Use Case 2: Multi-Project Development

Problem: Working on multiple projects with different procedures.

Solution: Configure multiple projects:

~/.config/engmanager-mcp/
├── frontend-config.json
├── frontend-workflow.md
├── backend-config.json
└── backend-workflow.md

LLMs can switch between project contexts easily.

Use Case 3: Onboarding Documentation

Problem: New team members (including AI assistants) need workflow guidance.

Solution: Comprehensive procedure files serve as executable documentation:

## Developer Setup
1. Clone repository
2. Install dependencies
3. Configure environment
4. Run development server

## Development Workflow
[Steps...]

## Deployment Process
[Steps...]

## Error Recovery
[Procedures...]

🔨 Development Setup

Local Installation

# Clone repository
git clone https://github.com/scarr7981/engmanager-mcp.git
cd engmanager-mcp

# Create virtual environment
python3 -m venv .venv
source .venv/bin/activate  # Linux/Mac
# or
.venv\Scripts\activate     # Windows

# Install dependencies
pip install -r requirements.txt

# Install in editable mode for development
pip install -e .

# Run locally
python -m engmanager_mcp.server
# or
engmanager-mcp

Development Mode with Claude Code

For local development and testing with Claude Code, add this to your project's .mcp.json file:

{
  "mcpServers": {
    "engmanager": {
      "command": "/absolute/path/to/engmanager-mcp/.venv/bin/python",
      "args": ["-m", "engmanager_mcp.server"],
      "cwd": "/absolute/path/to/engmanager-mcp",
      "env": {
        "ENGMANAGER_DEFAULT_PROJECT": "example",
        "ENGMANAGER_MCP_LOG_LEVEL": "DEBUG"
      }
    }
  }
}

Important:

Replace /absolute/path/to/engmanager-mcp with the actual path to your cloned repository
For Windows WSL, use: /mnt/c/Users/username/path/to/engmanager-mcp/.venv/bin/python
For Windows native, use: C:\\absolute\\path\\to\\engmanager-mcp\\.venv\\Scripts\\python.exe
The .mcp.json file should be in the project root directory
This file is gitignored, so your local config won't be committed

This configuration:

Uses the virtual environment's Python interpreter directly
Runs from your local development directory
Enables DEBUG logging for troubleshooting
Sets the example project as default
Allows you to edit code and see changes immediately (restart Claude Code to reload)

Testing

Create a test project:

mkdir -p procedures
cat > procedures/test-config.json <<EOF
{
  "project_name": "test",
  "procedure_file": "example-workflow.md",
  "variables": {
    "REPO_OWNER": "testuser",
    "REPO_NAME": "testrepo",
    "DEFAULT_BRANCH": "main"
  }
}
EOF

# Copy example workflow
cp procedures/example-workflow.md procedures/test-workflow.md

# Test with MCP inspector or Claude Code

📦 Publishing to PyPI

Build Package

# Install build tools
pip install build twine

# Build package
python -m build

# Check distribution
twine check dist/*

Upload to PyPI

# Upload to Test PyPI first
twine upload --repository testpypi dist/*

# Test installation
pip install --index-url https://test.pypi.org/simple/ engmanager-mcp

# Upload to PyPI
twine upload dist/*

Using GitHub Actions

This project can be configured with GitHub Actions for automatic PyPI publishing on tagged releases. See cargoshipper-mcp for reference.

🤝 Contributing

This project is inspired by the EXAMPLE_PROCEDURE.md workflow for Trowel.io and follows similar patterns.

Contribution Guidelines:

Follow existing code patterns
Add comprehensive docstrings
Update README for new features
Test with real procedures
Include example configurations

📄 License

MIT License - See LICENSE file for details

CargoShipper MCP - Infrastructure automation MCP server
Model Context Protocol - Official MCP documentation
FastMCP - Python MCP framework

💡 Tips & Best Practices

Writing Effective Procedures

Use numbered steps for sequential workflows
Include code examples in bash blocks
Document error recovery procedures
Add quality gates at key checkpoints
Use template variables for project-specific values

Organizing Projects

One config per project - Keep projects isolated
Shared procedures - Reference common workflows
Default project - Set for most common use case
Version control - Keep procedures in git

LLM Integration

Ask "what's next?" - Simple queries work best
Provide context - Mention current step if known
Query sections - Jump to specific workflow parts
List steps - Get overview before starting

🐛 Troubleshooting

"Project not found"

Check config file location
Verify filename format: <project>-config.json
Check ENGMANAGER_DEFAULT_PROJECT environment variable

"Procedure file not found"

Verify procedure_file path in config
Check procedures directory
Ensure markdown file exists

"Missing template variables"

Check procedure file for {VARIABLE} syntax
Add missing variables to config variables object
Variables must be UPPERCASE with underscores

"No projects configured"

Add at least one <project>-config.json file
Check config search paths
Verify JSON syntax in config files

📞 Support

Issues: GitHub Issues
Documentation: GitHub README
MCP Help: Model Context Protocol Docs

Made with ❤️ for better AI-assisted development workflows

Available Tools

5 tools

get_next_stepA

Get the next step in the workflow

Retrieves the next step in the development workflow for the specified project. If current_step is provided, returns the step immediately following it. If current_step is not provided, returns step 1 (start of workflow).

Args: project: Project name (uses default if not specified) current_step: Current step number (optional, defaults to 0 to get step 1)

Returns: Formatted next step instructions

Examples: get_next_step(project="trowel") get_next_step(project="trowel", current_step=3)

ParametersJSON Schema

Name	Required	Description	Default
`project`	No
`current_step`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It discloses basic behavior (returns formatted next step instructions, defaults to step 1) but does not mention error handling, side effects (likely read-only), or authorization requirements. More context on edge cases would improve transparency.

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 well-structured with a brief intro, bullet-style args, returns, and examples. It is front-loaded and each section adds value, though could be slightly more concise.

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 low complexity (2 params) and presence of output schema, the description covers purpose, parameter details, and behavior. It provides sufficient context for an agent to use the tool correctly.

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 0%, so the description must compensate. It explains both parameters: 'project' with default behavior and 'current_step' with default of 0. This adds useful meaning beyond the schema's type and title.

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 'Get the next step in the workflow' and elaborates on retrieving the next step for a project with an optional current_step parameter. It distinguishes from siblings like 'list_workflow_steps' by focusing on a single next step rather than listing all steps.

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 clear context on when to use the tool (to get the next step) and includes examples. It explains behavior for both providing and omitting current_step. However, it does not explicitly mention when not to use this tool or suggest alternatives.

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

get_project_infoA

Get information about a specific project

Shows configuration and available procedures for a project.

Args: project: Project name

Returns: Project information including variables and procedure file

Examples: get_project_info(project="trowel")

ParametersJSON Schema

Name	Required	Description	Default
`project`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations, the description carries the burden. It clearly indicates a read operation returning configuration and procedures. It does not mention side effects, authentication, or performance, but for a simple query tool this is adequate.

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?

Very concise: a header, a sentence, args/returns sections, and an example. All information is front-loaded and no wasted words.

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 output schema exists, the description adequately covers the tool's purpose and return shape. Could mention it is read-only, but not necessary. Completeness is high for a simple query.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It only says 'project: Project name' and gives an example, adding minimal meaning. No constraints or format details beyond 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 states it gets information about a specific project and shows configuration and available procedures. This distinguishes it from sibling 'list_available_projects' which lists projects.

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 use for a specific project but lacks explicit guidance on when to use vs. alternatives like 'list_available_projects' or 'get_next_step'. No exclusions or prerequisites mentioned.

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

get_workflow_sectionA

Get a specific section from the workflow

Retrieves a named section from the project's workflow procedure. Useful for jumping to specific parts of the workflow or getting reference information.

Args: section: Section title to retrieve project: Project name (uses default if not specified)

Returns: Section content

Examples: get_workflow_section(section="Error Recovery Protocols", project="trowel") get_workflow_section(section="Quality Gates")

ParametersJSON Schema

Name	Required	Description	Default
`section`	Yes
`project`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description must disclose behavioral traits. It indicates a read operation (retrieves section content) but does not mention side effects, error handling, or authentication needs.

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, with a clear lead sentence followed by parameter docs, return description, and example. Each sentence adds value without 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?

The description covers purpose, parameters, return value, and example. With an output schema present, return details are sufficient. It lacks handling of missing sections but is complete for a simple retrieval tool.

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 0%, so the description fully defines parameters: 'section' as title to retrieve and 'project' as optional with default. It also provides an example, adding value beyond the 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 states the tool retrieves a specific section from the workflow, using the verb 'get' and resource 'section'. It distinguishes from siblings like 'get_next_step' by specifying it retrieves a named section.

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 mentions it's useful for jumping to parts of the workflow or getting reference info, which implies usage context. However, it does not explicitly contrast with alternatives or state when not to use it.

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

list_available_projectsA

List all configured projects

Shows all projects that have configuration files available.

Returns: List of available project names

Examples: list_available_projects()

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

No annotations are provided, so the description must disclose behavioral traits. It states that projects with configuration files are shown, implying a read-only operation, but does not mention side effects, authentication requirements, or error handling (e.g., empty list). The description is acceptable for a simple listing tool but could be more transparent.

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 very concise: three sentences for purpose, returns, and an example. It is front-loaded with the action and resource, and every sentence adds necessary information without redundancy.

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?

Given the tool has no parameters and a simple output (list of project names), the description is complete. It explains what it returns and gives a usage example, which suffices for AI invocation.

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?

With zero parameters, schema coverage is 100%, so the description adds value by specifying the return value ('List of available project names') and providing an example. This exceeds the baseline of 3 for high schema coverage.

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 'List all configured projects' and 'Shows all projects that have configuration files available,' which specifies the verb (list) and resource (configured projects). Among sibling tools that handle workflow steps or specific project details, this tool is distinct and its 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 Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description only states what the tool does—list projects—without any guidance on when to use it versus alternatives like get_project_info or list_workflow_steps. No when-not or scoping constraints are mentioned, though the context of listing all projects is implied.

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

list_workflow_stepsA

List all steps in the workflow

Provides an overview of all numbered steps in the project's workflow.

Args: project: Project name (uses default if not specified)

Returns: List of all workflow steps

Examples: list_workflow_steps(project="trowel") list_workflow_steps()

ParametersJSON Schema

Name	Required	Description	Default
`project`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. States it lists steps and returns a list, but does not disclose read-only nature or other behavioral traits. Since it's a simple list operation, the lack of extra detail is acceptable but not exemplary.

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?

Description is front-loaded with the main purpose, includes structured Args/Returns/Examples sections, and every sentence adds value. No waste.

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?

Tool has one optional parameter and an output schema (not shown but indicated). The description explains the parameter and return type adequately given the presence of output schema. Complete for this simple tool.

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 0%, meaning description adds value. The description explains 'project: Project name (uses default if not specified)' which clarifies the parameter's purpose and default behavior beyond the schema's type and default values.

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?

Clearly states 'List all steps in the workflow' and 'Provides an overview of all numbered steps in the project's workflow.' Distinct from siblings like get_next_step (singular step) and get_workflow_section (section focus).

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 parameter details and examples, showing usage with and without project argument. Does not explicitly contrast with sibling tools but the purpose is clear enough that an agent can infer when to use it based on need.

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.2Jun 4, 2026
- First observedget_next_step
- First observedget_project_info
- First observedget_workflow_section
- First observedlist_available_projects
- First observedlist_workflow_steps

Install Server

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

TDQS

A4.3/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: listing projects, getting project info, listing workflow steps, getting the next step, and retrieving a specific workflow section. No overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case: 'get_next_step', 'get_project_info', 'get_workflow_section', 'list_available_projects', 'list_workflow_steps'. The verbs 'get' and 'list' are appropriately used for their respective retrieval operations.

Tool Count5/5

Five tools is well-scoped for a workflow manager. Each tool addresses a necessary aspect of navigating and inspecting project workflows without excess or deficiency.

Completeness5/5

The tool set covers all essential read operations for the domain: discovering projects, viewing info, listing steps, getting the next step, and accessing specific sections. It is complete for its intended purpose of guiding users through predefined workflows.

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

CoderbudsOAuth
com.coderbuds
Your team's shipping standards, org map and delivery metrics, inside your coding agent.
1
StoriesOnBoard - structured specifications for AI AgentsOAuth
com.storiesonboard
Turn PRDs and product ideas into structured specs so coding agents build your intent, not theirs.
Product Management Coding Agents
2
Roamer MCPOAuth
com.mathismeadows
Project registry, behavioral specs, and engineering threads for AI coding agent workflows.
Agent Orchestration Developer Tools Project Management
1
AI Worlds CLI Knowledge A
com.claude-world
Source-checked CLI guides and model-aware planning for Claude Code, Codex, and Grok Build.
Command Line Developer Tools Documentation Access
121

Related MCP Servers

AI Development Guidelines MCP
Developer Tools Documentation Access Code Analysis
anip1805-dotcom
F
license
Not graded
quality
D
maintenance
Provides AI agents with professional coding standards, development best practices, and context-aware guidance through static documentation and AI-powered custom recommendations. Enables agents to access comprehensive development guidelines including coding rules, debugging techniques, and AI steering instructions.
Updated 10 months ago (2025-10-27 18:05 UTC)
-
Vibe-Coder MCP Server
Developer Tools Project Management Autonomous Agents
MCP-Mirror
F
license
Not graded
quality
Not graded
maintenance
Implements a structured development workflow for LLM-based coding with feature clarification, PRD generation, phased development, and task tracking. Guides LLMs through organized feature development from requirements gathering to completion with document storage and progress monitoring.
Updated a year ago (2025-06-25 18:10 UTC)
67
-
Accordo
Developer Tools Coding Agents Autonomous Agents
AndurilCode
A
license
Not graded
quality
D
maintenance
A YAML-driven workflow guidance MCP server that enables AI coding agents to follow structured development workflows with real-time state tracking and progression control.
Updated 10 months ago (2025-10-27 20:12 UTC)
5
MIT
Workflow MCP Server
App Automation Autonomous Agents
tuanknguyen
A
license
B
quality
D
maintenance
Guides agents through structured workflows with predefined steps, allowing for flexible execution via instructions and tool calls.
Updated a year ago (2025-04-08 04:30 UTC)
8
1
MIT

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/scarr7981/engmanager-mcp'

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

Engineering Manager MCP

🎯 Purpose

✨ Quick Start

Installation from PyPI

Configure in Claude Code

Create Your First Project

🔧 Available Tools

get_next_step

get_workflow_section

list_workflow_steps

list_available_projects

get_project_info

📚 Available Resources

engmanager://procedures/{project}

engmanager://config/{project}

engmanager://templates

engmanager://projects

🎨 Template Variables

📁 Project Structure

⚙️ Configuration

Environment Variables

Project Configuration Format

📖 Example Use Cases

Use Case 1: Consistent Git Workflow

Use Case 2: Multi-Project Development

Use Case 3: Onboarding Documentation

🔨 Development Setup

Local Installation

Development Mode with Claude Code

Testing

📦 Publishing to PyPI

Build Package

Upload to PyPI

Using GitHub Actions

🤝 Contributing

📄 License

🔗 Related Projects

💡 Tips & Best Practices

Writing Effective Procedures

Organizing Projects

LLM Integration

🐛 Troubleshooting

"Project not found"

"Procedure file not found"

"Missing template variables"

"No projects configured"

📞 Support

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`get_next_step`

`get_workflow_section`

`list_workflow_steps`

`list_available_projects`

`get_project_info`

`engmanager://procedures/{project}`

`engmanager://config/{project}`

`engmanager://templates`

`engmanager://projects`