feat: Add workflow support to MCP server#178
feat: Add workflow support to MCP server#178christopher-tin-atlan wants to merge 12 commits intomainfrom
Conversation
christopher-tin-atlan
commented
Nov 14, 2025
christopher-tin-atlan
commented
- Add new workflows.py module with 6 workflow retrieval functions
- Register 6 new MCP tools with comprehensive LLM-friendly docstrings
- Add metadata extraction functions for WorkflowTemplate and Workflow types
- Include naming convention notes and usage guidance in all tool docstrings
- Implement error handling and type safety improvements
- Export all workflow functions in tools/init.py
…tion - Add new workflows.py module with 6 workflow retrieval functions - Implement two-tier field naming convention (run_* and workflow_* prefixes) - Register 6 new MCP tools with comprehensive LLM-friendly docstrings - Add metadata extraction functions for WorkflowTemplate and Workflow types - Include naming convention notes and usage guidance in all tool docstrings - Implement error handling and type safety improvements - Export all workflow functions in tools/__init__.py
christopher-tin-atlan
requested review from
Hk669 and
firecast
as code owners
- Remove get_workflow_run_by_id function as it provides no additional value over get_workflow_runs - Standardize terminology: workflow = WorkflowTemplate, workflow_run = Workflow - Update all docstrings to use consistent 'workflow' and 'workflow_run' terminology - Clarify that only functions starting with get_workflow_run return workflow_run information - Update LLM instructions in server.py to match implementation
|
@Hk669 / @firecast - Loom video with the demo: https://www.loom.com/share/a22c6f476ba44bdfb62267145ac388a5 |
…le tool get_workflows
… parameters workflow_phase vs status
|
@abhinavmathur-atlan - I've consolidated all the workflows to three tools:
My validation test is here: https://atlanhq.atlassian.net/browse/CSA-1117 Let me know if you approve! |
| - package_name, package_version: Package information | ||
| - source_system, source_category, workflow_type: Source information | ||
| - certified, verified: Certification status | ||
| - creator_email, creator_username: Creator information |
There was a problem hiding this comment.
we should not send all this information
There was a problem hiding this comment.
Removed
- package_version
- source_system
- source_category
- workflow_type
- certified
- verified
I left the creator information and package name, as it does give useful information for our end users on who last created/modified the package internally which they can use for troubleshooting.
There was a problem hiding this comment.
Noted I saw your request on removing PII data in later comments. I have removed created/modified user information.
| - creation_timestamp: When template was created | ||
| - package_author, package_description, package_repository: Package metadata | ||
| - workflow_steps: Workflow steps (only when getting by ID) | ||
| - workflow_spec: Full workflow specification (only when getting by ID) |
There was a problem hiding this comment.
do we need to send the spec? What use cases are you targetting with this tool?
There was a problem hiding this comment.
Agreed. workflow_specs has been removed.
Keeping workflow_steps as it is useful to identify patterns of failures which can help the LLM make recommendations on possible issues. However, it does expose our internal pipeline patterns, which is visible in the UI, so I'm assuming that is not an issue.
| def get_workflow_runs_tool( | ||
| workflow_name: str | None = None, | ||
| workflow_phase: str | None = None, | ||
| status: str |
There was a problem hiding this comment.
Looks like status and workflow_phase seem to do the same thing
| f"Retrieving workflows with workflow_package_name={workflow_package_name}, max_results={max_results}" | ||
| ) | ||
|
|
||
| logger.debug( |
There was a problem hiding this comment.
Remove this since we already have an info log
|
|
||
| return { | ||
| "workflows": [processed_workflow] if processed_workflow else [], | ||
| "total": 1 if processed_workflow else 0, |
| - total: Total count of workflow_runs | ||
| - error: None if no error occurred, otherwise the error message | ||
|
|
||
| Examples: |
There was a problem hiding this comment.
Examples etc. are not required here since those are present in the tools. Same for all functions in this file
|
|
||
| # Use workflow_phase if provided, otherwise use first item from status list | ||
| phase_to_use = workflow_phase | ||
| if not phase_to_use and status: |
There was a problem hiding this comment.
This whole block looks complicated and can be solved with a pydantic model
| # Process the response | ||
| runs = [] | ||
| total = 0 | ||
| if response and response.hits and response.hits.hits: |
There was a problem hiding this comment.
isn't total always len(processed_runs)?
…ove API terminology. Simplified descriptions to enhance understanding of 'workflow' and 'workflow_run' distinctions.
…low and workflow_run terminology. Removed API-specific language for improved readability and consistency.
3 participants
