Skip to main content
Glama
Sign In

Convika

by com.convika
OverviewDiscussionsAdmin

Publish page

publish_site
Destructive

Deploy a landing page to preview or production. ページ公開・デプロイ。

For normal creation/editing, prefer create_preview first so the user can review changes.
- "preview" slot (default): creates a token-protected preview URL without affecting the live version
- "production" slot: makes the page publicly accessible at the assigned primary URL if one exists, otherwise at its path on the workspace's https://<name>.convika.page site (get_brand shows it)

  • Production requires confirmProduction=true and should only be used when the user explicitly asks to publish/go live

  • If versionNumber is omitted, the latest saved version is published

  • Convika handles hosting, CDN, and SSL automatically

  • On Pro, MAX, Enterprise, a production publish also sends the page's URL to IndexNow (Bing and the other engines that take part; Google doesn't take IndexNow). Engines decide when to crawl: don't promise faster indexing or a place in AI answers.

  • The response includes a "warnings" array with preflight checks: missing goals, meta description, OGP tags, or forms. Inform the user of any warnings and offer to fix them (use set_goals for goals, save_page_content for meta tags, create_form for forms).

Input Schema

NameRequiredDescriptionDefault
slotNoDeployment slot. Defaults to 'preview'. 'production' makes the page live and requires confirmProduction=true.preview
siteIdYesThe ID of the page to publish
versionNumberNoVersion number to publish. If omitted, the latest saved version is used.
confirmProductionNoSet true only when the user explicitly asked to publish/go live in production.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / siteId / description
      Previous value: -"The ID of the site to publish"New value: +"The ID of the page to publish"
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations (which only flag destructive/openWorld/not-idempotent) by explaining that preview is token-protected and does not touch the live version, that production makes the page publicly reachable at a specific URL resolution order, that hosting/CDN/SSL are handled, that IndexNow submission occurs on paid plans, and that the response carries a warnings array with preflight checks. It even guards against over-promising indexing outcomes.

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-loaded with the core verb and slot choice, then bulleted for scannability, with the warnings-handling contract last. A couple of bullets (versionNumber default, slot description) duplicate the schema verbatim and could be trimmed, and the bilingual tagline adds no routing value.

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, yet the description sketches the important part of the return (warnings with missing goals/meta/OGP/forms) and routes the agent to set_goals, save_page_content, and create_form to fix them. For a destructive, world-visible action, the preconditions an agent needs before calling are all present.

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; the description still adds meaning by expanding slot semantics (public URL resolution order, get_brand to find the workspace site) and by tying confirmProduction to an explicit user request. versionNumber and confirmProduction restate the schema rather than extend it, keeping this just 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 ('Deploy a landing page') plus the two target slots, so the agent immediately knows this is a deployment action rather than authoring. It explicitly contrasts itself with create_preview for creation/editing, and the unspoken sibling publish_pages is at least distinguishable by singular scope.

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 routing rules: prefer create_preview for normal creation/editing so the user can review, use only when the user explicitly asks to publish/go live, and requires confirmProduction=true for production. Both the when and the when-not are stated, along with the guardrail parameter.

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

All Convika toolsInspect
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