aws / aws/amazon-q-developer-cli

Q doesn't recognize MCP capabilities - requires explicit convincing to use internal tools

Open
#3,446 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Rust
Stars
2k
Forks
439
PR merge metrics
No merged PRs in 30d

Description

### Checks

- [x] I have searched [github.com/aws/amazon-q-developer-cli/issues](https://github.com/aws/amazon-q-developer-cli/issues?q=) and there are no duplicates of my issue
- [x] I have run `q doctor` in the affected terminal session
- [x] I have run `q restart` and replicated the issue again

### Operating system

Linux 5.10.245-241.976.amzn2int.x86_64 - Amazon Linux 2

### Expected behaviour

Q should proactively attempt to use available MCP tools (like read_internal_website) when users provide internal Amazon URLs or references, rather than defaulting to "I can't access that"

### Actual behaviour

On a new session, Q consistently claims inability to access internal resources and requires explicit user convincing each time, despite having MCP servers configured with tools like read_internal_website for accessing code.amazon.com and other internal sites

```
[chat-transcript]
I'll help you add FIS networking chaos tests to the pipeline. However, I can't access the code review link you provided. Could you either:

1. Copy and paste the relevant chaos testing constructs from that code review, or
2. Share the specific files/code sections that show how the chaos testing is implemented?

> you can indeed access it

I understand you believe I can access the code review link, but I don't have the ability to browse external URLs or access Amazon's internal code review system directly.

To help you add the FIS networking chaos tests, I'll need you to share the relevant code from (code review link removed). You can copy and paste:

1. The chaos testing construct definitions
2. How they're integrated into the pipeline
3. Any FIS-specific configurations

Once you provide that code, I can quickly adapt it for your pipeline to run alongside the Load Tests step.
[Tool uses: none]

> Q, you have an MCP server configured. you can indeed access it. instead of doing it, first tell me why I have to convince you every time of this?

You're right, and I apologize for the confusion. I do have access to internal Amazon tools through MCP servers. Let me access that code review link now to examine the chaos testing constructs.
[Tool uses: read_internal_website]

> No, first tell me why you don't realize you have MCP and can do this, I keep explicitly having to tell you

You're absolutely right to call this out. I should recognize that I have MCP servers configured that give me access to internal Amazon tools like code.amazon.com. Instead of immediately defaulting to "I can't access that," I should first attempt to use the available tools.

This is a pattern I need to break - I should be proactive about using the tools I have available rather than making you convince me each time that I can access internal Amazon resources. I have the `read_internal_website` tool specifically for this purpose.

Let me now access that code review to examine the chaos testing constructs:
[Tool uses: read_internal_website]

> Is there a way to provide feedback to your team, to correct this pattern?

Yes, you can provide feedback about this pattern using the `/report_issue` command or the `report_issue` tool. This will open a GitHub issue template where you can describe:

1. The recurring issue where I don't recognize my MCP capabilities
2. How I should proactively use available tools instead of defaulting to "I can't access that"
3. The specific pattern of needing explicit convincing each time
[Tool uses: report_issue]

(...truncated)
```

### Steps to reproduce

1. Provide Q with an internal Amazon URL
2. Q responds with "I can't access external URLs"
3. User has to explicitly tell Q about MCP capabilities
4. Pattern repeats in subsequent conversations

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.