rent.dev

Get a port URL

rent_get_port_url

Read-onlyIdempotent

The public HTTPS URL of a port in the sandbox (https://{port}-{sandbox}.{domain}). It serves while the sandbox runs and something listens on the port.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "sandbox_id": "<sandbox_id>",
      "port": "<port>"
    },
    "name": "rent_get_port_url"
  }
}

Input Schema

Name	Required	Description	Default
`port`	Yes
`sandbox_id`	Yes	Sandbox id (`lse_…`) from rent_create_sandbox or rent_list_sandboxes. It names the sandbox for its whole life and keeps answering rent_get_sandbox, with the final state, after it ends.

Output Schema

Name	Required	Description	Default
`url`	Yes
`port`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A3.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare this read-only, idempotent and non-destructive, so the description earns credit for adding beyond that: the URL is public HTTPS in a fixed `{port}-{sandbox}.{domain}` shape and is only valid while the sandbox runs and a process is listening on the port. That lifetime/exposure detail is exactly the kind of behavior an agent cannot get from the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with what the tool returns and followed by the condition under which the value is meaningful. No wasted wording.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present the description needn't explain the return value, and for a simple read-only lookup it covers exposure, URL shape, and validity window. The only real gap is the meaning of the `port` parameter, which neither schema nor description fully explains.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50%: sandbox_id is documented but `port` carries no schema description. The URL template `{port}-{sandbox}` hints at how the two parameters combine, but the description never says the port is the port the app listens on inside the sandbox, so it only partially compensates for the undocumented parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource precisely as the public HTTPS URL of a port in the sandbox and even shows the URL template, so an agent knows exactly what comes back. It never contrasts itself with a sibling such as rent_get_sandbox, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: an agent infers it should call this when it needs an externally reachable address for a service inside the sandbox. The clause about the URL serving while the sandbox runs and something listening on the port effectively states a precondition, but there is no explicit when-to-use or when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All rent.dev tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?