Skip to content

Conversation

@gallettilance
Copy link
Contributor

@gallettilance gallettilance commented Aug 12, 2025

Description

Type of change

  • Refactor
  • New feature
  • Bug fix
  • CVE fix
  • Optimization
  • Documentation Update
  • Configuration Update
  • Bump-up service version
  • Bump-up dependent library
  • Bump-up library or tool used for development (does not change the final image)
  • CI configuration change
  • Konflux configuration change
  • Unit tests improvement
  • Integration tests improvement
  • End to end tests improvement

Related Tickets & Documents

  • Related Issue #LCORE-226
  • Closes #

Checklist before requesting a review

  • I have performed a self-review of my code.
  • PR has passed all pre-merge test jobs.
  • If it is a core feature, I have added thorough tests.

Testing

  • Please provide detailed steps to perform tests related to this code change.
  • How were the fix/results from this change verified? Please provide relevant screenshots or results.

Summary by CodeRabbit

  • Documentation
    • Added guidance for MCP Server and Tool Configuration with sample configurations.
    • Documented per-request MCP headers usage with an example curl command.
    • Restored note clarifying run.yaml as an implementation detail; future configuration to come from lightspeed-core, including a TOML project sample.
    • Minor formatting improvement before the Integration with Llama Stack image.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Aug 12, 2025

Walkthrough

README.md updated to document MCP server configuration via lightspeed-stack.yaml, per-request MCP-HEADERS usage, and reinstates a note about run.yaml being an implementation detail with a TOML project sample. Minor formatting adjustment adds a blank line before an image.

Changes

Cohort / File(s) Summary of Changes
Documentation: MCP config and notes
README.md
Added sections on MCP server and tool configuration (sample lightspeed-stack.yaml with mcp_servers), MCP-HEADERS example via curl, and a note about run.yaml with TOML project sample; minor formatting tweak before an image.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Possibly related PRs

Suggested reviewers

  • tisnik

Poem

Thump-thump! I nudge the README’s seams,
Wiring MCP into config dreams.
Headers hop in every curl,
run.yaml’s a hidden whirl.
With stacks aligned and docs just right—
I twitch my nose, commit in sight. 🐇✨

✨ Finishing Touches
🧪 Generate unit tests
  • Create PR with unit tests
  • Post copyable unit tests in a comment

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

CodeRabbit Commands (Invoked using PR/Issue comments)

Type @coderabbitai help to get the list of available commands.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Status, Documentation and Community

  • Visit our Status Page to check the current availability of CodeRabbit.
  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@tisnik tisnik changed the title (docs) How to register MCP servers with LCORE LCORE-226: How to register MCP servers with LCORE Aug 12, 2025
Copy link
Contributor

@tisnik tisnik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (4)
README.md (4)

118-137: Good addition: clear, actionable MCP server configuration sample

The new section is helpful and concrete. Two follow-ups to tighten it:

  • Ensure the mcp_servers schema is documented in your configuration reference (keys, required/optional, validation).
  • Add a link to Model Context Protocol docs for readers unfamiliar with MCP.

Also, since this is a new third-level section under “Llama Stack as separate server,” consider regenerating the vim-markdown TOC so this header (and “Configuring MCP Headers”) appear in the TOC if that’s your convention.

Would you like me to add a short “Configuration reference” block enumerating mcp_servers[*].{name,provider_id,url} and constraints?


139-139: Wording/consistency nit: prefer “inaccessible”; capitalize consistently

Minor phrasing and capitalization polish.

Apply this diff:

-**Important**: Only MCP servers defined in the `lightspeed-stack.yaml` configuration are available to the agents. Tools configured in the llama-stack `run.yaml` are not accessible to lightspeed-core agents.
+**Important**: Only MCP servers defined in the `lightspeed-stack.yaml` configuration are available to the agents. Tools configured in the Llama Stack `run.yaml` are inaccessible to lightspeed-core agents.

141-150: Clarify header format and security considerations for MCP-HEADERS

  • Show how to set headers for multiple MCP servers and include multiple headers per server.
  • Add a brief caution that request logs and reverse proxies may capture this header; recommend redaction.

Apply this diff to expand the example:

-curl -X POST "http://localhost:8080/v1/query" \
-  -H "Content-Type: application/json" \
-  -H "MCP-HEADERS: {\"filesystem-tools\": {\"Authorization\": \"Bearer token123\"}}" \
-  -d '{"query": "List files in /tmp"}'
+curl -X POST "http://localhost:8080/v1/query" \
+  -H "Content-Type: application/json" \
+  -H $'MCP-HEADERS: {"filesystem-tools":{"Authorization":"Bearer token123"},"git-tools":{"X-API-Key":"abc123","X-Org":"eng"}}' \
+  -d '{"query":"List files in /tmp"}'

Optionally add after the example:

  • “Note: Ensure intermediaries (proxies, access logs) do not log sensitive MCP-HEADERS. Consider server-side redaction.”

155-155: Avoid repeating the same “run.yaml is an implementation detail” note

This note appears earlier (Line 120). Consider keeping it once and cross-referencing here to reduce duplication.

Apply this diff:

-**Note**: The `run.yaml` configuration is currently an implementation detail. In the future, all configuration will be available directly from the lightspeed-core config.
+See note above: `run.yaml` is currently an implementation detail; future configuration will be driven from lightspeed-core.
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between e02198e and 1824419.

📒 Files selected for processing (1)
  • README.md (2 hunks)
🧰 Additional context used
🪛 LanguageTool
README.md

[style] ~139-~139: Consider using “inaccessible” to avoid wordiness.
Context: ...gured in the llama-stack run.yaml are not accessible to lightspeed-core agents. #### Config...

(NOT_ABLE_PREMIUM)

🔇 Additional comments (1)
README.md (1)

90-90: LGTM: spacing before image improves readability

The extra blank line before the image renders cleanly in most Markdown renderers.

```yaml
mcp_servers:
- name: "filesystem-tools"
provider_id: "model-context-protocol"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the provider_id: "model-context-protocol" necessary? As it is llama-stack "thing", can it be added automatically?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But I wonder if you can have two MCPs with the same name and different providers ? If this is supported by llama-stack I fear we will need to expose it as well ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a bit complicated because the provider_id needs to match an id defined in tool_runtime. By default we just have the following defined in the run.yml:

tool_runtime:
    - provider_id: model-context-protocol
      provider_type: remote::model-context-protocol
      config: {}

The providers supported today are here

But name is toolgroup_id today which must be unique no matter the provider id (see: https://github.com/lightspeed-core/lightspeed-stack/blob/main/src/utils/common.py#L56 ).

If we want to allow for same name but different provider we can generate a toolgroup_id or something but that sounds messy.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is another MCP provider in lightspeed-providers. This is why we asked for the provider to be a parameter too.

```bash
curl -X POST "http://localhost:8080/v1/query" \
-H "Content-Type: application/json" \
-H "MCP-HEADERS: {\"filesystem-tools\": {\"Authorization\": \"Bearer token123\"}}" \
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just as in HTTP/1.x, header field names are strings of ASCII characters that are compared in a case-insensitive fashion. However, header field names MUST be converted to lowercase prior to their encoding in HTTP/2. A request or response containing uppercase header field names MUST be treated as malformed -- RFC 7540, Hypertext Transfer Protocol Version 2 (HTTP/2), Section 8.1.2

Should MCP-HEADERS be uppercase?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ldjebran I believe we use upper case from Ansible Lightspeed (as, IIRC, the header was contributed by us). Changing case could break us? Unless other code in lightspeed-core looks for the header in a case insensitive way?

Copy link
Contributor

@ldjebran ldjebran Aug 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@manstis we are already using uppercase when sending the header just as the curl command above, do not think this should affect anyone as soon as they can be converted to lowercase or looking in a case insensitive way.

forcing clients to have headers in lowercase will break us for sure.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

curl actually send Mcp-headers in request. And as HTTP/1.1 standard says, header names are case insensitive, so don't worry much ;)

Copy link
Contributor

@umago umago left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

```yaml
mcp_servers:
- name: "filesystem-tools"
provider_id: "model-context-protocol"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But I wonder if you can have two MCPs with the same name and different providers ? If this is supported by llama-stack I fear we will need to expose it as well ?

Copy link
Contributor

@ldjebran ldjebran left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@tisnik tisnik merged commit 2cc494c into lightspeed-core:main Aug 14, 2025
18 checks passed
@coderabbitai coderabbitai bot mentioned this pull request Sep 16, 2025
18 tasks
@coderabbitai coderabbitai bot mentioned this pull request Nov 10, 2025
15 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants