Skip to main content
Glama

Add asset permalinks

add_asset_permalinks

Give assets a permalink: a permanent, PUBLIC URL that needs no login and never expires, unlike the signed display_url, which dies at the end of the next day. Use it when a URL has to keep working — an external site, a deck, a doc, a hand-off to another system. Publishing is the point: the file is copied to a public bucket and anyone holding the URL can fetch it, so a sensitive file becomes public. It serves files, not web pages: an HTML file behind a permalink is sandboxed and its scripts never run, so never use it to host a page or app — deploy_app is for that. The copy runs in the background. This call waits up to about 20 seconds for it and returns the finished URLs under created; anything still copying comes back under pending with no URL. Read those with get_asset_permalinks shortly after — never publish them again; a URL does not work until it is reported there. A large video can take minutes. Assets that already have one are left untouched and are NOT in created — they are listed under already_had_permalink; read their URL with get_asset_permalinks. Assets that all already have one publish nothing and come back listed under already_had_permalink, not as a failure. A permalink only exists for real uploaded files: a link asset, a note, a colour swatch, or an upload still ingesting (is_skeleton: true) is listed under no_file_to_publish and nothing is created — poll get_asset until the upload finishes before asking. failed_to_publish means the file could not be copied at all and the permalink was withdrawn; retrying will not help. Capped per plan (10 Free, 100 on trials, 1,000 Pro, 5,000 Team/Business); going over returns 422 and publishes NOTHING — the whole batch is refused, not the overflow, and the count is taken before the unpublishable assets are skipped, so near the cap send only real files. If the call fails partway, the response still reports what was published or queued plus a remaining list — call again with exactly that list, never with the original one. Send the whole set in one call, up to 200 tokens. The response reports quota after the writes, and list_organizations reports the same headroom without publishing anything, so check it there before a batch you are not sure fits. Requires write scope and update permission on every asset; one unknown token fails the whole call.

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": {
      "asset_tokens": "<asset_tokens>"
    },
    "name": "add_asset_permalinks"
  }
}

Input Schema

NameRequiredDescriptionDefault
asset_tokensYesAsset tokens to give a permalink (max 200 per call). Tokens that already have one are skipped. If the response carries `remaining`, call again with exactly those tokens.
organizationNoWorkspace slug, as returned by list_organizations. Omit it when the account has a single workspace — it is then resolved from your token. Pass it only when the account has several, or when you mean a workspace other than the obvious one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Changed3 schema fields changed
    • addedInput schema / additionalProperties
      Added value: +false
    • removedInput schema / properties / context
      Removed value: -{
      -  "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
      -  "type": "string"
      -}
    • changedInput schema / required
      Previous value: -[
      -  "asset_tokens",
      -  "context"
      -]New value: +[
      +  "asset_tokens"
      +]
  3. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Goes far beyond the annotations: discloses that the file is copied to a PUBLIC bucket (irreversible exposure), that the copy runs in the background with a ~20s wait, the per-plan caps (10/100/1,000/5,000) with a whole-batch 422 refusal, partial-failure `remaining` semantics, and that `write` scope plus per-asset update permission are required. The one soft spot is that `idempotentHint: false` sits slightly oddly against 'assets that already have one are left untouched', but the description clarifies the call is not a no-op re-publish, so this is not a contradiction — just a nuance a reader must reconcile.

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

Conciseness3/5

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

Front-loaded and nearly every sentence carries operational payload, but it is a single ~370-word undifferentiated block for a two-parameter tool. The failure taxonomy (`pending`, `already_had_permalink`, `no_file_to_publish`, `failed_to_publish`) and the quota rules interleave and would be far more scannable as separated structure; density here borders on overload.

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?

For a mutation tool with no output schema, the description fully covers the contract an agent needs: what is created, what is returned under `created` vs `pending`, how each skip/failure bucket behaves, the quota ceiling and its all-or-nothing enforcement, auth/scope requirements, and the correct recovery path after a partial failure. Nothing material is left to inference.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds real operational meaning for `asset_tokens`: send the whole set in one call, up to 200, and on partial failure retry with exactly the `remaining` list, not the original one. The `organization` parameter gets no additional treatment beyond the schema, which keeps this below a 5.

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 ('Give assets a permalink') and immediately defines it as a permanent PUBLIC URL without login, contrasted against the expiring signed `display_url`. It also names what it is not (a page/app host) and points to `deploy_app` for that case, so an agent can distinguish it from siblings like `share_asset`, `get_asset_permalinks`, and `deploy_app` 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 Guidelines5/5

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

Explicit when-to-use ('when a URL has to keep working — an external site, a deck, a doc, a hand-off'), explicit when-not-to-use ('never use it to host a page or app — deploy_app is for that'), and it routes follow-up reading to `get_asset_permalinks` and pre-flight quota checks to `list_organizations`. It even instructs a re-call with the returned `remaining` list rather than the original tokens.

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.

Resources