https://cloudposse.com logo
Join Slack
Powered by
Hey guys! I have a question about Atmos MCP config...
# atmos
m
Hey guys! I have a question about Atmos MCP configuration that came up during the latest office-hours meeting. I've reviewed the docs at https://atmos.tools/cli/configuration/mcp and the example at https://atmos.tools/gists/mcp-with-aws where ATMOS_PROFILE is set for authentication. Currently, I'm defining multiple MCP servers and need to set ATMOS_PROFILE and identity for each one individually. For example:
Copy code
mcp:
  servers:
    server-one:
      env:
        ATMOS_PROFILE: 'managers'
      identity: "core-root/terraform"
    server-two:
      env:
        ATMOS_PROFILE: 'managers'
      identity: "core-root/terraform"
Is there a way to configure ATMOS_PROFILE and identity globally so they apply to all MCP servers by default, rather than repeating them in each server definition? PS: I think the links for the last office hour are missing on the channel.
a
@Miguel Zablah there are a few diff things here: https://atmos.tools/cli/configuration/mcp - what you see on the page was merged to 
main
but not released yet (see https://github.com/cloudposse/atmos/pull/2267), it will be released today/tomorrow
to answer your question, no, we have not implemented 'global' settings for external MCP servers in 
atmos.yaml
- but thank you for pointing it our, we'll consider that
fast parrot 1
also note that https://atmos.tools/gists/mcp-with-aws is yet another way to configure and use external MCP servers in Atmos using Atmos custom commands and executing commands from the Claude Code CLI (not related to the PR above, but complimentary)
m
ah! I miss that I though they say it was already there on the office hour but I miss heard then!! thanks for the clarification hehe
Thanks I have implemented the gist one works really well
āœ… 1
a
@Miguel Zablah Atmos 1.214.0 has been releasd https://github.com/cloudposse/atmos/releases/tag/v1.214.0
fast parrot 1
with regards to Atmos AI + MCP, it now allows you to do it in two (maybe more?) different ways (you either use Atmos CLI or Claude Code CLI for prompts): ā€¢ Use Claude Code CLI (or other AI CLI), configure AWS MCP servers + Atmos MCP server, Configure Atmos Auth - Claude Code will execute the prompts and invoke the configured MCP servers (using Atmos Auth for credentials) - as shown in the Gist ā€¢ Use Atmos CLI, in 
atmos.yaml
configure external MCP servers, configure Atmos AI (API provider or CLI provider), configure Atmos Auth and toolchain - use 
atmos ai ask
to ask questions about your infra, Atmos will ask the AI provider which MCP servers to start, will start the servers, will send the prompt to the AI (API or locally via stdin), the AI provider will ask Atmos to execute tools from the configured MCP servers, Atmos will send the result back to the AI provider for 'thinking', and the result will be displayed in the console
m
That was fast! Nice!! I will give this a try first I will try to replicate the gist but using this and then I will try 
atmos ai ask
though last time I try it it was really but this is maybe the claude model I chose šŸ˜›
@Andriy Knysh (Cloud Posse) I have set it up using locals but it looks that it dosent like this can we not use 
locals
in mcp.yaml? also is there no 
atmos mcp test all
? like the gist example
a
locals
can be used in Atmos stack manifests, not in 
atmos.yaml
and any files belonging to CLI config (like 
mcp.yaml
- this is part of 
atmos.yaml
CLI config, not Atmos stack manifest)
regarding the second question, the command https://atmos.tools/cli/commands/mcp/status will start all configured MCP servers, ping them, check if they are alive and good to go, and generate a status report
atmos mcp status
m
Well there goes my attempt to set global profile and identity hahahaha
And I missed that one hehehe
a
since all of that is new, there could be issue - please let us know if you find anything, or any areas for improvements
m
@Andriy Knysh (Cloud Posse) Dose the envs should be respected by atmos? here is and example of 1 mcp server:
Copy code
mcp:
  enabled: true
  routing:
    enabled: true
  servers:
    atmos:
      description: Atmos MCP server
      command: atmos
      args: ["mcp", "start"]
      env:
        ATMOS_PROFILE: managers
      identity: core-root/terraform
The ENV 
ATMOS_PROFILE
is not being read by atmos CLI so the identity is not being found and test fails. If I set it manually it works, Ej. 
ATMOS_PROFILE=managers atmos mcp test atmos
is this expected are the ENV only for that mcp server?
yeah this means that when generating the mcp.json file it will not add the atmos profile as the gist dose so that will not work as well šŸ˜¢
a
this should work (we have tests for that, and I tested it manually). something is different in your config. can you please create a GH issue?
(oh, I see, it's Atmos MCP - this is different from the external MCPs. Please create a GH issue)
m
On it
a
you are 100% into testing all of this šŸ™‚ thank you, you help to improve Atmos a lot
m
I love all the stuff you guys are doing and I actually use atmos daily on multiple project so it's the least I can do!!
here is the issue hopefully I can get more time to actually help fix this instead of just creating more issues hahahaha
@Andriy Knysh (Cloud Posse) Hey so I saw that you close the issue but it looks that it's not working I ask Claude to check my issue with the fix and this is what it found:
Copy code
This is a bug in the fix itself (PR #2291). Here's what's happening:

1. Viper lowercases all YAML map keys ā€” your ATMOS_PROFILE: managers in the env: block becomes atmos_profile: managers in memory
2. The fix's filterAtmosOverrides() filters for keys starting with ATMOS_ (uppercase), but Viper has already lowercased it to atmos_profile
3. The filter silently drops the override, so the auth manager is built with the default profile (no ATMOS_PROFILE set)
4. The default profile doesn't have core-root/terraform, hence the identity not found error

There was a separate fix for this exact Viper lowercasing issue in mcpconfig.go (for CLI provider MCP pass-through), but it was not applied to the auth env-override path.
So it looks like it might be a simple fix? hopefully haha PS: Sorry for the delay on this I'm currently traveling hehe
šŸ‘€ 1
@Andriy Knysh (Cloud Posse) Should I create a new issue or reopen the same one?
a
please reopen the same one, and add more description/info
m
It looks like I don't have permissions to re-open the same issue šŸ˜¢
a
please open a new one
m
@Andriy Knysh (Cloud Posse) Here is the new issue: https://github.com/cloudposse/atmos/issues/2349
a
thanks, we'll get to it, the fix will be in the next atmos release
m
thank you!!
2 Views
Open in Slack
PreviousNext
Powered by