Which integrations are available for this server?

Provides Flutter-focused setup and delivery support, including profile selection (imespro, external-structured, external-standard), setup/doctor checks, company foundation package cloning, and Flutter-specific agent skills and validators. Adds a Frappe UI stack pack with clean architecture rules and Frappe UI catalog guidance, syncing Frappe-specific skills and rules into supported workspaces.

How do I use Python MCP Hub?

1. Click on "Deploy 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., "@Python MCP Hub validate my Flutter architecture design for the imespro profile" 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.

Python MCP Hub

by pzakhim

Overview Schema Source Related Servers Discussions Admin

Python

Local

Coder Nexus

Agent roles, skills and MCP tools that help an AI coding agent deliver software the way a team does: requirements → design → plan → code → review → verification.

Coder Nexus has three parts:

VS Code / Antigravity extension: copies agent roles, skills and rules into your project and gives you one-click commands to manage them.
coder-nexus CLI (Python Hub): the MCP server your agent talks to, plus terminal commands for Huly task intake, two-layer Figma extraction (tokens.json + <node>.spec.json + per-screen .png/.jpg), and environment checks.
skill-factory CLI (new in 3.0): generators that write skills tailored to your workspace (architecture, clean code, tests, review, security, QA…). Installed together with coder-nexus.

Installing it does not start anything on its own. Your host agent (for example Antigravity) reads the installed roles and skills and uses them when you ask it to work.

How it works

Coder Nexus organizes 7 specialized agent roles into 2 departments (dev-team, bug-squad) plus 2 read-only companion workflows (debug-investigation, feature-testing):

Your request / task ticket
         │
         ├──► dev-team (Feature Delivery)         ──► Spec Writer (Huly + Figma Intake: S-NN, W-NN) ──► [Gate 1 Approval]
         │                                                                                                     │ (Zero-Re-Ask Handoff)
         │                                                                                                     ▼
         │                                                                             Planning [Gate 2 & 3] ──► Code Writer ──► Code Reviewer ──► Test Runner ──► Docs Writer (once after ACCEPTED)
         │
         └──► bug-squad (4-Gate Bug Resolution)   ──► Bug Fixer (Reproduce ──► Root Cause & Impact ──► [S1-S4 & L1/L2/L3 Confirmation])
                                                             ├── L1: Bug Fixer ──► Test Runner
                                                             ├── L2: Bug Fixer ──► Code Reviewer ──► Test Runner
                                                             └── L3: Escalation Report ──► dev-team (Zero-Re-Ask Handoff)

Concept	What it means
2 Departments & 7 Roles	`dev-team` (`Spec Writer`, `Planning`, `Code Writer`, `Code Reviewer`, `Test Runner`, `Docs Writer`) and `bug-squad` (`Bug Fixer`, `Code Reviewer` L2, `Test Runner`).
Approval gates	You approve requirements, screens (`S-NN`) & workflows (`W-NN`) (`Gate 1`), technical design & UI Kit mapping (`Gate 2`), and the implementation plan (`Gate 3`) — or the bug triage level (`S1–S4`, `L1/L2/L3`) — before production code is written. Agents never approve for you.
Zero-Re-Ask Handoffs	When `Spec Writer` completes Gate 1, `Planning` starts directly at `Gate 2` without re-asking business requirements. Likewise, `debug-investigation` and `feature-testing` hand off directly to `bug-squad`, and L3 bugs hand off to `dev-team`.
Skills & Always-On rules	Constitutional guardrails in `.agents/rules/` stay active on every turn; step-by-step skills in `.agents/plugins/coder-nexus/skills/` load on demand for discovery, design, coding, review, debugging, and evidence.
Stack packs & profiles	Rules and skills for a specific stack (Flutter, Backend). Profile-specific guidance (`external-standard`, `external-structured`, `imespro`) is injected automatically into the installed skills.
Workspace skills	Skills generated by the Skill Factory into `.agents/skills/`. They belong to your project and take priority over pack skills on the same topic.
MCP tools	Task intake, architecture guidance, UX patterns, and validators the agent can call.
Work & debug items	Feature artifacts live under `.superpowers/work-items/<slug>/vN/`, bug/investigation artifacts under `.superpowers/debug/<slug>/`, and scenario runs under `.superpowers/test-runs/<slug>/`.

Related MCP server: devops-mcp-server

Install

1. Install the extension

In VS Code / Antigravity open Extensions (Cmd+Shift+X / Ctrl+Shift+X), search Coder Nexus and click Install. Or download a .vsix from Releases and use Extensions → … → Install from VSIX....

2. Install the CLI

Click Coder Nexus in the status bar → Install / Update CLI. It installs uv if needed, then the CLI matching the extension version.

Manual install:

curl -LsSf https://astral.sh/uv/install.sh | sh

uv tool install --force git+https://github.com/pzakhim/coder-nexus.git@vX.Y.Z

coder-nexus --help

On Windows, install uv with powershell -c "irm https://astral.sh/uv/install.ps1 | iex". Replace X.Y.Z with your extension version. Run Install / Update CLI again after each extension update.

3. Add agents to your project

Open your project. If the extension detects a supported stack it offers Sync Now. Otherwise open the Command Palette (Cmd+Shift+P / Ctrl+Shift+P) and run Coder Nexus: Sync Stack to Workspace (Auto-Detect), then pick your stack.

The sync writes:

Path	Content
`.agents/agents/`	The 7 agent roles, combined with the rules of the selected pack
`.agents/rules/`	Always-On constitutional guardrails for the installed pack (`clean_architecture_rules.md` or `backend_clean_architecture_rules.md`)
`.agents/plugins/coder-nexus/`	Shared skills, stack skills (with active profile references injected), and `mcp_config.json`; `GUIDELINE.md` there is a user guide for the stack (Flutter)
`.agents/stack.json`	Which pack owns which folders (edit it if detection guessed wrong)

Re-run the sync after installing or updating the CLI so the MCP config points to it.

4. Check your setup

coder-nexus doctor

Using it

Once synced, talk to your agent in natural language or name a workflow directly:

Workflow / Skill	When to use	Example prompt
`dev-team`	End-to-end feature delivery: Huly + Figma intake (`S-NN`, `W-NN`) at `Gate 1`, UI Kit & Clean Architecture design (`## UI/UX mapping`) at `Gate 2`, implementation plan at `Gate 3`, phase-by-phase coding/review, final QA (`Test Runner`), and a single visual `as-built.md` (`Docs Writer`).	"Implement task ABC-12" or "Build the order screen from this Figma link"
`bug-squad`	Reproduce a bug, prove root cause & blast-radius impact, confirm severity (`S1–S4`) + fix level (`L1/L2/L3`), then fix and verify	"Fix bug: the order list crashes when empty" or "Sửa lỗi task ABC-45"
`debug-investigation`	Read-only investigation or runtime flow tracing with temporary `[DBG-<slug>]` logs (automatically cleaned up) into `diagnosis.md`	"Debug: why does the order list show yesterday's data?" or "Trace luồng từ màn B sang C"
`feature-testing`	Read-only scenario testing by `Test Runner` on the real app/browser/API into `test-run-report.md`	"Test function A going from page B to C to D"

Fixing a bug (`bug-squad`)

Report it, for example "Fix bug: the order list crashes when empty". The bug-squad skill enforces a strict 4-Gate Anti-Rush Sequence in .superpowers/debug/<bug-slug>/ so the agent never jumps straight to editing code:

Reproduce first: Bug Fixer reproduces the failure via an uncommitted failing test or live runtime run (NOT_REPRODUCED stops immediately).
Root cause & call-graph impact: Pinpoints the exact file:line cause using git forensics / runtime traces and maps affected callers (gitnexus + rg).
Classify & confirm: Proposes severity (S1–S4) and fix level for your confirmation before touching production code:
- L1 (Quick patch): Fixed by Bug Fixer (starting with a failing regression test) and verified by Test Runner without code review.
- L2 (Local fix): Follows fixing-plan.md, goes through Code Reviewer, and is verified by Test Runner.
- L3 (Escalate): Contract, schema, shared-code, or business-rule changes write escalation-report.md (with zero code edits) and hand off to dev-team.

Debugging without fixing (`debug-investigation`)

Ask, for example "Debug: why does the order list show yesterday's data?" or "Trace what happens from page B to C". The debug-investigation skill has Bug Fixer reproduce the bug or run the scenario, add tagged temporary logs ([DBG-<slug>]) when needed, and write diagnosis.md in .superpowers/debug/<slug>/. Every temporary log is removed and verified clean before it reports DIAGNOSED; no code change is kept. If you then want the bug fixed, it hands diagnosis.md directly to bug-squad without repeating the investigation.

Testing a scenario (`feature-testing`)

Give a scenario in your own words or as a file, for example "Test function A going from page B to C to D". The feature-testing skill has Test Runner turn it into cases, use default checks where you gave no expected result, run them on the app or API, and report PASS/FAIL per case with evidence in .superpowers/test-runs/<slug>/. It never writes tests or fixes code; any FAIL case can be handed directly to bug-squad on your confirmation.

Task intake (optional)

Connect a task tracker so agents can read tickets. Credentials go into the project's local .env. Make sure .env is in .gitignore.

Command	What it does
`coder-nexus setup huly`	Guided setup: workspace URL, then login
`coder-nexus setup huly --check`	Check that the configuration is complete (read-only)
`coder-nexus setup huly --reset`	Start setup again (e.g. expired session)
`coder-nexus my-tasks`	List your open tasks (`--all` for the whole workspace)
`coder-nexus task-detail <ID>`	Show a task with its acceptance criteria
`coder-nexus task-detail <ID> --download`	Also save attachments and linked designs under `.superpowers/sources/<ID>/`

You can also just ask the agent to "set up Huly".

Figma two-layer extraction (optional, read-only)

Add FIGMA_TOKEN=… to .env. Linked frames are downloaded with task-detail --download, or fetch one directly:

coder-nexus figma fetch "https://www.figma.com/design/<key>/<name>?node-id=<id>"

Each fetch writes per-screen renders (<stem>-SNN.png or --format jpg), a file-level W3C DTCG tokens.json (extracted from Figma styles, bound variables, and component sets), a Framelink-inspired normalized <stem>.spec.json (screens, workflows_inferred, and normalized node tree referencing tokens.json), and the raw <stem>.json ground truth.

Stack setup

coder-nexus setup flutter --check

coder-nexus setup flutter --profile external-standard

Profiles tell the agent where a Flutter project's shared building blocks come from:

Profile	Use when the project…
`external-standard`	has no shared component library; use standard framework widgets
`external-structured`	has its own design system or shared components (`lib/core/`, `lib/shared/`); reuse them
`imespro`	resolves the internal sibling packages (`../app-core`, `../app-util`, `../app-ui-kit`)

When a profile is selected (saved in .superpowers/setup.json), syncing or running setup flutter automatically injects that profile's reference guides into the installed Flutter skills under .agents/plugins/coder-nexus/skills/. coder-nexus setup flutter also runs step [4/6] Developer tools, the same as setup tools --pack flutter below. Missing tools never make the setup gate fail.

Developer tools

The skills check code with real tools (linters, type checkers, test helpers) instead of relying on the agent's reading alone. Set them up per pack:

Command	What it does
`coder-nexus setup flutter`	Flutter project setup and the Flutter tools
`coder-nexus setup tools --pack flutter`	Only the Flutter tools
`coder-nexus setup tools --pack backend`	Only the backend tools
`coder-nexus setup tools --pack <pack> --only <a,b>`	Only the named tools, optional ones included (e.g. `--only mocktail,dart_code_linter`)
`coder-nexus setup tools --pack <pack> --check`	Read-only: what is installed and what is missing

It lists the planned changes and asks once before applying them (--yes skips the question). Dev dependencies go through the stack's own package manager, missing lint or type config is added without rewriting yours, and tools it cannot install get an install hint. Results are recorded in .agents/coder-nexus.setup.json. Syncing the plugin never runs it and never edits your project files.

Kind	Backend	Flutter
Dev dependencies (default)	`pytest`, `pytest-asyncio`, `ruff`, `mypy` (`uv add --dev`)	`flutter_lints`, `mocktail`, `bloc_test` (`flutter pub add --dev`)
Dev dependencies (optional, with `--only`)	`pytest-cov`, `import-linter`, `pytest-alembic`, `pytest-randomly`	`very_good_analysis`, `dart_code_linter`
Config (added only when missing)	`[tool.ruff.lint]`, `[tool.mypy]` in `pyproject.toml` (`ruff-config`, `mypy-config`)	lint include and rules in `analysis_options.yaml` (`analysis_options`)
Installed for your user	`ripgrep`; `mockoon-cli` (optional)	`ripgrep`, `mockoon-cli`
Run through `uvx`	`pip-audit`	—
Checked only (install hint)	`git`, `uv`, `docker`; `psql` (optional)	`git`, `flutter`, `dart`; `adb`, `xcrun` (optional)

Skill Factory (new in 3.0)

Fixed packs give every project the same rules. The Skill Factory instead gives you generators: each one studies your workspace, asks you to confirm the key decisions, and writes a skill that fits your code, stack and conventions. The generated skill lives in .agents/skills/ and is yours to edit. When it covers the same topic as a pack skill, the Code Writer and Code Reviewer follow your skill.

skill-factory list

skill-factory get -p coder

Then ask your agent to run a generator, e.g. /create-clean-code-skill in Claude Code. It writes the real skill (for example .agents/skills/clean-code/) and trial-runs it on your code.

Package	Generators (`create-…-skill`)
`coder`	clean-architecture · incremental-implementation · clean-code · unit-testing · code-simplification · bug-hunt · root-cause-debugging · secure-coding-standards · database-migrations · git-workflow · api-contract-design
`reviewer`	code-review · bug-hunt · clean-architecture · clean-code · unit-testing · secure-coding-standards · database-migrations · security-review · git-workflow · api-contract-design
`security`	secure-coding-standards · security-review
`quality`	quality-planning · quality-environment · quality-acceptance · quality-reporting · visual-quality · domain-knowledge
`planning`	domain-knowledge · requirements-specification · change-impact-analysis · implementation-planning · api-contract-design

Command	What it does
`skill-factory list [-p <package>] [--json]`	List generators with version, package and scope
`skill-factory get <name> [<name>…]`	Copy one or more generators (`clean-code` or `create-clean-code-skill`)
`skill-factory get -p <package>`	Copy a whole package
`skill-factory get .`	Copy everything

get writes the generator to .agents/skills/create-*-skill/, a shared core to .agents/skill-factory-core/, and a link under .claude/skills/ so Claude Code can run it. Use --force to refresh existing copies and --workspace PATH to target another folder. Copies you already have are never overwritten without --force; compare them with a newer generator and keep what you want. Details: Skill Factory guide.

Inspect the MCP tools

npx @modelcontextprotocol/inspector coder-nexus serve

Working on Coder Nexus

Requirements: Python 3.12+, uv, Node.js (for packaging).

uv sync

uv run pytest -q

uv run coder-nexus install-plugin --pack flutter --workspace /path/to/project

npx @vscode/vsce package --no-dependencies --readme-path README.extension.md

Path	Content
`src/coder_nexus/`	CLI and MCP server
`src/skill_factory/`	`skill-factory` CLI and the generator library
`plugins/`	Agent roles, skills and stack packs (built by `python -m coder_nexus.plugin_build`)
`extension.js`	VS Code extension
`docs/guides/`	Detailed guides
`README.extension.md`	Page shown on the extension marketplace

Releases are published by pushing a vX.Y.Z tag.

Ground rules for agents

Agents cannot approve their own gates.
Task tracker and Figma access is read-only.
A result is reported as PASS only with evidence. Otherwise it stays BLOCKED, NOT_RUN or UNVERIFIED.

License: MIT

Available Tools

8 tools

get_project_structureA

Retrieve Clean Architecture blueprint and guidelines for Flutter project root or feature module.

Strictly READ-ONLY: Never generates code or touches files in the workspace.
Zero Mock Data: Returns verified blueprints with traceable source references.

Args:
    scope: Either 'root' (top-level layout & boot sequence) or 'module' (feature module).
    feature_name: Name of the feature module in lower_snake_case (required if scope='module').

Returns:
    A dictionary containing blueprint tree, DI order, and source citations.

Name	Required	Description	Default
`scope`	Yes
`feature_name`	No

Output Schema

Name	Required	Description
No output parameters

get_ux_error_patternsA

Retrieve UX design patterns, UI behaviors, and BLoC state transitions for error/edge scenarios.

Args:
    scenario: Error or edge scenario identifier (e.g., 'auth_failure', 'network_timeout', 'form_validation', 'empty_state').

Returns:
    Dictionary containing UI behavior guidance, BLoC state pattern, and anti-patterns.

Name	Required	Description	Default
`scenario`	Yes

Output Schema

Name	Required	Description
No output parameters

huly_get_my_tasksA

Open Huly tasks assigned to the logged-in user (status category not Done/Canceled).

Strictly READ-ONLY: Never modifies tasks on Huly.
Zero Mock Data: Fails fast if credentials are not configured or network error occurs.

Args:
    workspace_path: Client workspace containing the .env with Huly credentials.
                    Defaults to current working directory if empty.
    include_all: List open tasks of the whole workspace instead of only the user's own.

Returns:
    Task count and the open tasks with ID, title, status name, priority, assignee and due date.

Name	Required	Description	Default
`include_all`	No
`workspace_path`	No

Output Schema

Name	Required	Description
No output parameters

huly_get_task_detailA

Read the FULL context of one Huly issue the user names (READ-ONLY on Huly).

Returns: title, description text, status name + category, priority, assignee name, due date,
explicit acceptance criteria (with source), parent, direct sub-issues (status, assignee, AC),
comments (author, time, text) and `sources`: every PO document mention, image, attachment,
file link (e.g. a PDF linked in a comment) and external link the ticket points to, each with
a status: READ (document text included), DOWNLOADED (saved file path), AVAILABLE (call again
with download=true), UNREACHABLE (this account cannot open it: ask the user) or EXTERNAL.

Args:
    task_id: The issue the user named: an ID ('APP-123'), a number ('123', only if unique),
             a Huly _id, or a Huly issue link pasted from the browser.
    workspace_path: Client workspace containing the .env with Huly credentials.
    include_sub_issues: Also return direct child issues (one level) with their own criteria.
                        A parent issue is one feature: write one spec and use the children as
                        planning input. A child issue: scope the spec to it; parent is context only.
    download: Save files, images, attachments and readable documents to
              <workspace>/.superpowers/sources/<ISSUE-ID>/ so they can be opened and read
              (PDF, images). Use it before writing requirements. A linked Figma frame is
              saved to figma/ (PNG, node JSON, summary) as a `figma` source: READ,
              NOT_PROVIDED (no FIGMA_TOKEN in the .env) or UNREACHABLE (401/403/404).

Name	Required	Description	Default
`task_id`	Yes
`download`	No
`workspace_path`	No
`include_sub_issues`	No

Output Schema

Name	Required	Description
No output parameters

validate_architecture_codeA

Validate Dart source code against enterprise Clean Architecture rules for a specific layer.

Strictly READ-ONLY: Performs static analysis on the provided code string without writing files.
Zero Mock Data: Fails fast on invalid inputs or malformed layers, returning structured violations.

Args:
    dart_code: Full Dart source code to analyze.
    layer: Architecture layer ('domain', 'data', 'presentation', 'core', 'module').
    architecture_profile: Approved mode: imespro, external-structured, or external-standard.
        Omitted values retain legacy iMESPro checks. External Client conventions need manual verification.

Returns:
    Dictionary with status, valid flag, list of violations, checked rules, and unsupported checks.

Name	Required	Default
`layer`	Yes
`dart_code`	Yes
`architecture_profile`	No	imespro

Output Schema

Name	Required	Description
No output parameters

validate_module_architectureA

Validate module boundaries using the approved architecture profile.

iMESPro also checks its layer, screen and DI conventions. External layout/DI needs Client inspection.

Strictly READ-ONLY: Performs static inspection of the module directory without writing files.
Zero Mock Data: Fails fast if module directory does not exist or has invalid structure.

Args:
    module_path: Path to the feature module directory (e.g. lib/modules/<feature>).
    feature_name: Name of the feature module (optional, inferred from path if omitted).
    architecture_profile: Approved mode: imespro, external-structured, or external-standard.
        Omitted values retain legacy iMESPro checks. External layout/DI checks remain UNVERIFIED.

Returns:
    Dictionary containing validation status, gate_status (PASSED/FAILED), violations, and checked rules.

Name	Required	Default
`module_path`	No
`feature_name`	No
`architecture_profile`	No	imespro

Output Schema

Name	Required	Description
No output parameters

validate_plan_slicesA

Validate a versioned implementation plan and its linked behavior phases, or a legacy plan/task pair.

Strictly READ-ONLY: Never modifies files in the workspace.
Zero Mock Data: Fails fast on invalid inputs or malformed schemas, returning structured violations.
Versioned plans map ACs to linked phases in one version directory. A scoped UI-only phase is valid.

Args:
    plan_content: Raw text of implementation-plan.md or a legacy plan.
    plan_path: Optional path to docs/features/<module>/<feature>/vN/implementation-plan.md.
    task_content: Legacy task.md content; unused for versioned plans.
    task_path: Legacy task.md path; unused for versioned plans.
    feature_name: Name of the feature module (optional).

Returns:
    Dictionary containing validation status, gate_status (PASSED/FAILED), violations, and checked rules.

Name	Required	Description	Default
`plan_path`	No
`task_path`	No
`feature_name`	No
`plan_content`	No
`task_content`	No

Output Schema

Name	Required	Description
No output parameters

validate_proposal_specA

Validate versioned requirements, codebase-notes, change impact, or design Markdown; legacy proposals remain readable.

Strictly READ-ONLY: Never modifies files in the workspace.
Zero Mock Data: Fails fast on invalid inputs or malformed schemas, returning structured violations.
Anti-Self-Approval: Detects and rejects unauthorized autonomous approvals (APPROVED_BY_SPEC).

Args:
    proposal_content: Raw Markdown content of a requirements, codebase-notes, impact, design, or legacy proposal document.
    proposal_path: Optional path in docs/features/<module>/<feature>/vN/ or docs/work-items/<slug>/vN/ (legacy paths also supported).
    feature_name: Name of the feature module (optional).

Returns:
    Dictionary containing structural validation status, violations, and checked rules; never user approval.

Name	Required	Description	Default
`feature_name`	No
`proposal_path`	No
`proposal_content`	No

Output Schema

Name	Required	Description
No output parameters

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

8 tool updatesv3.3.1Oct 29, 2026
- First observedget_project_structure
- First observedget_ux_error_patterns
- First observedhuly_get_my_tasks
- First observedhuly_get_task_detail
- First observedvalidate_architecture_code
- First observedvalidate_module_architecture
- First observedvalidate_plan_slices
- First observedvalidate_proposal_spec

Deploy Server

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

TDQS

A3.9/5.0

Scored 2026-10-29 18:20 across 8 tools

Disambiguation4/5

Most tools target distinct artifacts: UX patterns, two Huly read operations, a project blueprint, and four validators keyed to different inputs (Dart code string, proposal Markdown, plan Markdown, module directory). The only real overlap is validate_architecture_code vs validate_module_architecture, which both enforce Clean Architecture rules but on different inputs (source string vs directory path) — the descriptions do disambiguate this, though an agent could still hesitate.

Naming Consistency4/5

Nearly everything follows a clean verb_noun snake_case pattern with a clear family of validate_* tools and get_* retrievals. The two huly_* tools break the pattern by adding a domain prefix while the other six do not, a minor deviation that is still readable and arguably intentional namespacing.

Tool Count4/5

Eight tools is a well-scoped count with each validator earning its place against a distinct workflow artifact. It is slightly lean for something branded a 'hub', since the surface spans two unrelated domains (Huly task retrieval and Flutter architecture validation) with no bridging tools.

Completeness3/5

The read-only validation workflow is reasonably covered end-to-end: blueprint retrieval, code-layer checks, module-boundary checks, spec validation, and plan-slice gating. However the surface has no write or creation path at all (no authoring specs, no creating or updating tasks), UX guidance is limited to error/edge scenarios only, and there is no tool to discover or list existing docs/tasks before validating them.

Maintenance

ActivityMaintained

ResponsivenessNo recent community issues

Resources

Related MCP Connectors

baseframelabs-catalogueA
io.github.abhiyoheswaran1
Agent-native catalogue of Baseframe Labs dev tools and MCP servers.
Developer Tools Agent Orchestration
52
https://mcp.baseframelabs.com
gtm-toolsA
dev.gtmtools
A read-only verified record of agent-operable GTM tools: search, fetch, compare, track changes.
Search Marketing Research & Data
1
https://mcp.gtmtools.dev/mcp
codeitso (코드잇소)A
io.github.yoorrard
Read-only catalog of app-building materials: fonts, APIs, MCP servers, libraries, templates, data.
71
https://codeitso.yoorrard.workers.dev/mcp
AgentTask AtlasA
com.agenttaskatlas
Read-only catalog of verified MCP servers and Agent Skills by dev task, with practical verdicts.
Developer Tools Search Documentation Access
31
https://agenttaskatlas.com/api/mcp

Related MCP Servers

squad-mcp
Developer Tools Project Management Code Analysis
ggemba
A
license
A
quality
C
maintenance
Exposes the squad-dev workflow as deterministic MCP tools, enabling task classification, risk scoring, specialist reviewer selection, and advisory verdict consolidation for code changes.
Updated 3 months ago (2026-08-01 09:36 UTC)
27
46 npm
4
Apache 2.0
devops-mcp-server
Monitoring Observability
rpsangam
F
license
Not graded
quality
D
maintenance
Exposes DevOps/SRE operations like Kubernetes pod status, Prometheus metrics queries, and deploy history as tools for MCP-compatible clients.
Updated 4 months ago (2026-07-15 16:06 UTC)
-
system-brain-mcp
Developer Tools Code Analysis
QEbellavita
A
license
A
quality
D
maintenance
Read-only MCP tools for coding agents to audit deployment targets, detect fabricated code, review backlog, database schema, analytics, ML models, architecture docs, and decision lenses.
Updated 3 months ago (2026-07-26 00:01 UTC)
11
14 npm
MIT
frasma
Search Documentation Access
francemazzi
F
license
Not graded
quality
B
maintenance
Exposes read-only MCP tools for discovering Frasma's profile and knowledge base, accessing the diagnostic framework, and preparing validated process briefs and diagnostic summaries with handoff URLs. It enables agents to gather operational context and generate quote-ready process assessments without sending emails.
Updated 5 days ago (2026-11-05 11:01 UTC)
-

Coder Nexus

How it works

Install

1. Install the extension

2. Install the CLI

3. Add agents to your project

4. Check your setup

Using it

Fixing a bug (bug-squad)

Debugging without fixing (debug-investigation)

Testing a scenario (feature-testing)

Task intake (optional)

Figma two-layer extraction (optional, read-only)

Stack setup

Developer tools

Skill Factory (new in 3.0)

Inspect the MCP tools

Working on Coder Nexus

Ground rules for agents

More

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

squad-mcp

devops-mcp-server

system-brain-mcp

frasma

Fixing a bug (`bug-squad`)

Debugging without fixing (`debug-investigation`)

Testing a scenario (`feature-testing`)