feat(dsl): implement workflow tool mode handling and MCP server node #212
Conversation
…ents ENG-95 - Add PortBindingType and bindingType to ComponentPortMetadata - Add AgentToolConfig and agentTool to ComponentUiMetadata - Create tool-helpers.ts with isAgentCallable, getToolSchema, getCredentialInputIds, getActionInputIds, getToolName, getToolDescription, getToolMetadata - Add comprehensive tests for all helper functions (14 tests) Signed-off-by: betterclever <[email protected]>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7074d5305c
ℹ️ 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".
| 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.
In the workflow runner, only component.execute is called; Docker execution is not triggered automatically (see run-component.activity.ts, which expects components to call runComponentWithRunner themselves). This execute implementation just returns a placeholder endpoint and never starts the container, so workflows that include this node will not actually launch an MCP server and will point to http://localhost:8080 even if nothing is running. Unless an external server is already up, the node will silently succeed but downstream tool calls will fail.
Useful? React with 👍 / 👎.
| let encryptedCredentials: string | undefined; | ||
| if (authToken) { | ||
| const encryptionMaterial = await this.encryption.encrypt(authToken); | ||
| encryptedCredentials = JSON.stringify(encryptionMaterial); |
There was a problem hiding this comment.
registerRemoteMcp encrypts a raw authToken string, but getToolCredentials later does JSON.parse on the decrypted payload. For non-JSON tokens, this throws and credentials are dropped, so remote MCP auth tokens become unretrievable. Either JSON.stringify the token before encryption or make getToolCredentials accept plain strings for remote-mcp tools.
Useful? React with 👍 / 👎.
…itecture Signed-off-by: betterclever <[email protected]>
ENG-96
- Create ToolRegistryService with Redis-backed storage
- Implement registerComponentTool, registerRemoteMcp, registerLocalMcp
- Implement getToolsForRun, getTool, getToolByName, getToolCredentials
- Implement areAllToolsReady for agent readiness check
- Implement cleanupRun for workflow completion cleanup
- Encrypt credentials using existing SecretsEncryptionService
- Redis key pattern: mcp:run:{runId}:tools (Hash, TTL 1hr)
- Add McpModule to app imports
- Add comprehensive tests (8 tests passing)
Note: Temporal activities (registerToolActivity, waitForToolsActivity, etc.)
will be added in a follow-up as they reside in the worker package.
Signed-off-by: betterclever <[email protected]>
Signed-off-by: betterclever <[email protected]>
Signed-off-by: betterclever <[email protected]>
betterclever
force-pushed
the
eng-97/workflow-tool-mode
branch
from
7074d53 to
f79081a
Compare
Summary
WorkflowNodeMetadatato supportmode('normal' | 'tool') andtoolConfig.core.mcp.servercomponent (Docker-based) to allow workflows to start and manage external tool providers.Stacked on: #208 (ENG-96)