Skip to main content
Glama

Set public paths

set_public_paths
DestructiveIdempotent

Let anyone open some paths of a restricted spawnpoint project with no sign-in, while the rest of the app stays behind sign-in: a webhook (/webhooks/slack), an OAuth callback that people outside the share list return through (/oauth/callback), or pages for those people (/p/). A callback that only signed-in viewers return through already works and needs no entry. Pass the whole list each time: it replaces the current one, and [] clears it. An entry is an exact path (/webhooks/slack matches only that path) or a folder ending in / (/p/* matches everything under /p/). Matching is exact and case-sensitive. / and /* are refused: to open the whole app, use set_visibility. At most 20 entries. List only the exact paths a sender or a page needs, never a folder that also holds other routes: /api/* opens the whole API. A public page needs its own files' folders listed too (/assets/* for Vite, /_next/static/* for Next.js), or it opens without its scripts and styles. spawnpoint checks no one on these paths, so a webhook route must check the sender's own signature (for example Slack's signing secret). Takes effect on the next request, with no redeploy. Returns each path's url to give the sender. A sleeping app takes about half a minute to wake and a webhook sender may give up first, so open the app before registering a webhook, or keep it awake with set_always_on.

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": {
      "project_id": "<project_id>",
      "paths": "<paths>"
    },
    "name": "set_public_paths"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathsYesthe whole list of paths anyone may open with no sign-in. Each is an exact path such as /webhooks/slack, or a folder ending in /* such as /p/*, which covers everything under /p/. Replaces the current list; [] clears it, so on a restricted project every path needs sign-in again
project_idYesthe id of the project

Output Schema

NameRequiredDescriptionDefault
noteYes
project_idYes
visibilityYes
public_pathsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.9/5.0
Behavior5/5

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

Goes well beyond the annotations: the list is replaced wholesale ([] clears it), the 20-entry cap, matching is exact and case-sensitive, / and /* are refused, changes take effect on the next request with no redeploy, and it returns each path's URL. Crucially it discloses the security consequence the destructiveHint annotation cannot convey — spawnpoint checks no one on these paths, so webhook routes must verify signatures themselves.

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?

Purpose and scope come first, then rules, then operational caveats — well ordered and free of filler. It is a dense single paragraph of considerable length, and the replacement behavior is partly repeated from the schema, so it is slightly over-packed rather than maximally tight.

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?

Given an output schema exists, the description needn't explain return values, yet it still notes URLs are returned for the sender. Combined with annotations (destructive, idempotent, open-world) and 100% schema coverage, nothing an agent needs to call this safely is missing.

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

Parameters5/5

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

Schema coverage is 100% and the paths field already documents replacement and the exact-vs-/* format, yet the description adds matching semantics (exact and case-sensitive), the 20-entry limit, rejection of / and /*, and the caveat that a public page also needs its asset folders (/assets/*, /_next/static/*). That is real added meaning rather than restatement.

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 ('Let anyone open some paths of a restricted spawnpoint project with no sign-in') and immediately scopes it against the app-wide alternative set_visibility. Concrete examples (/webhooks/slack, /oauth/callback, /p/*) make the effect unambiguous versus siblings like share_project or set_storage_visibility.

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

Usage Guidelines5/5

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

Explicitly names when an entry is not needed ('a callback that only signed-in viewers return through already works'), names the alternative for opening the whole app ('use set_visibility'), and warns against over-broad folders ('/api/* opens the whole API'). It also gives operational guidance (open the app before registering a webhook; keep it awake with set_always_on).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.