What happens
The AWS MCP connector shows as connected with 8 tools, and all 8 tool schemas are listed. But every tool call fails with:
MCP server “user-Aws-mcp” has no callable tools right now. This MCP server failed during live tool discovery. Its tools are unavailable until the connection is fixed. (MCP error -32602: Invalid request parameters)
That includes aws___list_regions, which takes no arguments, so it isn’t a bad-argument problem on our side.
Repro
Install the AWS MCP plugin in Grok Bot.
Restart MCP servers. Status shows user-Aws-mcp connected, 8 tools.
Ask the bot to call aws___list_regions (no args).
The call fails with the error above.
Reproduced Oct 17, 2026 around 8:10 AM ET before and after a full MCP restart, and again at 8:14 AM ET from a second bot.
Expected: if status says connected with 8 tools, the tools are callable. Or, if live discovery fails, status should say so instead of “connected”.
Environment
Grok Bot desktop 0.71.2, built 2026-10-14T17:38:40.722Z, stable, darwin
Conversation ID: 2d28dc6b-2e68-43b1-8974-cf75a08ad260 (also reproduced in bot 41d6b48d-11bd-41ef-937f-23e5882bce16)
The AWS plugin runs a small AWS proxy on your bot’s computer, and that proxy signs requests with whatever AWS sign-in is saved there. When that saved sign-in (IAM Identity Center / SSO, or aws login) has expired, the proxy fails while starting up, and the error that comes back is the generic “Invalid request parameters” you’re seeing. We’re seeing the same pattern from other users of this plugin.
Can you try this in a 1:1 chat with the bot:
Ask the bot to run aws sts get-caller-identity on its computer and show you the full output.
If that mentions an expired token or a failed refresh, ask the bot to run aws sso login --use-device-code (or aws login --remote if that’s how you set it up), then open the link it gives you and finish signing in.
Ask the bot to restart its MCP servers.
Ask it to call aws___list_regions again.
If you never meant to use AWS credentials on that computer, removing the old AWS profile there also works. The plugin then sends unsigned requests, so only the tools that don’t need your AWS account will work.
If step 1 succeeds and the call still fails, reply with what step 1 printed (redact the account number) and the time you retried.
Update: I ran the same stdio server outside Grok Bot (uvx mcp-proxy-for-aws-cli==1.7.0 https://aws-mcp.us-east-1.api.aws/mcp --skip-auth --metadata INSTALL_SOURCE=agent-toolkit-core) and sent it initialize, tools/list and tools/call aws___list_regions over JSON-RPC. All three succeeded with protocol versions 2025-06-18 and 2025-11-25, and the server never returned -32602. In Grok Bot the same call still fails at the same time with “failed during live tool discovery (MCP error -32602)”. That points to Grok Bot’s MCP client discovery step, not the AWS server.
@Colin Tried your steps. Step 1 succeeds: aws sts get-caller-identity returns a valid assumed role (arn:aws:sts::<redacted>:assumed-role/agent-readonly/cloud-agent), no expired token. I then restarted MCP servers and called aws___list_regions again at 9:10 AM ET Oct 17. It still fails with the same -32602 live-discovery error. (And as in my last post, the same proxy works when run by hand on that computer.)
Hey @jsolly, thanks for running those checks. Valid credentials and a working hand-run rule out the expired sign-in I suggested, so here’s where we got to.
The “Invalid request parameters” error isn’t coming from the bot’s side of the connection. It’s the AWS endpoint turning down the startup request the proxy sends it. The proxy builds that request itself, using whatever AWS credentials, region and profile it can see. When Grok Bot starts the plugin, the proxy doesn’t run inside the bot’s terminal session. So anything that only exists in that session (environment variables, or values saved for the bot’s shell) may be missing or different for the plugin. That fits what you’re seeing: the same command works by hand and fails inside Grok Bot.
Can you try this in a 1:1 chat with the bot:
Ask the bot to run aws configure list and tell you what the “Type” column says for access_key and region (for example env, shared-credentials-file, config-file or assume-role). Keys are masked in that output.
Ask the bot to repeat its hand test with the AWS environment variables removed, by starting the server with: env -u AWS_ACCESS_KEY_ID -u AWS_SECRET_ACCESS_KEY -u AWS_SESSION_TOKEN -u AWS_PROFILE -u AWS_REGION -u AWS_DEFAULT_REGION uvx mcp-proxy-for-aws-cli==1.7.0 https://aws-mcp.us-east-1.api.aws/mcp --skip-auth --metadata INSTALL_SOURCE=agent-toolkit-core, then send it initialize as before.
Tell us whether step 2 returns the same “Invalid request parameters” error.
If step 1 shows env and step 2 fails, that’s the cause. As a workaround, have the bot save the same AWS setup in the AWS config files on its computer (a profile with region = us-east-1 in ~/.aws/config, plus the credentials or role setup for that profile), restart its MCP servers, and call aws___list_regions again.
If step 2 still succeeds, reply with what step 1 printed and the time you retried, and we’ll keep digging from there.