Skip to main content
Glama

publish_app

Idempotent

Publish an app YOU own, on a paid plan: on Free an app stays private and this answers 402 plan_required with the upgrade link. Two ways to publish: "public" gives it a tile in the autario app store on its own shelf (social next to Social 360, public data next to the World Bank and FRED data surfaces), credited to you, plus a public URL, "unlisted" gives it only the URL, so anyone you send the link to can open it and nobody else finds it. Every publish runs a content check first and refuses, naming the rule and the line, an external script, an embedded frame, a form posting elsewhere, a redirect, an advertising or affiliate link, hidden text, or text aimed at AI agents in the name, tagline or manifest. Both unlisted and public then pass ONE AI content review per content version (text and code), synchronously, and both need a shelf first (create_app or update_app_manifest with shelf, else 422 shelf_required with the allowed ids), a public listing needs the app hosted on autario (upload_app_bundle): a block returns the reasons (edit the app and publish again), review_unavailable means try again later. Returns public_url. Viewers read data through autario.js with their own role: a stranger sees public catalog data only, a team member the owner invited to the app (Account > Team) sees the datasets the app declares. Note that a published app is deliberately NOT search-engine indexed; only autario can put a community app into the sitemap. Use it when the user says the app is ready to share. unpublish_app reverses it and is never refused.

Input Schema

NameRequiredDescriptionDefault
app_idYesId of an app you own, as returned by create_app. An app you do not own answers not found.
visibilityNo"public" = listed in the app store. "unlisted" = link only. Default "public".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / app_id / description
      Previous value: -"The app id."New value: +"Id of an app you own, as returned by create_app. An app you do not own answers not found."
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Far exceeds the annotations: it discloses the paid-plan 402 plan_required gate, the per-version synchronous AI content review, the specific content-check refusal classes (external script, embedded frame, form posting, redirect, ad/affiliate link, hidden text, AI-agent-targeted text), the 422 shelf_required error, review_unavailable retry semantics, and that published apps are deliberately not search-indexed.

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?

Front-loads the core action and the plan gate, and every sentence carries substantive information rather than filler. It is very dense and delivered as one long run-on block, which slightly hurts scannability but does not waste words.

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?

No output schema exists, yet the description names the return value (public_url) and covers the failure modes (402, 422, review block, review_unavailable) and viewer data-visibility model. An agent has everything needed to invoke and interpret the result correctly.

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 already 100%, so the schema documents both parameters fully. The description nonetheless adds real value beyond it by spelling out the downstream effects of each visibility value (credited tile, public URL) and the ownership/not-found behavior of app_id.

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 (publish) and resource (an app you own) and immediately distinguishes the two visibility modes with concrete consequences: a tile in the app store vs URL-only. It is clearly separable from siblings like unpublish_app, create_app, and update_app_manifest.

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?

Gives explicit when-to-use ("when the user says the app is ready to share"), preconditions (needs a shelf first via create_app/update_app_manifest; public needs upload_app_bundle hosting), and names the reversing tool (unpublish_app, never refused). Nothing about routing is left to inference.

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