Konnexx Development MCP Server
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| generate_ticketsC | Generate development tickets in batches of 5 from API endpoints and timeline |
| generate_tickets_batchC | Generate multiple ticket batches for architecture projects |
| design_erdC | Design Entity-Relationship Diagram from requirements |
| extract_requirementsD | Extract and structure requirements from documentation |
| specify_api_endpointsC | Specify API endpoints from requirements and ERD |
| create_timeline_ganttC | Create timeline and Gantt chart from tickets and API endpoints |
| synthesize_documentationC | Orchestrate complete architecture workflow and synthesize all documentation |
| implement_featureB | Execute complete feature implementation workflow following team standards: plan → approve → implement → review → test. Uses MCP servers (GitHub, Database, Context7) for integrated workflow. ALWAYS use this for feature implementation to ensure consistency with team patterns (DDD, Laravel conventions). |
| test_fixC | Run tests, identify failures, and fix them using parallel agents |
| test_fix_incrementalB | Run tests incrementally, fixing failures as they occur (faster for large test suites) |
| architecture_reviewC | Review code for architectural compliance (DDD, Laravel patterns) |
| implement_feature_webB | Execute complete Next.js feature implementation workflow following team's 7-step process: Types → Service → Hooks → Components → Screens → Routes. ALWAYS use this for Next.js features to ensure architectural compliance and consistency. |
| test_fix_webC | Run tests for Next.js application and fix failures |
| test_fix_incremental_webC | Run tests incrementally for Next.js application, fixing failures as they occur |
| architecture_review_webB | Review code for architectural compliance (Next.js patterns) |
| implement_feature_mobileC | Implement a feature for Flutter mobile application |
| commit_prA | Execute complete commit and PR workflow: auto-detects project type, generates conventional commit messages, cleans up plan files, commits, pushes, and creates PR with proper formatting. Uses GitHub MCP for PR operations. ALWAYS use this instead of manual git commands to ensure team standards. |
| verify_mcp_serversB | Execute workflow to verify all MCP servers are working (Context7, GitHub, Filesystem, Database, Browser). Use this to test MCP connectivity and diagnose issues. |
| clear_plansC | Execute workflow to automatically clear Cursor plan files from the project. Follows team standards for cleanup. |
| db_queryC | Execute database query workflow using Database MCP. Provides standardized query execution with proper error handling. |
| docs_lookupC | Execute documentation lookup workflow using Context7 MCP. Provides up-to-date library documentation and code examples. |
| test_packageA | Execute local package testing workflow: builds package, creates npm link, verifies MCP server startup, and validates command files. Use this to test the konnexx-dev-mcp package locally before publishing. |
| publish_packageA | Execute complete package publishing workflow: reviews changes, determines version bump, builds package, updates version, creates git commit and tag, pushes to GitHub, and publishes to npm. ALWAYS use this for publishing konnexx-dev-mcp to ensure proper versioning and tagging. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 23 tools
Most tools are clearly distinct, but generate_tickets and generate_tickets_batch overlap significantly in purpose, both generating tickets. Additionally, synthesize_documentation orchestrates multiple individual workflow steps, which could lead to misselection when an agent only needs a single step.
Tool names follow a consistent verb_noun pattern (generate_tickets, design_erd, implement_feature), with platform-specific suffixes like _web and _mobile. Minor inconsistencies include abbreviations (db_query, docs_lookup) and the slightly awkward generate_tickets_batch.
At 23 tools, the server is on the heavy side of the ideal range. While the broad scope of development workflows justifies many tools, it borders on being overwhelming and could benefit from consolidation.
The tool surface covers the full development lifecycle from requirements and architecture through implementation, testing, PR creation, and package publishing. Some gaps exist (e.g., no explicit deployment or ticket update tools), but core workflows are well-covered.