Click on "Deploy 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., "@LLM-bridge-mcp-server review the project structure and identify issues"
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.
LLM-bridge-mcp-server is a local-first MCP server that lets Codex, Claude Desktop, and other MCP-compatible hosts use GLM-family and compatible LLM providers as knowledge consultants, reasoning specialists, UI auditors, repository inspectors, and approval-gated development assistants.
The project started as a thin model bridge. It now exposes a safer orchestration layer around provider requests, persistent context, bounded agent loops, repository memory, workflows, jobs, and approval-controlled file changes. The host remains the primary controller at every stage.
For installation and package metadata, the npm package name remains lowercase and scoped: @magnexis/llm-bridge-mcp-server. The GitHub repository and display branding use LLM-bridge-mcp-server.
Release guide: RELEASE.md
Most model bridges either stop at plain prompting or overreach into unrestricted autonomy. This server is built around a narrower and more practical middle ground:
strong MCP compatibility
explicit security boundaries
local-first persistence
approval-driven mutation
auditable orchestration
provider-aware LLM integration
Related MCP server: openai-mcp
MCP host
-> strict Zod-validated tool input
-> MCP server registration layer
-> provider-aware GLM client / local orchestration services
-> local persistence, policy, workflow, and approval stores
-> approval-gated file mutation and allowlisted command executionThe compiled entry point is dist/index.js, and npm start launches node dist/index.js.
The server supports both local stdio MCP hosting and remote HTTP MCP hosting. Use GLM_BRIDGE_TRANSPORT_MODE=stdio for local hosts like Codex or Claude Desktop, or GLM_BRIDGE_TRANSPORT_MODE=http to expose a remote streamable HTTP MCP endpoint.
Compatibility note: the project branding is now LLM-bridge-mcp-server, while the existing public MCP tool names, resource URIs, prompts, and GLM_BRIDGE_* environment variables remain stable for backward compatibility.
Release artifacts included in this repository:
package.json for npm publication
server.json for MCP Registry metadata
manifest.json as a desktop-extension packaging manifest scaffold
LICENSE and CHANGELOG.md for release distribution
For npx-style launch flows, publish the executable CLI package as:
npx @magnexis/llm-bridge-mcp-serverCapability | Status |
Knowledge consultation | Implemented |
Deep reasoning | Implemented |
Vision/UI auditing | Implemented |
Smart routing | Implemented |
Controlled read-only agent loop | Implemented |
Persistent contexts | Implemented |
Persistent sessions | Implemented |
Repository memory | Implemented |
Approval-gated file changes | Implemented |
Checkpoint and rollback | Implemented |
Allowlisted approved commands | Implemented |
Roles and orchestration jobs | Implemented |
Workflow registry and runner | Implemented |
Workspace inspection | Implemented |
Restricted network retrieval | Implemented, disabled by default |
Streamable HTTP MCP transport | Implemented |
Legacy SSE MCP compatibility endpoint | Implemented |
Remote bearer-token protection | Implemented |
OAuth metadata discovery for remote MCP clients | Implemented |
Import and export | Implemented in safe JSON form |
Privacy modes | Partially implemented in config and policy surface |
Core tools preserved:
glm_5_route_agentic_task
glm_5_query_reasoning
glm_5_consult_knowledge
glm_5v_diff_ui_layout
glm_5_smart_route
glm_5_run_controlled_agent
glm_5_context_manage
glm_5_inspect_project_context
glm_5_continue_task
Development and orchestration tools:
glm_5_propose_changes
glm_5_approve_and_apply_changes
glm_5_rollback_changes
glm_5_plan_code_change
glm_5_propose_patch
glm_5_apply_approved_patch
glm_5_review_change_set
glm_5_rollback_change_set
glm_5_run_approved_command
glm_5_execute_development_task
glm_5_orchestrate_project_task
glm_5_inspect_job
glm_5_resume_job
glm_5_cancel_job
glm_5_manage_policy_profile
glm_5_inspect_repository_memory
glm_5_update_repository_memory
glm_5_create_workflow
glm_5_run_workflow
glm_5_list_pending_approvals
glm_5_inspect_workspace
glm_5_compare_model_recommendations
glm_5_evaluate_model_routing
glm_5_fetch_reference
glm_5_export_project_state
glm_5_import_project_state
glm-bridge://capabilities
glm-bridge://configuration
glm-bridge://contexts
glm-bridge://sessions
glm-bridge://jobs
glm-bridge://workflows
glm-bridge://policies
glm-bridge://approvals
glm-bridge://repository-memory
glm-bridge://evaluations
glm_architecture_review
glm_repository_audit
glm_debugging_session
glm_ui_review
glm_second_opinion
glm_implementation_task
glm_safe_refactor
glm_fix_failing_tests
glm_dependency_upgrade
glm_multi_agent_implementation
glm_repository_modernization
glm_security_remediation
glm_release_readiness
glm_architecture_consensus
Supported providers:
direct Z.AI via ZAI_PROVIDER=zai
OpenRouter-compatible chat completions via ZAI_PROVIDER=openrouter
The provider capability layer distinguishes text, vision, structured output, reasoning toggles, and numeric reasoning-budget support rather than assuming all OpenAI-like providers behave identically.
npm install
copy .env.example .env
npm run build
npm startOn macOS or Linux, use cp .env.example .env.
Required:
ZAI_API_KEY
Important optional variables:
ZAI_PROVIDER
ZAI_API_BASE_URL
ZAI_TEXT_MODEL
ZAI_VISION_MODEL
GLM_BRIDGE_DATA_DIR
GLM_BRIDGE_LOG_LEVEL
GLM_BRIDGE_TRANSPORT_MODE
GLM_BRIDGE_HTTP_HOST
GLM_BRIDGE_HTTP_PORT
GLM_BRIDGE_REMOTE_AUTH_MODE
GLM_BRIDGE_REMOTE_AUTH_TOKEN
GLM_BRIDGE_RATE_LIMIT_ENABLED
GLM_BRIDGE_RATE_LIMIT_MAX_REQUESTS
GLM_BRIDGE_PROVIDER_RATE_LIMIT_PER_MINUTE
GLM_BRIDGE_NETWORK_ENABLED
GLM_BRIDGE_ALLOWED_DOMAINS
npm run typecheck
npm run test:run
npm run build
npm run inspect:mcp
npm run verifySee docs/CLAUDE-DESKTOP.md and examples/claude_desktop_config.json.
See docs/CODEX.md and examples/codex-config.toml.
This repository is now structured for MCP Registry publication as an npm package with a companion server.json. See docs/REGISTRY-PUBLISHING.md.
When GLM_BRIDGE_TRANSPORT_MODE=http, the server exposes:
streamable HTTP at GLM_BRIDGE_HTTP_MCP_PATH (default /mcp)
deprecated SSE compatibility at GLM_BRIDGE_HTTP_SSE_PATH (default /sse)
deprecated SSE message POST endpoint at GLM_BRIDGE_HTTP_MESSAGES_PATH (default /messages)
a health endpoint at /healthz
protected resource metadata at /.well-known/oauth-protected-resource{mcpPath}
optional OAuth authorization metadata at /.well-known/oauth-authorization-server
Remote auth modes:
none
bearer
oauth_metadata
Knowledge consultation:
Use glm_5_consult_knowledge for a second opinion on a TypeScript API boundary.Reasoning:
Use glm_5_query_reasoning to compare retry policies for provider failures.Vision:
Use glm_5v_diff_ui_layout with an absolute local screenshot path and a review objective.Controlled agent:
Use glm_5_run_controlled_agent for bounded repository inspection in a specific working directory.Approvals and patches:
Use glm_5_propose_patch to persist a reviewable change set, then glm_5_apply_approved_patch with the exact matching approvalId.Multi-agent coordination:
Use glm_5_orchestrate_project_task to create a role-specific job and inspect it with glm_5_inspect_job.no unrestricted shell execution
no unrestricted filesystem access
no unrestricted network retrieval
no automatic mutation resume after restart
no access to .env, private keys, .aws, .ssh, .npmrc, or similar sensitive files
no raw Base64 image persistence in resources or stores
no hidden chain-of-thought exposure
All file mutation remains explicit and proposal-bound. The current implementation uses distinct approval records per proposal revision, with expiry, single-use consumption, and revocation when a proposal materially changes.
The controlled agent is read-only and only exposes a bounded local tool allowlist:
read_text_file
list_directory
search_text
inspect_package
inspect_git_status
The server stores contexts, sessions, development proposals, audit records, jobs, policies, repository memory, and workflows under GLM_BRIDGE_DATA_DIR using atomic JSON replacement.
Repository memory tracks architecture notes, conventions, testing patterns, security rules, dependencies, and known strategies with provenance, confidence, and status metadata.
Orchestration jobs and workflow runs persist planning state and task graphs. Mutation still requires explicit approval; jobs do not auto-resume writes after restart.
glm_5_inspect_workspace detects workspace signals such as npm workspaces, pnpm, Turborepo, Nx, and Lerna and reports package manifests visible within the inspected repository.
glm_5_fetch_reference is disabled by default. When enabled, it allows HTTPS-only retrieval with an allowlist, rejects credential-bearing URLs, blocks localhost and private-IP literal targets, rejects redirects, and limits content to text-like responses.
The policy/profile surface exposes standard, minimal_retention, and no_persistence. Runtime enforcement is still partial, so the docs describe those modes as in-progress rather than fully complete.
The test suite is built with Vitest and does not require a live API key. Use:
npm run test:runMissing key: set ZAI_API_KEY in the host MCP environment.
Empty tool list: rebuild and restart the host after changing the server.
Network fetch denied: GLM_BRIDGE_NETWORK_ENABLED is false by default.
Approval failure: the apply/rollback request must use the exact matching proposal identifier.
Approval records now exist, but broader queue/reissue workflows can still be deepened further.
Remote hosting is implemented for streamable HTTP and legacy SSE compatibility. WebSocket server hosting is not included in the current SDK/runtime pass.
Privacy-mode enforcement is not yet comprehensive across all stores.
The network retrieval layer is still fail-closed and intentionally narrow.
Documentation now reflects the implemented state, not the full aspirational architecture.
complete privacy-mode enforcement
deepen orchestration consensus behavior
deepen quality-gate execution
complete privacy-mode enforcement
generalize workflow-step execution and rollback semantics
MIT � 2026 Magnexis. See LICENSE.
Apply an explicitly approved proposed patch and create a rollback checkpoint.
Inputs: approvalId (required), proposalId (required).
Apply an explicitly approved proposal's scoped file operations, create a rollback checkpoint, and record an audit entry. Commands are not executed.
Inputs: approvalId (required), proposalId (required).
Cancel future work in a persisted job while preserving audit state.
Inputs: jobId (required), reason, rollbackIfPossible.
Compare a reasoning-oriented GLM answer with an independent knowledge-oriented answer for the same question.
Inputs: question (required), context.
Consult GLM for an independent expert explanation, second opinion, architecture advice, or unfamiliar concept—not task execution.
Inputs: question (required), domain, context, outputFormat, +4 more.
Create, update, retrieve, list, or delete reusable local project contexts. Contexts never include API keys.
Inputs: action (required), name, tags, content, +2 more.
Continue a persisted agentic task using its objective and compact prior summary. It proposes only and does not execute host tools.
Inputs: sessionId (required), instruction (required), maxSteps, additionalContext.
Create a reusable local workflow definition with validated step dependencies and bounded step types.
Inputs: steps (required), title (required), workflowId (required), description (required).
Score likely routing modes for a request without executing the routed tool.
Inputs: request (required), imagePath.
Create an auditable development orchestration plan using the safe development workflow surface. No mutation occurs automatically.
Inputs: objective (required), workingDirectory (required), mode, roles, +5 more.
Export safe persisted bridge state such as workflows, policies, repository memory, and job summaries without secrets or raw source files.
Inputs: includeJobs, includeMemory, includeContexts, includePolicies, +2 more.
Fetch an external HTTPS reference only when network retrieval is enabled and the target domain is allowlisted.
Inputs: url (required), allowRedirects.
Import safe persisted bridge state from a validated payload. Dry-run is enabled by default.
Inputs: payload (required), dryRun, overwrite.
Inspect a persisted orchestration job and its safe task graph status.
Inputs: jobId (required), includeTaskGraph, includeAuditSummary.
Safely inspect an approved local project directory with read-only bounded file metadata, tree, package, and Git-summary information.
Inputs: projectPath (required), maxDepth, includeFileTree, includeGitSummary, +1 more.
List or inspect persisted repository memory entries with provenance, confidence, and status metadata.
Inputs: action (required), title, status, content, +5 more.
Inspect a repository or monorepo root for workspace signals, package manifests, and package layout metadata.
Inputs: workingDirectory (required).
List pending change proposals that still require an exact matching approval before mutation or approved commands.
Inputs: no named parameters.
Inspect or upsert auditable policy profiles that control writes, commands, network access, and privacy posture.
Inputs: action (required), profileId, allowWrites, deniedPaths, +12 more.
Create an auditable role-specific, dependency-aware development plan/job. It never mutates files without a separate explicit approval workflow.
Inputs: objective (required), workingDirectory (required), mode, roles, +5 more.
Plan an approval-gated code change and persist the proposed file operations without mutating the repository.
Inputs: summary (required), operations (required), workingDirectory (required), commands.
Create a persistent, reviewable file-change proposal. This never mutates files or executes commands; explicit matching approval is required for application.
Inputs: summary (required), operations (required), workingDirectory (required), commands.
Propose a scoped patch as reviewable file operations. No files are changed until a later exact approval.
Inputs: summary (required), operations (required), workingDirectory (required), commands.
Resolve a difficult technical, systems, debugging, algorithmic, mathematical, or architecture bottleneck with provider-supported reasoning.
Inputs: prompt (required), outputFormat, reasoningBudget, projectContextId, +1 more.
Reissue a fresh approval ID for the current proposal revision, revoking the previous approval token.
Inputs: approvalId (required), proposalId (required), reason.
Resume a non-mutating job planning state; mutation remains approval-gated.
Inputs: jobId (required), approvalId, additionalInstruction.
Inspect a proposed change set together with its audit trail before approval or rollback.
Inputs: proposalId (required).
Revoke the current approval token for a proposal without applying mutation.
Inputs: approvalId (required), proposalId (required), reason.
Restore a proposal checkpoint after an explicit matching approval token. Only restores files in the proposal's working directory.
Inputs: approvalId (required), proposalId (required), checkpointId (required).
Roll back an applied change set by restoring its checkpoint inside the approved working directory.
Inputs: approvalId (required), proposalId (required), checkpointId (required).
Delegate multi-step planning, implementation proposals, debugging, migrations, or refactors to GLM; it proposes but never executes host tools.
Inputs: taskDescription (required), maxSteps, contextCode, sessionName, +3 more.
Run an allowlisted project validation command after explicit matching approval. Arbitrary shell execution is not supported.
Inputs: command (required), approvalId (required), proposalId (required), workingDirectory (required).
Run a bounded, read-only GLM tool-use loop within an approved directory. It cannot write files or run arbitrary commands.
Inputs: task (required), dryRun, context, allowedTools, +3 more.
Instantiate a reusable workflow as an auditable planning job. It can optionally execute approved command-backed quality gates.
Inputs: objective (required), workflowId (required), workingDirectory (required), createJob, +4 more.
Deterministically route a request to vision, agentic planning, reasoning, or knowledge consultation without recursive MCP calls.
Inputs: request (required), context, imagePath, preferredMode, +1 more.
Create or update repository memory entries. Confirmed facts require explicit provenance; inference must remain marked accordingly.
Inputs: action (required), title, status, content, +5 more.
Audit a local PNG, JPEG, JPG, or WEBP screenshot, mockup, or wireframe against an objective using the vision model.
Inputs: imagePath (required), systemObjective (required), outputFormat, projectContextId, +1 more.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 37 tools
Many tools have overlapping purposes despite detailed descriptions. For instance, `propose_changes`, `propose_patch`, and `plan_code_change` all create proposals but differ in scope. Similarly, `continue_task`, `route_agentic_task`, and `orchestrate_project_task` all involve multi-step planning. This makes it difficult for an agent to select the correct tool without deep analysis.
All tools follow a strict `glm_5_verb_noun` pattern (e.g., `glm_5_propose_changes`, `glm_5_rollback_changes`). The prefix is uniform, verbs are consistent (camelCase), and nouns clearly indicate the object of operation. No mixing of styles or irregular names.
With 37 tools, the set is large but may be justified by the complex domain of safe development orchestration with proposals, approvals, rollbacks, jobs, workflows, and contexts. However, many tools could be consolidated without loss of functionality, suggesting the count is slightly excessive.
The tool surface covers a wide range of operations: proposals, approvals, rollbacks, jobs, workflows, knowledge, contexts, repository memory, and policies. Minor gaps exist, such as the inability to delete proposals directly (only revoke approval) and no tool to cancel a running job after it has started. Overall, lifecycle coverage is strong.
MCP server for GLM chat completions using Zhipu AI models via AceDataCloud
MCP server for AI dialogue using various LLM models via AceDataCloud
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.