-
Notifications
You must be signed in to change notification settings - Fork 791
Fix HTTP timeouts #616
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix HTTP timeouts #616
Conversation
WalkthroughThe pull request updates API endpoint references from a public domain to an internal domain across configuration constants and documentation files. Changes are consistent URL replacements with no modifications to underlying logic or control flow. Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes
Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
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. Comment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
examples/mcp_agent_server/asyncio/README.md(1 hunks)src/mcp_agent/cli/core/api_client.py(1 hunks)src/mcp_agent/cli/core/constants.py(1 hunks)src/mcp_agent/data/examples/mcp_agent_server/asyncio/README.md(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-07-22T18:59:49.368Z
Learnt from: CR
Repo: lastmile-ai/mcp-agent PR: 0
File: examples/usecases/reliable_conversation/CLAUDE.md:0-0
Timestamp: 2025-07-22T18:59:49.368Z
Learning: Applies to examples/usecases/reliable_conversation/examples/reliable_conversation/src/**/*.py : Use mcp-agent's Agent abstraction for ALL LLM interactions, including quality evaluation, to ensure consistent tool access, logging, and error handling.
Applied to files:
examples/mcp_agent_server/asyncio/README.md
🔇 Additional comments (3)
src/mcp_agent/cli/core/api_client.py (1)
60-60: Documentation updated correctly.The docstring example now reflects the new internal API endpoint, consistent with the updated default constant.
src/mcp_agent/data/examples/mcp_agent_server/asyncio/README.md (1)
192-192: Example log output updated correctly.The deployment log example now shows the new internal API endpoint, keeping documentation consistent with the actual behavior.
examples/mcp_agent_server/asyncio/README.md (1)
192-192: Example log output updated correctly.The deployment log example reflects the new internal API endpoint, consistent with other documentation updates.
|
|
||
| # API defaults | ||
| DEFAULT_API_BASE_URL = "https://mcp-agent.com/api" | ||
| DEFAULT_API_BASE_URL = "https://web-internal.mcp-agent.com/api" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧩 Analysis chain
Verify endpoint accessibility and backwards compatibility.
The change from mcp-agent.com to web-internal.mcp-agent.com raises concerns:
-
Accessibility: The "internal" subdomain suggests this endpoint may not be publicly accessible. This could break external integrations and deployments that rely on the default URL.
-
DNS resolution: Verify that
web-internal.mcp-agent.comis resolvable from all deployment contexts (public internet, cloud providers, on-premises, local development). -
Migration path: If this is a breaking change, users may need guidance on:
- Using the
MCP_API_BASE_URLenvironment variable to maintain the old endpoint - Timeline for deprecating the old endpoint
- Any authentication or configuration differences
- Using the
-
Testing scope: The PR description mentions "ensure existing integrations continue to work," but it's unclear whether this means:
- The internal endpoint is publicly accessible
- The old endpoint remains operational as a fallback
- Users must update their configuration
Please run the following verification:
Additionally, please search for information about this endpoint change:
🏁 Script executed:
#!/bin/bash
# Verify the internal endpoint is accessible and the old endpoint behavior
# Test DNS resolution for new endpoint
echo "=== Testing DNS resolution for web-internal.mcp-agent.com ==="
nslookup web-internal.mcp-agent.com || echo "DNS resolution failed"
# Test HTTP connectivity to new endpoint
echo -e "\n=== Testing HTTP connectivity to new endpoint ==="
curl -I -m 5 https://web-internal.mcp-agent.com/api || echo "HTTP request failed"
# Test HTTP connectivity to old endpoint
echo -e "\n=== Testing HTTP connectivity to old endpoint ==="
curl -I -m 5 https://mcp-agent.com/api || echo "HTTP request to old endpoint failed"
# Check if old endpoint redirects to new one
echo -e "\n=== Checking for redirects ==="
curl -L -I -m 5 https://mcp-agent.com/api 2>&1 | grep -i location || echo "No redirect found"Length of output: 1601
🌐 Web query:
web-internal.mcp-agent.com public accessibility
💡 Result:
I couldn't find any public records or pages for the hostname web-internal.mcp-agent.com — it does not appear in the mcp-agent docs or public listings and likely is an internal/private subdomain rather than a public endpoint. [1][2]
If you want to verify from your side, run one of these checks from your network:
- DNS lookup: dig +short web-internal.mcp-agent.com or nslookup web-internal.mcp-agent.com
- HTTP check: curl -I https://web-internal.mcp-agent.com
- Port reachability: nc -vz web-internal.mcp-agent.com 80 (or 443)
If those fail, contact the mcp-agent admin or your network team — the domain is likely internal to their infrastructure (mcp-agent public deployments use other *.deployments.mcp-agent.com patterns). [2]
Sources:
[1] mcp-agent project homepage and docs.
[2] mcp-agent “MCP-Cloud / deployments” documentation.
Endpoint change is a breaking change—new default URL is not publicly accessible.
Verification confirms the original concern: the new endpoint web-internal.mcp-agent.com is not reachable from external networks (connection refused), while the old endpoint mcp-agent.com/api remains publicly accessible. The old endpoint does not redirect to the new one.
Impact:
- All external integrations using the default URL will immediately fail with connection errors
- The claim in the PR description that "existing integrations continue to work" is contradicted by this evidence
- This is a breaking change requiring migration guidance or a functional fallback
Required before merge:
Either change the default URL back to a publicly accessible endpoint, or implement automatic fallback/retry logic that allows the old endpoint to be used when the internal endpoint fails.
🤖 Prompt for AI Agents
In src/mcp_agent/cli/core/constants.py around line 27 the DEFAULT_API_BASE_URL
is set to the internal, non-public endpoint
"https://web-internal.mcp-agent.com/api" which breaks external integrations;
either revert this constant to the previous public default
"https://mcp-agent.com/api" or implement fallback logic where the client first
tries the internal URL and on connection failure (timeout/ECONNREFUSED)
transparently retries the public URL, logging the fallback and honoring any
environment/config override so integrations can opt-in to the internal host.

TL;DR
Updated API base URL from mcp-agent.com to web-internal.mcp-agent.com to reflect recent backend changes
What changed?
Changed the default API base URL from
https://mcp-agent.com/apitohttps://web-internal.mcp-agent.com/apiacross multiple files:DEFAULT_API_BASE_URLin constants.pyHow to test?
Why make this change?
To fix it
Summary by CodeRabbit
Chores
Documentation
✏️ Tip: You can customize this high-level summary in your review settings.