Skip to main content
Glama

SaSame MCP Observatory + Gold Rush Town

by online.sasame

factory_membership_checkout

Idempotent

New paid Factory membership checkout is disabled during Capability Control Beta. This compatibility tool returns NEW_MEMBERSHIP_CHECKOUT_DISABLED without creating a Stripe object; existing subscriber renewals, webhooks, entitlement and status rails remain supported.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
plan_idYesfactory / factory_pro / factory_team
offer_refNoOptional, required together with mission_id: the specific Mission offer this checkout is claimed to fulfill. Same no-authority-by-itself rule as mission_id.
mission_idNoOptional: attribute this checkout to a Mission offer (Project Pancho, #2837). Carried into Stripe metadata as-is; grants NO authority by itself — only an exact match against SaSame's own durable, selection-proof-validated Mission offer lineage ever counts as real Mission fitness/North-Star evidence. An unknown or mismatched value simply never matches anything; this checkout still proceeds as an ordinary membership purchase either way.
variant_idNoOptional: the specific Mission variant this checkout is claimed to fulfill. Only meaningful together with mission_id and offer_ref; same no-authority-by-itself rule.
principal_idYes
principal_keyYes
affiliate_referral_idNoOptional (#3370): carries the referring agent's referral_id into Stripe metadata as-is, exactly like mission_id/offer_ref above — grants NO authority by itself. Factory account plans are EUR Stripe purchases, which packages/affiliate-settlement's receipt.mjs never accepts as a commission-qualifying receipt (USDC-only by design); this tag exists for durable attribution/audit only, never to mint a commission from a EUR receipt.
analytics_correlation_idNoOptional opaque journey token; only its SHA-256 hash is stored for cross-channel analytics.
stripe_live_payment_acknowledgedNoCompatibility field only. Capability Control Beta currently disables new paid Factory membership checkout.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed2 schema fields changed
    • changedInput schema / properties / stripe_live_payment_acknowledged / description
      Previous value: -"Required acknowledgement that completing the returned Factory membership Checkout charges real money via Stripe LIVE mode at the selected LIVE plan price."New value: +"Compatibility field only. Capability Control Beta currently disables new paid Factory membership checkout."
    • changedInput schema / required
      Previous value: -[
-  "principal_id",
-  "principal_key",
-  "plan_id",
-  "stripe_live_payment_acknowledged"
-]New value: +[
+  "principal_id",
+  "principal_key",
+  "plan_id"
+]
  2. Changed1 schema field changed
    • addedInput schema / properties / affiliate_referral_id
      Added value: +{
+  "description": "Optional (#3370): carries the referring agent's referral_id into Stripe metadata as-is, exactly like mission_id/offer_ref above — grants NO authority by itself. Factory account plans are EUR Stripe purchases, which packages/affiliate-settlement's receipt.mjs never accepts as a commission-qualifying receipt (USDC-only by design); this tag exists for durable attribution/audit only, never to mint a commission from a EUR receipt.",
+  "pattern": "^sasame-aff-[a-f0-9]{16}$",
+  "type": "string"
+}
  3. Changed3 schema fields changed
    • addedInput schema / properties / mission_id
      Added value: +{
+  "description": "Optional: attribute this checkout to a Mission offer (Project Pancho, #2837). Carried into Stripe metadata as-is; grants NO authority by itself — only an exact match against SaSame's own durable, selection-proof-validated Mission offer lineage ever counts as real Mission fitness/North-Star evidence. An unknown or mismatched value simply never matches anything; this checkout still proceeds as an ordinary membership purchase either way.",
+  "maxLength": 120,
+  "minLength": 4,
+  "pattern": "^[A-Za-z0-9._:-]+$",
+  "type": "string"
+}
    • addedInput schema / properties / offer_ref
      Added value: +{
+  "description": "Optional, required together with mission_id: the specific Mission offer this checkout is claimed to fulfill. Same no-authority-by-itself rule as mission_id.",
+  "maxLength": 120,
+  "minLength": 1,
+  "pattern": "^[A-Za-z0-9._:-]+$",
+  "type": "string"
+}
    • addedInput schema / properties / variant_id
      Added value: +{
+  "description": "Optional: the specific Mission variant this checkout is claimed to fulfill. Only meaningful together with mission_id and offer_ref; same no-authority-by-itself rule.",
+  "maxLength": 120,
+  "minLength": 1,
+  "pattern": "^[A-Za-z0-9._:-]+$",
+  "type": "string"
+}
  4. Changed1 schema field changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  5. Changed2 schema fields changed
    • addedInput schema / properties / analytics_correlation_id
      Added value: +{
+  "description": "Optional opaque journey token; only its SHA-256 hash is stored for cross-channel analytics.",
+  "maxLength": 160,
+  "minLength": 8,
+  "pattern": "^[A-Za-z0-9._:-]+$",
+  "type": "string"
+}
    • changedInput schema / properties / stripe_live_payment_acknowledged / description
      Previous value: -"Required acknowledgement that completing the returned Checkout charges REAL money via Stripe LIVE mode at the owner-set activation price."New value: +"Required acknowledgement that completing the returned Factory membership Checkout charges real money via Stripe LIVE mode at the selected LIVE plan price."
  6. Added

TDQS

A3.5/5.0
Behavior1/5

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

Description says the tool returns NEW_MEMBERSHIP_CHECKOUT_DISABLED and does not create a Stripe object. The annotation's title says 'Create a Factory membership Stripe Checkout' and readOnlyHint: false, which strongly implies a real mutation. This is a direct contradiction between description and annotation, and the contradiction cannot be resolved by the reader.

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?

Two sentences contain the disabled status, the exact returned code, the lack of side effects, and the surviving rails. There is no filler, repetition, or unnecessarily long taxonomy phrasing. The structure front-loads the most important behavioral constraint first.

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?

The description is complete for the operation as it currently stands: it tells the agent the tool will always return the disabled code, will not create anything, and what still works. Since the tool never actually creates an object in this Beta, the description does not need to explain Stripe-specific side effects or output formatting beyond the exact status string it provides.

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?

The tool description adds no parameter-level guidance, but the input schema descriptions are already unusually rich and detailed for most of the 9 parameters, covering regex patterns and security-sensitive semantics like no-authority-by-itself and metadata-only attribution. With roughly 78% schema coverage, the description does not need to duplicate what the schema already explains.

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 uses a specific verb (returns) with an explicit, exact result value (NEW_MEMBERSHIP_CHECKOUT_DISABLED) and a concrete resource scope (new paid Factory membership checkout). It clearly differentiates this stub from factory_checkout and factory_membership_status by stating that it does not create a Stripe object during Capability Control Beta.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description implies its intended use: it is the compatibility path for new paid Factory membership checkout calls during the Beta. It does not explicitly list alternative tools, state when-not-to-use, or provide a decision rule about renewals versus new subscriptions beyond saying existing rails 'remain supported.' Some guidance is implied but not made explicit.

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

All SaSame MCP Observatory + Gold Rush Town toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.1/5.0
Disambiguation2/5

With 94 tools spanning overlapping concepts (multiple readiness/audit/grade tools, many status checkers, deprecated aliases like trust_* vs observation_*), agents will frequently struggle to pick the right one. While each tool is individually distinct, the sheer volume and conceptual overlap (e.g., audit_mcp, readiness_report, verify_mcp_ready, lookup_readiness, recommend_mcp, subscribe_grade_changes) create high misselection risk.

Naming Consistency3/5

Most tools use snake_case with underscores, but the pattern is inconsistent: some are verb-first (audit_mcp, verify_mcp_ready, claim_start, check_engagement) while others are noun-first (receipt_issue, meter_open, work_order_open, agent_invoice_status). Deprecated aliases like trust_compare vs observation_compare further break consistency, though the majority remain readable.

Tool Count1/5

94 tools is far beyond any reasonable scope for a single server, even one with broad ambitions like 'observatory + town'. The calibration notes 50+ as extreme mismatch; this server far exceeds that. Many tools are highly specific (e.g., factory_resolve_dead_letter, visit_touch_status, start_here) and could be consolidated or split into separate servers.

Completeness3/5

The server covers a wide range of domains (auditing, claiming, receipts, meters, escrow, work orders, gold rush, town, analytics) and offers many CRUD-like operations, but several lifecycle gaps exist: no cancel/close for work orders (only open/accept/deliver/accept_delivery), escrow (only open/attest/status), or meters (only open/charge/status). Given the massive scope, important operations are missing, though core workflows are present.

Resources