Normal Epic Goal
Deliver the tools that will be required by the Agent/s as MCP Server as a separate and early deliverable.
Why is this important?
- BU may decide to prioritize this.
- Technically, if customers are willing to test out the tools, this can be a high quality feedback for us.
- We have nothing to lose by sharing this earlier because we will need to work on these anyway.
Scenarios
Customer has a LLM like Claude Desktop. This can be easily configured to talk to MCP Server. And then they run simple commands that use the tool.
Acceptance Criteria
TBD
Dependencies (internal and external)
- Will RH creating a standard recommendation/way for creating MCP Servers.
- Will RH deliver a LLM (vLLM?) to run on CPU for the customer to play with MCP Server
Previous Work (Optional):
- ...
Open questions:
- What about Authz functionality. The community is working on it - but will we release ours before Authz is done? Perhaps making our tools read only is enough.
- Do we have to create a mcp cli or a llama-stack client for the customer to play with this; Or will this be for their own to figure out.
Done Checklist
- CI - CI is running, tests are automated and merged.
- Release Enablement <link to Feature Enablement Presentation>
- DEV - Upstream code and tests merged: <link to meaningful PR or GitHub
Issue> - DEV - Upstream documentation merged: <link to meaningful PR or GitHub
Issue> - DEV - Downstream build attached to advisory: <link to errata>
- QE - Test plans in Polarion: <link or reference to Polarion>
- QE - Automated tests merged: <link or reference to automated tests>
- DOC - Doc issue opened with a completed template. Separate doc issue
opened for any deprecation, removal, or any current known
issue/troubleshooting removal from the doc, if applicable. - Considerations were made for Extended Update Support (EUS)
