Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@DevNarrate Review the changes you just made"
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.
MCP server for developer workflow automation — smart commits, secret scanning, PR descriptions, and more.
Change Review: Understand AI-generated code changes before committing — narrative summaries, goal alignment, and attention guides instead of raw diffs
Smart Commit Messages: Generate conventional commit messages from staged changes with full user control
Secret Scanning: Detect leaked API keys, tokens, passwords, and private keys in staged diffs before they reach your repo — powered by detect-secrets with 25+ built-in detectors
PR Descriptions: Create detailed pull request descriptions with customizable templates
Multi-Platform: Supports GitHub and GitLab
Token-Aware: Handles large diffs with automatic pagination
Template System: Use custom PR templates or built-in defaults
Safety First: Only works with staged changes to prevent accidental commits
Related MCP server: pr-mcp-server
curl -LsSf https://astral.sh/uv/install.sh | shgit clone https://github.com/krishnamandanapu/DevNarrate.git
cd DevNarrate
uv syncThe server must be launched with the Python interpreter from your uv-managed virtual environment (typically /path/to/DevNarrate/.venv/bin/python on macOS/Linux or .venv\\Scripts\\python.exe on Windows).
# capture the interpreter path once
VENV_PY=$(pwd)/.venv/bin/python
# Claude Code (global scope)
claude mcp add --scope user DevNarrate -- "$VENV_PY" -m devnarrate.server
# Claude Code (project scope)
claude mcp add DevNarrate -- "$VENV_PY" -m devnarrate.serverCursor (~/.cursor/mcp.json):
{
"mcpServers": {
"DevNarrate": {
"command": "/path/to/DevNarrate/.venv/bin/python",
"args": ["-m", "devnarrate.server"]
}
}
}For pip-based installation steps, head to https://pypi.org/project/devnarrate/.
DevNarrate only works with staged changes to keep you in control.
git add <file1> <file2>
# or stage everything tracked:
git add -uThen ask Claude:
Generate a commit message for my changesClaude inspects the staged diff, proposes a conventional commit message, and asks for approval before running git commit.
After an AI assistant makes changes to your code, ask it to review them before committing:
Review the changes you just madeDevNarrate analyzes the working tree diff and presents a layered summary:
Narrative overview — what changed, how many files, lines added/removed
Goal grouping — which changes map to the stated goal, which were inferred from comments/docstrings, and which are unrecognized (possibly from another session)
Attention guide — what needs human review vs what's routine
This replaces reading raw diffs with a structured, goal-oriented breakdown.
Secret scanning runs automatically as part of get_commit_context. When you stage changes and ask for a commit message, DevNarrate scans the diff for:
API keys (AWS, Google, Stripe, GitHub, Slack, etc.)
Passwords & tokens in config files
Private keys (RSA, SSH, PGP)
High-entropy strings that look like secrets
If secrets are found, Claude warns you before committing. To suppress false positives, add an inline comment:
SAFE_VALUE = "not-a-real-secret" # pragma: allowlist secretAsk Claude: "Create a PR to main from my current branch"
Claude analyzes the diff and offers template options (custom templates live in .devnarrate/pr-templates/)
Review the generated description and approve to let Claude create the PR via gh or glab
DevNarrate ships a fully commented config file at .devnarrate/config.toml. Copy it into your repo root and edit the values you care about — every setting documents its purpose and default inline.
All settings are optional — delete or comment out any line to use the default.
mkdir -p .devnarrate/pr-templatesExample (.devnarrate/pr-templates/feature.md):
## Summary
[What does this PR do?]
## Changes
-
-
## Testing
[How to test]
## Related Issues
[Links]If no template is found, DevNarrate falls back to its default format.
Commits: Works anywhere git runs
PRs: Requires platform CLIs
Format/lint through uv-managed tooling
Build artifacts with uv run pyproject-build
Use bump-my-version (see RELEASING.md) for tagged releases
MIT
Execute git commit with a user-approved commit message.
CRITICAL WORKFLOW - YOU MUST FOLLOW THESE STEPS IN ORDER:
Call get_commit_context to get the diff
Generate a commit message based on the actual diff
SHOW the generated commit message to the user in your response
ASK the user: "Should I proceed with this commit?" and WAIT for their response
ONLY call this tool AFTER the user explicitly approves (says "yes", "proceed", "commit it", etc.)
Set user_approved=True when calling this tool
DO NOT call this tool in the same response where you generate the commit message. The user MUST see the message and approve it first.
Args: message: User-approved commit message (should follow 50/72 rule) user_approved: REQUIRED - Must be True. Confirms user has seen and approved the commit message. repo_path: Path to git repository (optional, defaults to Claude's working directory)
Returns: Success message with commit hash or error
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | ||
| repo_path | No | ||
| user_approved | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 fully explains the requirement for user approval, the execution of the commit, and the expected return (success message with commit hash or error). It also warns not to call the tool prematurely, ensuring safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and well-structured: it starts with the purpose, then provides a critical numbered workflow, followed by parameter details and return value. It is slightly verbose due to explicit step-by-step instructions, but every sentence is meaningful and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is comprehensive for the tool's complexity: it covers the workflow, parameters, and return value. Although an output schema is not provided in the data (context says 'Has output schema: true' but no schema shown), the description concisely states 'Returns: Success message with commit hash or error,' which is sufficient for a straightforward commit operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema: it specifies that the message should follow the 50/72 rule, clarifies that user_approved must be True and represents user consent, and explains that repo_path is optional and defaults to Claude's working directory. This compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Execute git commit with a user-approved commit message,' specifying the action (commit), resource (git), and the key condition (user-approved). It is distinct from sibling tools like get_commit_context (diff retrieval) and create_pr (pull request creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a detailed, step-by-step workflow that must be followed exactly, including calling get_commit_context first, generating and showing a commit message to the user, obtaining approval, and only then invoking this tool with user_approved=True. It explicitly states 'DO NOT call this tool in the same response where you generate the commit message,' providing clear guidance on when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a pull request on the detected platform (GitHub/GitLab).
CRITICAL WORKFLOW - YOU MUST FOLLOW THESE STEPS IN ORDER:
Call get_pr_context to analyze the changes
Generate PR title and description based on the diff
SHOW the generated PR title and body to the user in your response
ASK the user: "Should I create this PR?" and WAIT for their response
ONLY call this tool AFTER the user explicitly approves (says "yes", "proceed", "create it", etc.)
Set user_approved=True when calling this tool
DO NOT call this tool in the same response where you generate the PR description. The user MUST see the content and approve it first.
Args: title: PR title (keep it concise, ~50 chars) body: PR description (formatted markdown) base_branch: Base branch (e.g., "main", "dev") user_approved: REQUIRED - Must be True. Confirms user has seen and approved the PR content. head_branch: Head branch (defaults to current branch) draft: Create as draft PR (default: False) repo_path: Path to git repository (optional, defaults to Claude's working directory)
Returns: Success message with PR URL or error message
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | ||
| draft | No | ||
| title | Yes | ||
| repo_path | No | ||
| base_branch | Yes | ||
| head_branch | No | ||
| user_approved | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It describes the behavior: creates a PR, requires user approval, and returns a success message with URL or error. It mentions defaults (head_branch defaults to current branch, draft default False). It does not detail side effects like CI triggers, but the essential behavior is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a critical workflow section and clear parameter explanations. It is somewhat long but every sentence is necessary for safe usage. Minor improvements could be made by condensing the workflow steps, but overall it's effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, 4 required) and no annotations, the description is remarkably complete. It explains the workflow, each parameter's role, and the return value. It also addresses prerequisite context (get_pr_context) and user approval, leaving no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the tool description adds significant meaning for each parameter: e.g., 'title: PR title (keep it concise, ~50 chars)', 'user_approved: REQUIRED - Must be True.' This goes well beyond the bare schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Create a pull request on the detected platform (GitHub/GitLab).' It uses a specific verb and resource, and distinguishes itself from siblings like commit_changes and review_changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a detailed step-by-step workflow, explicitly stating when to use the tool (only after user approval) and when not to (not in the same response as generating the description). It also names a prerequisite tool (get_pr_context) and includes critical warnings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
REQUIRED FIRST STEP: Get git diff and file changes to analyze before writing a commit message.
IMPORTANT: You MUST call this tool FIRST before generating any commit message. Never write a commit message without first seeing the actual git diff from this tool.
This tool ONLY shows STAGED changes. We intentionally do not support unstaged changes to ensure users have explicit control over what gets committed and prevent accidental commits.
CRITICAL: If the diff is empty and there are no files:
STOP immediately - do NOT proceed with generating a commit message
Tell the user: "No staged changes found. Please stage the files you want to commit first using: git add "
DO NOT attempt to stage files automatically
Wait for the user to stage their changes
Returns file changes and diff output with TOKEN-BASED pagination (MCP limit: 25k tokens). Large diffs are automatically paginated to stay under the token limit.
ANALYZING THE RESPONSE - follow these steps in order:
SECRET SCAN (automated): Check secret_scan.status FIRST.
If "warnings_found": STOP and warn the user about each finding. Show the file, line number, type, and redacted preview for each finding. Recommend removing the secret before committing. Do NOT proceed to generate a commit message until the user acknowledges or explicitly chooses to proceed despite the warnings.
If "clean": proceed to step 2.
SECRET SCAN (your review): Even if the automated scan is clean, briefly review the diff yourself for anything the regex-based scanner might miss:
Hardcoded credentials or secrets in unusual formats
Internal URLs, IP addresses, or hostnames that shouldn't be committed
Sensitive configuration values (database hosts, internal endpoints)
Comments containing passwords or access instructions If you spot anything suspicious, warn the user before proceeding.
COMMIT MESSAGE: After confirming no secrets (or user acknowledgment), generate a commit message following:
50/72 rule: 50 char subject line, 72 char body lines
Conventional commits format: type(scope): description
DO NOT include AI signatures, attribution, or "Generated with" footers
Args: cursor: Pagination cursor for large diffs (optional, returned as next_cursor) max_diff_tokens: Maximum tokens per response (default: 20000, safe under 25k limit) repo_path: Path to git repository (optional, defaults to Claude's working directory)
Returns: JSON string with: - has_changes: boolean - True if there are any staged changes to commit - files: list of changed files with status - secret_scan: results of secret detection on added lines - diff: the diff chunk (paginated) - next_cursor: pagination cursor for next chunk (if any) - pagination_info: token counts and chunk info - commit_format_guide: formatting rules for commit messages
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | ||
| repo_path | No | ||
| max_diff_tokens | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the burden of behavioral disclosure. It reveals that only staged changes are shown, explains pagination (token-based, 25k limit), details the return structure (has_changes, files, secret_scan, diff, etc.), provides a step-by-step analysis guide including secret scanning, and clarifies behavior for edge cases (empty diff).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is quite long and includes extensive step-by-step instructions that could be better placed elsewhere. While it front-loads the critical 'REQUIRED FIRST STEP' message, it could be more concise by separating behavior from workflow instructions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and a return structure described in the text, the description is complete: it covers all parameters, return fields, pagination, error handling (empty diff), security scanning, and even formatting rules for commit messages. No gaps remain for effective usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description's 'Args' section explains each parameter: cursor for pagination, max_diff_tokens for token limit, repo_path defaults to working directory. This adds meaningful context absent from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get git diff and file changes to analyze before writing a commit message,' specifying the verb (get), resource (git diff and file changes), and purpose (analyze before commit). It distinguishes itself from sibling tools like 'commit_changes' by positioning itself as the required first step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'REQUIRED FIRST STEP' and instructs the agent to never write a commit message without first seeing the diff. It also describes when to stop (empty diff) and what to tell the user. While it doesn't directly compare to alternatives, the strong directive provides clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get diff and commits between branches for PR description.
IMPORTANT: After calling this tool, you should:
Check if .devnarrate/pr-templates/ directory exists (use ls or Bash)
If templates exist, list them and ask user which template to use
Read the chosen template file (use Read tool)
If no templates exist, use git_operations.DEFAULT_PR_TEMPLATE
Analyze the diff and commits to fill the template
Args: base_branch: Base branch to compare against (e.g., "main", "dev") head_branch: Head branch (defaults to current branch) cursor: Pagination cursor for large diffs (optional, returned as next_cursor) max_diff_tokens: Maximum tokens per diff chunk (default: 12000, leaves room for commits/files in 25k limit) repo_path: Path to git repository (optional, defaults to Claude's working directory)
Returns: JSON string with commits, files, diff chunk, and pagination info
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | ||
| repo_path | No | ||
| base_branch | Yes | ||
| head_branch | No | ||
| max_diff_tokens | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full responsibility. It reveals that the tool returns a JSON string with commits, files, diff chunk, and pagination info, and explains the max_diff_tokens parameter. However, it does not state whether the tool is read-only or discuss side effects, authentication, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, but the IMPORTANT section includes workflow instructions that go beyond tool behavior, adding length. While useful, it could be more concise. The parameter descriptions are clear and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (branches, diffs, pagination, token limits) and that an output schema exists, the description covers the main aspects: branch specification, pagination via cursor, token limit rationale, and return type. Missing details on error handling or prerequisites but adequate for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining all five parameters: base_branch, head_branch, cursor, max_diff_tokens, repo_path. It provides defaults, purpose (e.g., pagination cursor, token limit), and context (e.g., 'leaves room for commits/files in 25k limit').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Get diff and commits between branches for PR description,' clearly identifying the tool's action and target. It distinguishes from siblings like get_commit_context and review_changes, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The IMPORTANT section provides a step-by-step workflow for using the tool's output, guiding the agent on when to call it (for PR description generation) and how to proceed. It lacks explicit exclusions but offers clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Review code changes before staging/committing to understand what was done and why.
WHEN TO CALL: After you (the AI assistant) have made code changes on behalf of the user and BEFORE staging or committing. This lets the user understand what you did at a conceptual level rather than reading raw diffs.
REQUIRED: Before calling this tool, summarize what the user asked you to do. Pass this as the 'goal' parameter. Be specific — "add JWT authentication middleware" is better than "make changes".
HOW TO PRESENT THE RESPONSE — follow this layered approach:
NARRATIVE SUMMARY (always show first): Start with a plain-language summary of what changed. Example: "I made 5 changes across 3 files to add JWT authentication." Include the key stats: files added/modified/deleted, lines changed.
GOAL ALIGNMENT (group changes by purpose): Look at each changed file and classify it into one of three tiers:
KNOWN: Changes that directly relate to the 'goal' you passed. You know these because you made them for the stated purpose.
INFERRED: Changes whose context_clues (comments, docstrings) suggest a clear purpose different from the stated goal. These may be from a different AI agent session. Describe the inferred purpose.
UNKNOWN: Changes with no clear connection to any goal AND no useful context clues. Flag these — the user should review them.
PER-FILE BREAKDOWN: For each goal group, list the files with a short description of what changed. Read the diff to explain HOW the goal was achieved:
What functions/classes were added or modified?
What's the approach? (e.g., "Added middleware pattern using decorators")
Any notable implementation choices?
ATTENTION GUIDE: Tell the user what needs their eyes vs what's routine:
NEW FILES: "I created auth/middleware.py — worth a quick review"
MODIFIED FILES: "Added 3 lines to config.py — routine import addition"
UNKNOWN CHANGES: "utils.py was modified but doesn't match the goal — please check"
LARGE CHANGES: Any file with 50+ lines added deserves a mention
DETAIL ON DEMAND: End with: "Want me to walk through any specific file in detail?"
IMPORTANT: You have the full diff in the response — READ IT to understand the actual code in any programming language. The context_clues are supplementary hints (comments/docstrings) to help you classify changes from other sessions that you didn't make yourself.
Args: goal: What the user asked the AI to do. Summarize from your conversation. Be specific — this is used to classify changes into goal groups. scope: What to analyze: - "working" (default): All unstaged working tree changes (git diff) plus untracked files. Use this before staging. - "staged": Only staged changes (git diff --staged). Use this if the user has already staged specific files. repo_path: Path to git repository (optional, defaults to MCP roots).
Returns: JSON string with: - goal: The stated goal (pass-through for your reference) - summary: File and line count statistics - changes: Per-file stats (path, status, lines_added, lines_removed) - context_clues: Comments and docstrings from added lines (per file) - diff: Raw diff text for you to read and understand the code - untracked_files: List of new files not yet tracked by git (working scope only) - pagination_info: Token counts and chunk info for the diff
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | ||
| scope | No | working | |
| repo_path | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses behavior: returns JSON with summary, changes, diff, context clues, etc. Explains how to interpret and present results. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very detailed and well-structured with clear sections, but quite lengthy. Every section adds value, but could be more concise while retaining essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all aspects: purpose, when to call, prerequisites, parameters, output schema (explained even though output schema exists), and how to present results. Complete for a tool with 3 parameters and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description includes an 'Args:' section that explains each parameter (goal, scope, repo_path) with defaults and usage guidance, adding significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool reviews code changes before staging/committing. Provides specific verb 'review' and resource 'code changes', and distinguishes from sibling tools like commit_changes and create_pr.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states WHEN TO CALL: after making changes and before staging/committing. Gives required prerequisite to provide a 'goal' summary. Provides detailed instructions on how to present the response.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0commit_changescreate_prget_commit_contextget_pr_contextreview_changesEach tool has a clearly distinct purpose: commit changes, create PR, get commit context, get PR context, and review changes. No overlaps in functionality.
All tool names follow the verb_noun snake_case pattern consistently, e.g., commit_changes, get_commit_context, create_pr.
With 5 tools, the server is well-scoped for assisting with git workflows without being overwhelming or insufficient.
Covers core workflow: commit, PR, context retrieval, and review. Missing staging or branch management, but these are minor gaps for the intended domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A MCP server built for developers enabling Git based project management with project and personal…
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
AI-native git hosting — repos, PRs, issues, CI gates, and AI code review over MCP (60 tools).
MCP server for Appcircle mobile CI/CD platform.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/kmandana/DevNarrate'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
