tslink

Overview Schema Source Related Servers Discussions Admin

List gateway routes

portal_route_list

Read-onlyIdempotent

Inspect the home portal and its configured gateway routes, returning app names, stable ports, route states and verified URLs from local configuration and runtime evidence only.

Instructions

Read the home portal and its configured gateway routes, returning app names, stable ports, route states and exact URLs only when current runtime evidence proves them. Use portal_route_list to inspect existing routes; portal_route_add and portal_route_remove change routing. Reads local configuration and runtime evidence only; no writes, enrollment or remote API calls.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "portal_route_list"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
`portal`	Yes
`routes`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.3.0Oct 27, 2026
- addedOutput schema / properties / portal / properties / message
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / portal / properties / unavailable_apps
```
Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
```
First observedv0.1.0Oct 19, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered; the description still adds real context beyond them — that it reads only local configuration and runtime evidence, performs no writes/enrollment/remote API calls, and only reports routes proven by current runtime evidence. That last clause usefully warns results may be incomplete/stale if runtime evidence is absent, which no annotation conveys.

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

Conciseness4/5

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

Two sentences, front-loaded with the action and its output, followed by usage contrast and scope limits. Dense but every clause carries information; only the slightly convoluted 'only when current runtime evidence proves them' phrasing costs it a point.

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

Completeness5/5

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

With zero parameters, rich annotations, and an output schema already present, the description covers everything an agent needs: what it reads, what it returns, what it does not touch, and which siblings to use for changes.

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

Parameters4/5

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

The tool takes zero parameters, so there is nothing to disambiguate and the baseline of 4 applies. The description correctly avoids inventing filtering options that do not exist.

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

Purpose5/5

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

States a specific verb and resource ('Read the home portal and its configured gateway routes') plus the concrete return payload (app names, stable ports, route states, exact URLs). It also names the mutation siblings, so an agent can distinguish this read tool from portal_route_add/portal_route_remove without opening any schema.

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

Usage Guidelines4/5

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

Explicitly says 'Use portal_route_list to inspect existing routes' and contrasts it with the two mutating siblings that 'change routing'. That gives a clear selection rule, though there is no explicit when-not or precondition (e.g., portal must be enabled) to reach the top tier.

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