Skip to main content
Glama
gbatistuta0

AppFactory

by gbatistuta0
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

RevenueCat Setup

revenuecat_setup
DestructiveIdempotent

Sets up a RevenueCat v2 project idempotently: creates premium entitlement, subscription attachments, SDK key, and Supabase secret, with human approval for live writes.

Instructions

Idempotently set up the RevenueCat v2 project: premium entitlement, subscription attachments, SDK key and Supabase secret (live write, needs human approval).

Use when: after a human created the RC project, linked ASC and supplied the v2 key. Returns NEEDS_HUMAN if no project exists. For ASC plus RC in one pass use store_setup. Returns: {ok, entitlement, sdk_key_set, secrets} or an approval_required refusal.

Input Schema

NameRequiredDescriptionDefault
v2_keyYesRevenueCat secret API v2 key (sk_...); used for this call only.
bundle_idYesApp bundle identifier in reverse-DNS form, e.g. com.example.app.
env_suffixNoSuffix for secret names when several apps share one Supabase project, e.g. '_MYAPP'.
approval_idNoApproval id from a previous approval_required refusal; omit on the first call. The human approves out-of-band with `appfactory approve <id>`, then call again with the same arguments and this id.
set_secretsNoIf true (default) also write the RevenueCat secrets to Supabase.
supabase_refYesSupabase project ref that receives the RevenueCat secrets.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.1.5
    • addedInput schema / properties / approval_id / description
      Added value: +"Approval id from a previous approval_required refusal; omit on the first call. The human approves out-of-band with `appfactory approve <id>`, then call again with the same arguments and this id."
    • addedInput schema / properties / bundle_id / description
      Added value: +"App bundle identifier in reverse-DNS form, e.g. com.example.app."
    • addedInput schema / properties / env_suffix / description
      Added value: +"Suffix for secret names when several apps share one Supabase project, e.g. '_MYAPP'."
    • addedInput schema / properties / set_secrets / description
      Added value: +"If true (default) also write the RevenueCat secrets to Supabase."
    • addedInput schema / properties / supabase_ref / description
      Added value: +"Supabase project ref that receives the RevenueCat secrets."
    • addedInput schema / properties / v2_key / description
      Added value: +"RevenueCat secret API v2 key (sk_...); used for this call only."
  2. First observedv0.1.1

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare destructive/idempotent/openWorld, but the description adds context they cannot carry: the live-write nature requiring human approval, the approval_required refusal path, and the NEEDS_HUMAN outcome when no project exists. This meaningfully de-risks a mutation tool.

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

Conciseness5/5

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

Three short, labeled blocks (action / Use when / Returns) with the live-write warning front-loaded in the first sentence. Every clause carries information; no filler.

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 multi-system, approval-gated idempotent write, the description covers prerequisites, failure modes, the approval loop, and the alternative tool, while the output schema handles return-value detail. An agent has everything needed to call it correctly.

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 all six parameters are already documented in the schema, including the approval_id workflow and env_suffix semantics. The description adds no per-parameter detail beyond naming the SDK key and Supabase secret in prose, so baseline 3 applies.

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 ('set up the RevenueCat v2 project') and enumerates the concrete artifacts it creates: premium entitlement, subscription attachments, SDK key, and Supabase secret. It also names the sibling it is not (store_setup), so an agent can distinguish it without opening either 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 'Use when:' precondition (human already created the RC project, linked ASC, supplied v2 key), an explicit failure mode ('Returns NEEDS_HUMAN if no project exists'), and a named alternative ('For ASC plus RC in one pass use store_setup'). Nothing 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.

Deploy Server

Other Tools