Provides tools to perform Singapore-localized Google searches through a Singapore mobile IP.
Browse the web as if you were on a Singapore mobile network. Give Claude, Cursor, Cline, or any MCP agent a real Singapore mobile IP (SingTel / StarHub / M1 carrier ASNs) to fetch pages, run Singapore-localized Google searches, and check geo-locked content - something the agent cannot do on its own because it can't set a proxy.
The Singapore web, as your AI sees it.
This is a hosted (remote) MCP server. You don't install or run any code - you point your client at the endpoint with a free API key and it works.
Get a free key (includes 10GB): https://singaporemobileproxy.com/client/mcp
Add the server to your client:
Claude Desktop / Cursor / Cline / Windsurf (claude_desktop_config.json, ~/.cursor/mcp.json, etc.):
{
"mcpServers": {
"singapore-proxy": {
"command": "npx",
"args": ["-y", "singapore-proxy-mcp"],
"env": { "SMP_API_KEY": "sk_your_key_here" }
}
}
}(singapore-proxy-mcp is a thin launcher around mcp-remote
pointed at the hosted endpoint. If you prefer, you can call mcp-remote directly:
npx -y mcp-remote https://mcp.singaporemobileproxy.com/mcp --header "x-api-key:${SMP_API_KEY}".)
Claude.ai / clients with native remote MCP: add a custom connector for
https://mcp.singaporemobileproxy.com/mcp with header x-api-key: <your key>.
Ask your agent: "use my_proxy_status" - it should report a Singapore mobile exit IP.
Related MCP server: ProxyClaw MCP Server
Tool | What it does |
| Fetch a page through a SG mobile IP (markdown / text / html) |
| Singapore-localized Google organic results ( |
| Get a fresh Singapore mobile IP |
| Current exit IP, carrier, remaining quota |
Global proxy MCP servers (Bright Data, Oxylabs, Apify) are generalists. This one does only Singapore, on real mobile-carrier ASNs that are hard to source and high-trust.
Use cases: SERP / SEO / ad verification from a real SG IP, e-commerce and app-store availability + pricing checks in Singapore, scraping SG geo-gated sites for agents, PDPA / localization QA.
Free 10GB to start at singaporemobileproxy.com/client/mcp. Heavy use upgrades to a dedicated Singapore mobile proxy subscription - the same proxy works over HTTP/SOCKS outside MCP too.
https://mcp.singaporemobileproxy.com/mcp - Streamable HTTP, auth via x-api-key header.
Built on the SingaporeMobileProxy farm. Not affiliated with Anthropic, Google, or any carrier. See PUBLISHING.md for how this server is listed in MCP registries.
Fetch a URL through a Singapore mobile IP and return its content.
Args:
url: The full http(s) URL to fetch.
format: One of "markdown" (default, clean main content), "text", or "html".
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| format | No | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It discloses the egress path (Singapore mobile IP) and output formats, but omits edge behaviors like redirects, error handling, or failure modes. Still, the core read-only fetch behavior is stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact blocks: a one-sentence purpose followed by an Args list. No filler; allowed values and the default are front-loaded with the parameter definitions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter fetch tool, the essentials are present: target, format, and network path. With an output schema available, the lack of explicit return-type detail is acceptable, though examples or error behavior would round it out.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates: it defines url as a full http(s) URL and enumerates format values with default and meaning ('clean main content'). Both parameters are semantically clear beyond the bare string types in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete action ('Fetch a URL') with a distinctive constraint ('through a Singapore mobile IP'), clearly distinguishing it from sibling tools like search_google or rotate_ip. The resource and network context are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to choose this over siblings; it neither names alternatives nor states conditions/exclusions. The Singapore mobile IP hint provides context, but the description does not help an agent decide between fetch_url and search_google for retrieving web content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the current Singapore exit IP, carrier, and remaining quota.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. 'Show' clearly indicates a non-mutating read operation, and the listed outputs make the tool's behavior concrete. It could still disclose potential side effects or costs, but none are evident for a status tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence delivers the full purpose with no filler. The main action and outputs are front-loaded and immediately actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description sufficiently covers the essential context: what status is being queried, its geographic scope, and the quota aspect. Nothing critical is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema has no parameter semantics to convey. The description focuses on the returned status information, which is the only meaningful semantic content available.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Show') and narrows the resource to 'current Singapore exit IP, carrier, and remaining quota.' This is clearly distinct from sibling tools such as fetch_url, rotate_ip, and search_google, which target different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a status-check use case but does not explicitly state when to use it versus siblings. Because the sibling tools have obviously different functions, the ambiguity is minimal, yet no explicit when-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Request a fresh Singapore mobile IP for the current proxy.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly states the action (requesting a fresh IP) and the specifics (Singapore mobile, for current proxy). Though it doesn't mention side effects like timing or impact on existing connections, the operation is simple and self-explanatory – the behavior is transparent enough for an agent to understand what happens.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. It names the action, the specific IP type (Singapore mobile), and the target (current proxy) – all essential information, nothing extraneous.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no annotations, an output schema exists), the description is adequate. It explains the core action and scope. It doesn't mention prerequisites like an active proxy, but that is implied by 'current proxy.' The presence of an output schema likely covers return value details, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so there is nothing for the description to add. The baseline for zero parameters is 4, and the description doesn't need to explain any parameter semantics beyond what the empty schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Request a fresh Singapore mobile IP for the current proxy.' It distinguishes from siblings like fetch_url (fetching URLs), my_proxy_status (checking status), and search_google (searching) – none of which involve IP rotation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this tool is for rotating the proxy IP. While it doesn't explicitly state when not to use it or mention alternatives, the sibling tool names make the boundary obvious, and the single-purpose nature leaves no ambiguity. It's a clear context without exclusions, but lacks explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a Singapore-localized Google search (gl=sg) and return organic results.
| Name | Required | Description | Default |
|---|---|---|---|
| num | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does mention localization and organic results, but it omits other behavioral traits such as rate limits, proxy usage, pagination behavior, or any nuance about the result format. For a tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core action and scope. Every word contributes: 'Run', 'Singapore-localized', 'Google search', 'gl=sg', 'return organic results'. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description is incomplete for a 2-parameter tool: it leaves 'num' unexplained, gives no usage guidance, and provides sparse behavioral context. An agent would need to guess what 'num' means and what limitations the Singapore-localized search might have.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description does not explain the 'query' or 'num' parameters at all; 'num' (likely result count) is completely opaque. The description adds no value beyond the schema's bare property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Run') and resource ('Google search'), and adds a clear differentiator: 'Singapore-localized (gl=sg)' and 'return organic results'. This clearly distinguishes it from siblings like fetch_url and rotate_ip, which serve entirely different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage—when you need Google search results—but does not explicitly state when to use this tool versus alternatives or mention any exclusions. Siblings are clearly different, so the context is implicit rather than explicit, fitting 'implied usage'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0fetch_urlmy_proxy_statusrotate_ipsearch_googleScored across 4 tools
Each tool targets a distinct operation: fetching arbitrary URLs, running Google searches, rotating the IP, and checking proxy status. There is no overlap between these purposes.
Three tools follow a clear verb_noun pattern: fetch_url, search_google, rotate_ip. my_proxy_status breaks the pattern and would be more consistent as get_proxy_status, but the overall naming is still predictable.
Four tools is well-scoped for a narrow proxy-focused server. Each tool earns its place without redundancy or unnecessary bloat.
The server covers the core proxy workflow: fetch content, search the web, rotate the IP, and inspect status. No obvious missing operations are apparent for its stated purpose.
Dedicated static outbound IPv4 over WireGuard. Free 7-day trial, no card, no sales call.
Buy and manage residential, mobile and datacenter proxies in 170+ countries, prepaid per GB
Singapore property & financial data APIs for AI agents. 27 MCP tools. x402 micropayments.
Route HTTP requests through the Tor network. Rotating exit IPs, .onion support, no body logging.
