-
Notifications
You must be signed in to change notification settings - Fork 14
feat(mcp): implement MCP Gateway for internal and external tools #213
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: eng-97/workflow-tool-mode
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1a188c2285
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const result = await component.execute( | ||
| { inputs: mergedInputs as any, params: {} as any }, | ||
| { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Parse tool inputs/params before executing components
The MCP gateway calls component.execute with inputs: mergedInputs and params: {} directly, which bypasses the component’s Zod parsing/defaults and drops any workflow node parameters. That means tool calls will silently ignore required params or coercions (e.g., ports, endpoints, defaults), causing components to misbehave or throw at runtime. Consider fetching the node config for the run and running component.inputs.parse / component.parameters.parse before invoking execute.
Useful? React with 👍 / 👎.
| async execute() { | ||
| // The Docker runner handles execution. | ||
| // At runtime, the workflow engine will resolve the dynamic endpoint. | ||
| return { | ||
| endpoint: 'http://localhost:8080', // Placeholder |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually run docker runner in MCP server component
The new core.mcp.server component’s execute only returns a hardcoded endpoint and never calls runComponentWithRunner. In this codebase, docker components are executed only when the component itself invokes the runner (the activity doesn’t auto-run it), so this component will never start the MCP server container and will always return the placeholder URL.
Useful? React with 👍 / 👎.
fc4c1eb to
9ed839a
Compare
b32f6c6 to
f5e332d
Compare
Signed-off-by: betterclever <paliwal.pranjal83@gmail.com>
… MCP proxying - Replace deprecated SSEClientTransport with StreamableHTTPClientTransport - Fix lint errors (trailing whitespace in constructor and emitProgress) - Gateway currently executes components inline (to be refactored to Temporal) Signed-off-by: betterclever <paliwal.pranjal83@gmail.com>
- Add executeToolCallSignal and toolCallCompletedSignal for MCP tool calls - Add getToolCallResult query for polling tool execution results - Refactor callComponentTool to signal workflow instead of inline execution - Add queryWorkflow method to TemporalService - Tool calls now execute on worker with full Docker/secrets/storage support Signed-off-by: betterclever <paliwal.pranjal83@gmail.com>
…ation - Refactor component tool execution to run on Temporal workers via signals/queries - Implement validation for workflow run access and organization ownership - Add comprehensive telemetry: log tool execution (STARTED, COMPLETED, FAILED) to trace repository - implement robust external MCP proxying with 30s timeouts and exponential backoff retries - Add support for tool filtering via allowedTools header - Add E2E test for MCP gateway tool discovery and execution Signed-off-by: Antigravity <antigravity@google.com> Signed-off-by: betterclever <paliwal.pranjal83@gmail.com>
- Extract X-Run-Id and X-Allowed-Tools headers in McpGatewayController - Pass organizationId and allowedTools to McpGatewayService - Add basic protocol version validation - Fix type casting for MCP transport request handling Signed-off-by: betterclever <paliwal.pranjal83@gmail.com>
…eway - Add McpAuthService to manage short-lived, run-bounded session tokens - Implement McpAuthGuard for RFC 6750 (Bearer) compliance and AuthInfo injection - Refactor McpGatewayController to use native MCP AuthInfo instead of internal AuthContext - Add internal endpoint /internal/mcp/generate-token for session token issuance - Update E2E tests to validate the complete secure handshake and tool execution flow - Fix type safety issues in MCP transport integration Signed-off-by: Antigravity <antigravity@google.com> Signed-off-by: betterclever <paliwal.pranjal83@gmail.com>
…script harness - Ensure component 'parameters' are passed through tool registration and execution signals - Correctly map agent 'arguments' to component 'inputs' in runComponentActivity - Fix race condition in logic-script harness by ensuring output directory exists before write - Update E2E gateway test to reflect correct registration and execution pattern - Clean up debug logs and resolve linting errors across gateway and worker Signed-off-by: betterclever <paliwal.pranjal83@gmail.com>
f5e332d to
f1752c2
Compare
Summary
/mcpAPI withGET /toolsandPOST /tools/callendpoints.Stacked on: #212 (ENG-97)