Add dual transport support (SSE) to MCP server and LM-Studio integration#843
Closed
neodingo wants to merge 13 commits intocoleam00:mainfrom
Closed
Add dual transport support (SSE) to MCP server and LM-Studio integration#843neodingo wants to merge 13 commits intocoleam00:mainfrom
neodingo wants to merge 13 commits intocoleam00:mainfrom
Conversation
0.1.0 release of Archon! Improvements across the board to crawling speed and reliability, RAG strategies, docs, task management, and documentation.
Release workflow update for Archon 0.1.0 release.
Adjusting permissions in release note workflow for Archon 0.1.0 release
🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Implements LM-Studio integration as a new embedding provider option, enabling users to run embeddings locally without API keys. This extends the existing provider ecosystem (OpenAI, Google, Ollama) with another self-hosted alternative. Backend changes: - Add lmstudio to allowed providers list in knowledge API validation - Extend credential service to handle lmstudio (no API key required) - Configure default base URL: http://host.docker.internal:1234/v1 - Add lmstudio-specific embedding model validation patterns - Include default models: text-embedding-nomic-embed-text and variants - Support local model detection (embed, nomic, all-minilm, bge, gte) Frontend changes: - Add LM-Studio provider card in RAG Settings with indigo color scheme - Include LM-Studio logo (SVG) in provider selection grid - Mark as embedding-capable provider alongside OpenAI, Google, Ollama - Set default models: llama-3.2-1b-instruct (chat), text-embedding-nomic-embed-text (embedding) - Add LMSTUDIO_BASE_URL to credentials service schema - Handle lmstudio as configured by default (local service, no key check) Technical details: - Uses OpenAI-compatible API endpoints (similar to Ollama pattern) - No authentication required for local instances - Default port 1234 with Docker host.docker.internal routing - Supports common embedding models available in LM-Studio ecosystem 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Enable PydanticAI agents (RAG, Document, etc.) to use LM-Studio as a chat provider through the "lmstudio:model-name" format. This completes the LM-Studio integration that was already present in the embedding and credential services. Changes: - Add _prepare_model_for_agent() helper to detect and handle lmstudio: prefix - Create custom AsyncOpenAI client with LM-Studio base URL - Return OpenAIChatModel configured for PydanticAI compatibility - Support LM_STUDIO_BASE_URL env var (defaults to http://host.docker.internal:1234/v1) - Maintain backward compatibility for all existing providers - Add comprehensive test suite in tests/test_lmstudio_agent.py Usage: agent = RagAgent(model="lmstudio:llama-3.2-1b-instruct") 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
…lity Implements both Streamable HTTP (/mcp) and SSE (/sse) transports to support modern and legacy MCP clients. This enables smooth migration from deprecated SSE to the modern Streamable HTTP transport (MCP protocol 2025-03-26) while maintaining backward compatibility with existing integrations. Implementation: - Modified mcp_server.py to combine routes from both streamable_http_app() and sse_app() using shared FastMCP instance and lifespan context - Added environment variables ARCHON_MCP_ENABLE_STREAMABLE_HTTP and ARCHON_MCP_ENABLE_SSE (both default to true) - Updated mcp_api.py to return transport_endpoints array with both endpoints - Added comprehensive configuration guide (python/src/mcp_server/README.md) - Updated docs/docs/mcp-server.mdx with dual transport documentation and client configuration examples for Claude Code, Cursor, and Windsurf Testing: - Both transports verified functional on isolated test port (8060) - Manual client compatibility testing completed - Production MCP server (port 8051) confirmed untouched during development 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
|
Caution Review failedThe pull request is closed. WalkthroughThis PR adds dual-transport MCP server support (Streamable HTTP and SSE) configurable via environment variables, integrates LM-Studio as a new local LLM provider across UI and backend services, updates server configuration endpoints to reflect transport capabilities, and provides comprehensive documentation and test scripts for the new transport architecture. Changes
Sequence DiagramsequenceDiagram
participant Client
participant MCP Server
participant ASGI App
participant Streamable HTTP
participant SSE Handler
Client->>MCP Server: Initialize
MCP Server->>MCP Server: Read env vars<br/>(ENABLE_STREAMABLE_HTTP,<br/>ENABLE_SSE)
alt Both Enabled (Dual Transport)
MCP Server->>Streamable HTTP: Create app at /mcp
MCP Server->>SSE Handler: Attach routes at /sse
MCP Server->>ASGI App: Combined app ready
else Only Streamable HTTP
MCP Server->>Streamable HTTP: Create app at /mcp
MCP Server->>ASGI App: HTTP-only app ready
else Only SSE
MCP Server->>SSE Handler: Create SSE app
MCP Server->>ASGI App: SSE-only app ready
end
MCP Server->>MCP Server: Start uvicorn server
MCP Server->>Client: Ready on port 8060
Client->>MCP Server: GET /mcp (HTTP)
MCP Server->>Streamable HTTP: Route
Streamable HTTP->>Client: Response
Client->>MCP Server: GET /sse (SSE)
MCP Server->>SSE Handler: Route
SSE Handler->>Client: Event stream
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (15)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
coleam00
pushed a commit
that referenced
this pull request
Apr 7, 2026
…nd types (step 2.2) (#855) * refactor(schemas): connect server schemas to engine Zod schemas + generate frontend types (step 2.2) Replace z.any() in workflowDefinitionSchema with the real engine schema imported via direct subpath (@archon/workflows/schemas/workflow). The OpenAPI spec at /api/openapi.json now describes the full workflow definition structure (name, description, provider, model, etc.) instead of a bare {} object. Add openapi-typescript as a devDep in @archon/web and generate api.generated.d.ts from the live spec. Update workflow-types.ts to derive WorkflowRunStatus and the WorkflowDefinition base fields from the generated types; DagNode-related types remain hand-written (nodes is z.array(z.any()) by design in the engine schema — per-node validation happens in loader.ts, not at the top level). Add **/*.generated.d.ts to the ESLint global ignores so auto-generated declaration files are not linted. Closes #843 * docs+test: address review feedback on schema codegen PR - Update CLAUDE.md @archon/web bullet to clarify that WorkflowRunStatus and WorkflowDefinition base fields are derived from api.generated.d.ts (not a manual mirror); DagNode and variants remain hand-written - Update CLAUDE.md import patterns comment to distinguish generated vs hand-written types instead of calling the whole file a "local mirror" - Add generate:types prerequisite note (server must be running at :3090) to the Development section of CLAUDE.md - Fix TRIGGER_RULES comment in workflow-types.ts to make explicit it is a manual copy that must be kept in sync with triggerRuleSchema.options - Add prompt?: never omission comment to WorkflowDefinition in workflow-types.ts to document the deliberate structural difference - Add schema-shape assertion to api.workflows.test.ts that verifies GET /api/workflows/:name returns name, description, and nodes fields, guarding against silent spec drift from future engine schema changes
Tyone88
pushed a commit
to Tyone88/Archon
that referenced
this pull request
Apr 16, 2026
…nd types (step 2.2) (coleam00#855) * refactor(schemas): connect server schemas to engine Zod schemas + generate frontend types (step 2.2) Replace z.any() in workflowDefinitionSchema with the real engine schema imported via direct subpath (@archon/workflows/schemas/workflow). The OpenAPI spec at /api/openapi.json now describes the full workflow definition structure (name, description, provider, model, etc.) instead of a bare {} object. Add openapi-typescript as a devDep in @archon/web and generate api.generated.d.ts from the live spec. Update workflow-types.ts to derive WorkflowRunStatus and the WorkflowDefinition base fields from the generated types; DagNode-related types remain hand-written (nodes is z.array(z.any()) by design in the engine schema — per-node validation happens in loader.ts, not at the top level). Add **/*.generated.d.ts to the ESLint global ignores so auto-generated declaration files are not linted. Closes coleam00#843 * docs+test: address review feedback on schema codegen PR - Update CLAUDE.md @archon/web bullet to clarify that WorkflowRunStatus and WorkflowDefinition base fields are derived from api.generated.d.ts (not a manual mirror); DagNode and variants remain hand-written - Update CLAUDE.md import patterns comment to distinguish generated vs hand-written types instead of calling the whole file a "local mirror" - Add generate:types prerequisite note (server must be running at :3090) to the Development section of CLAUDE.md - Fix TRIGGER_RULES comment in workflow-types.ts to make explicit it is a manual copy that must be kept in sync with triggerRuleSchema.options - Add prompt?: never omission comment to WorkflowDefinition in workflow-types.ts to document the deliberate structural difference - Add schema-shape assertion to api.workflows.test.ts that verifies GET /api/workflows/:name returns name, description, and nodes fields, guarding against silent spec drift from future engine schema changes
joaobmonteiro
pushed a commit
to joaobmonteiro/Archon
that referenced
this pull request
Apr 26, 2026
…nd types (step 2.2) (coleam00#855) * refactor(schemas): connect server schemas to engine Zod schemas + generate frontend types (step 2.2) Replace z.any() in workflowDefinitionSchema with the real engine schema imported via direct subpath (@archon/workflows/schemas/workflow). The OpenAPI spec at /api/openapi.json now describes the full workflow definition structure (name, description, provider, model, etc.) instead of a bare {} object. Add openapi-typescript as a devDep in @archon/web and generate api.generated.d.ts from the live spec. Update workflow-types.ts to derive WorkflowRunStatus and the WorkflowDefinition base fields from the generated types; DagNode-related types remain hand-written (nodes is z.array(z.any()) by design in the engine schema — per-node validation happens in loader.ts, not at the top level). Add **/*.generated.d.ts to the ESLint global ignores so auto-generated declaration files are not linted. Closes coleam00#843 * docs+test: address review feedback on schema codegen PR - Update CLAUDE.md @archon/web bullet to clarify that WorkflowRunStatus and WorkflowDefinition base fields are derived from api.generated.d.ts (not a manual mirror); DagNode and variants remain hand-written - Update CLAUDE.md import patterns comment to distinguish generated vs hand-written types instead of calling the whole file a "local mirror" - Add generate:types prerequisite note (server must be running at :3090) to the Development section of CLAUDE.md - Fix TRIGGER_RULES comment in workflow-types.ts to make explicit it is a manual copy that must be kept in sync with triggerRuleSchema.options - Add prompt?: never omission comment to WorkflowDefinition in workflow-types.ts to document the deliberate structural difference - Add schema-shape assertion to api.workflows.test.ts that verifies GET /api/workflows/:name returns name, description, and nodes fields, guarding against silent spec drift from future engine schema changes
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR adds dual transport support to the Archon MCP server for maximum client compatibility, along with LM-Studio integration for both chat and embedding capabilities.
Key Features
🔄 Dual Transport Support
test_dual_transport.sh,test_endpoints.sh)🤖 LM-Studio Integration
test_lmstudio_agent.py)📚 Documentation Updates
Changes
Files Changed
Testing
Branch sync: This branch includes merges from main/stable with updates to release workflows, README improvements, and agent mode enhancements.
Summary by CodeRabbit
New Features
Documentation
Tests