Skip to main content
Glama
Sign In

Gemmein

by com.gemmein
OverviewDiscussionsAdmin

Ask to take the app live

request_go_live

Asks the founder to take the app live: its Development becomes the public Live app their customers use, on the Gemmein plan named (or the one the account already pays for). Going live is the founder's approval, then their payment for the plan in Stripe's own payment window on the same page (no payment step when buy_plan already paid for it) — payment details never pass through this chat. buy_plan pays for the plan earlier, if they want. Refused when the app is already live (request_promote carries later changes). This is what a founder may call putting it live or making it real. Your human approves it in their browser, then pays for the plan there; no emailed code is asked. Nothing changes until they approve; approving it carries it out — Gemmein does it the moment they press Approve, once, and records what happened on their Logs. The approval page shows Gemmein's own sentence of the real effect, read against Live; a request that no longer matches Live when it is carried out is refused and nothing changes. Returns the approval link for your human and a handle: live_action_status with wait: true answers the moment it is done, or why not — never ask your human to tell you they approved. A second call asks again (a new approval).

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": "request_go_live"
  }
}

Input Schema

NameRequiredDescriptionDefault
noteNoone sentence for your human, shown under Gemmein's own summary
tierNothe plan to take it live on (leave out for the one already paid, or the page's default)
intervalNodefault month; yearly is two months off

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / tier / enum
      Previous value: -[
-  "launch",
-  "live",
-  "growing"
-]New value: +[
+  "launch",
+  "run",
+  "grow"
+]
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Beyond annotations, it discloses the approval-and-payment workflow, that no payment details pass through chat, that nothing changes until approval, that execution happens once on approval and is recorded in Logs, and that stale requests are refused. These details substantially clarify the non-idempotent, open-world behavior implied by the annotations.

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?

The description is front-loaded with the core action and effect, and most of its length is justified by the approval/payment workflow. Some sentences repeat the approval and payment sequence, so it is slightly longer than necessary but not disorganized.

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 the complexity of approval, payment, stale-request refusal, and follow-up polling, the description covers what an agent needs to call and explain the tool. It also describes the return value as an approval link and handle for live_action_status, despite there being no output schema.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents note, tier, and interval. The description adds some useful context about the named plan or already-paid plan, but it does not need to compensate for missing schema information, making 3 the appropriate baseline.

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?

The description states a specific action, taking the app live, and explains the concrete effect: Development becomes the public Live app customers use. It distinguishes this from buy_plan and request_promote, so an agent can identify the tool without opening sibling schemas.

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?

It explicitly names alternatives and conditions: buy_plan pays for the plan earlier if desired, request_promote carries later changes after the app is already live, and a second call starts a new approval. These details tell the agent when this tool applies and when sibling tools are more appropriate.

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

All Gemmein toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources