Future Enhancements

This section outlines potential future enhancements for the Seed MCP Server. Each enhancement has its own detailed documentation page covering the problem, proposed solution, implementation details, and acceptance criteria.

Priority Levels

• ✅ IMPLEMENTED - Feature is complete and available
• 🔵 LONG-TERM - Future considerations, implement based on user demand
• 🟢 MEDIUM - Valuable improvements, schedule when bandwidth allows
• 🔴 HIGH - Important for security/compliance, prioritize soon
• 🚫 NOT PLANNED - Not currently planned for implementation

High Priority Enhancements

Medium Priority Enhancements

Session & Authentication Management

Session Management API	🟢 MEDIUM	LOW Risk	6-8 hours

Add REST API for users to list and manage their active MCP sessions. Enables session visibility, device-specific revocation, and security auditing.

---

Password Change Token Invalidation	🟢 MEDIUM	MEDIUM Risk	12-16 hours

Detect and respond to IdP security events (password changes, account locks) to invalidate active tokens and sessions. Options include periodic token validation, webhook integration, or token introspection.

---

Max Sessions Per User	🟢 MEDIUM	LOW Risk	4-6 hours

Implement per-user session limits to prevent resource exhaustion and abuse. Includes automatic LRU eviction, configurable limits, and session count metrics.

---

Available Enhancements

---

Security & Access Control

Bind MCP sessions to client IP addresses to prevent session hijacking. Includes configurable strictness levels, session fingerprinting (IP + User-Agent), and protection against stolen session IDs.

Session IP Binding	🔵 LONG-TERM	MEDIUM Risk	3 hours

---

Fine-grained access control for MCP tools based on user roles from JWT claims. Supports role hierarchy (Admin → Developer → Operator → Viewer) with configurable tool permissions.

Role-Based Access Control (RBAC)	🔵 LONG-TERM	LOW Risk	8 hours

---

Compliance & Auditing

Comprehensive audit logging for tool invocations and system events. Redis-backed storage with user-isolated history, REST API for queries, and compliance-ready trails for SOC2, HIPAA, and GDPR. Status: Ready for implementation.

Audit Logging System	🟢 MEDIUM	HIGH Impact	20-24 hours

---

Observability & Monitoring

OpenTelemetry integration for distributed tracing across MCP requests, tool executions, and external service calls. Supports Jaeger and Grafana Tempo with request flow visualization and log-trace correlation.

Distributed Tracing	🔵 LONG-TERM	LOW Risk	8 hours

---

Enhanced Rate Limiting

Extend existing distributed rate limiting with per-user and per-tool granular controls. Includes token bucket with burst allowance, adaptive rate limiting based on system load, and user tier management. Note: Basic distributed rate limiting is already implemented.

Enhanced Rate Limiting	🔵 LONG-TERM	LOW Risk	8-12 hours

---

Session Persistence

Add persistent session storage in Redis to allow MCP sessions to survive server restarts. Includes full session state storage, session recovery on startup, graceful shutdown with preservation, and session migration between servers. Note: Currently sessions are in-memory and lost on restart.

Session Persistence	🔵 LONG-TERM	MEDIUM Risk	16-20 hours

---

OAuth Token Introspection

Add RFC 7662 token introspection endpoint for third-party token validation. Enables external services to validate tokens with client authentication, token revocation support, API gateway integration, and introspection result caching.

OAuth Token Introspection	🔵 LONG-TERM	LOW Risk	8-12 hours

---

Confidential Client Support

OAuth 2.0 confidential client support for server-to-server integrations. Currently Seed only supports public clients (PKCE-protected). This enhancement would add client secret generation, storage (hashed), and validation for client_secret_basic and client_secret_post authentication methods.

Confidential Client Support	🔵 LONG-TERM	LOW Risk	8-12 hours

Note: This is a limitation by design, not a bug. The current public client + PKCE approach is more secure for the target use case (Claude Desktop, Claude Code).

---

Not Planned

These enhancements have detailed specifications but are not currently planned for implementation. The documentation is preserved for reference purposes.

Transport Cleanup Leak

Initial analysis suggested a memory leak in MCP transport cleanup, but this was a false alarm. The code already implements lazy cleanup when expired sessions are accessed. No action required.

In-Memory Transport Cleanup	✅ FALSE ALARM	Already Handled	-

Health Check Rate Limiting

Rate limiting for health check endpoints (/health and /health/ready). Intentionally not implemented due to operational requirements - health endpoints need high availability for Kubernetes probes and monitoring systems. False positives in health checks can trigger alerts and auto-scaling events. Low security risk (timing attacks) does not justify operational impact. Network-level rate limiting (firewalls, DDoS protection) is the recommended approach for preventing abuse.

Health Check Rate Limiting	🚫 NOT PLANNED	Operational	-

---

Multi-Tenancy Support

Support for multiple isolated tenants within a single Seed deployment. Each tenant would have their own OIDC provider, client registrations, and session management. Note: The specification itself recommends deploying separate Seed instances per tenant as the preferred approach, making this enhancement unnecessary for most use cases.

Multi-Tenancy Support	🚫 NOT PLANNED	Architecture	40-60 hours

---

Contributing Enhancements

If you're interested in implementing any of these enhancements:

1. Open an Issue - Discuss the enhancement on GitLab before starting work
2. Review Architecture - Read relevant documentation in Architecture
3. Follow Patterns - Match existing code style and patterns
4. Write Tests - Comprehensive test coverage required (aim for >90%)
5. Update Docs - Documentation is mandatory for new features
6. Submit PR - Follow the PR template and checklist

See CONTRIBUTING.md for detailed guidelines.

---

Enhancement Prioritization

When evaluating which enhancements to implement, we consider:

1. User Demand (Weight: 3) - How many users are requesting this feature?
2. Compliance Impact (Weight: 2) - Does this help meet regulatory requirements?
3. Security Value (Weight: 2) - Does this improve security posture?
4. Maintenance Cost (Weight: -1) - What's the ongoing maintenance burden?
5. Implementation Effort (Weight: -1) - How much work is required?
6. Architectural Fit - Does this align with Seed's design goals?

Priority Formula:

Score = (User Demand × 3) + (Compliance Impact × 2) + (Security Value × 2)
        - Maintenance Cost - Implementation Effort

Enhancements with high scores get added to the roadmap based on available bandwidth.

---

← Back to Developer Guide