[mangeshraut712]

Fixes #4812

Summary

Changes

With AUTH_TYPE=no-auth on streamable HTTP, call_aws was still registered, so anyone who could reach the endpoint could run AWS operations with the server's credentials. This leaves call_aws out of tool registration whenever the HTTP server has no authentication provider. stdio and OAuth-protected HTTP still expose it. suggest_aws_commands and get_execution_plan stay available, since they don't touch the AWS account.

User experience

Before: an unauthenticated HTTP deployment exposed call_aws. After: that deployment only lists the read-only tools; stdio and OAuth setups see no change.

Checklist

• I have reviewed the contributing guidelines
• I have performed a self-review of this change
• Changes have been tested
• Changes are documented

Tests: regression tests reload the server under AUTH_TYPE=no-auth and under OAuth and check that call_aws is hidden and exposed respectively. pytest tests/test_server.py (75 passed), ruff check, ruff format --check, and pyright are clean.

Is this a breaking change? (Y/N) Y for anyone running no-auth HTTP who relied on call_aws. That setup was unsafe, but I'm happy to add a warning or an explicit opt-in flag if you'd prefer.

Acknowledgment

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the project license.

[mangeshraut712]

Fixes #4812

Why: With AUTH_TYPE=no-auth on streamable HTTP, call_aws stayed registered so unauthenticated clients could use the server's AWS credentials.

What: Omit call_aws from tool registration when the HTTP server has no auth provider. stdio and OAuth-protected HTTP unchanged. suggest_aws_commands / get_execution_plan stay available.

Test: pytest tests/test_server.py (75 passed); ruff + pyright clean. Regressions for no-auth vs OAuth registration.

[mangeshraut712]

CI is green. Hides call_aws when AUTH_TYPE=no-auth. Please review and merge when you can.