Skip to main content
Glama

SaSame MCP Observatory + Gold Rush Town

factory_start

Start the real SaSame MCP Factory lifecycle from one of seven canonical creator entry types. During Capability Control Beta, free listing, guided build, repair and monitoring entries can start without a payment method; endpoint_url is required only for live_entry/underperforming_entry/monitoring_entry and can be supplied later for guided builds. New paid membership checkout is disabled in beta, while existing subscriber continuity remains preserved. If checkout is re-enabled in the future, guided/underperforming entries return to the account-level membership gate. No checkout is created at start; a redirect never grants access.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
entry_typeNoWhere this creator enters the one Factory lifecycle; defaults to live_entry for backward compatibility
journey_idNoAlias for entry_type. If both are supplied they must match; disagreement fails closed
buyer_emailNoOnly needed for a fixture/legacy activation checkout journey; membership/free journeys bill at the account level and never bind an email
endpoint_urlNoPublic MCP endpoint owned/operated by the creator. REQUIRED for live_entry/underperforming_entry/monitoring_entry; OPTIONAL for the four guided-build journeys (provide it later via factory_provide_endpoint)
principal_idNov2 principal binding; optional during free beta and used to preserve private account/lifecycle status. Required only when future membership gating is re-enabled for guided/underperforming journeys.
principal_keyNov2 principal binding; optional during free beta and used to preserve private account/lifecycle status. Required only when future membership gating is re-enabled for guided/underperforming journeys.
organization_idNov2 principal binding; legacy identity fields remain accepted
creator_identityYesStable creator reference; SaSame persists only its SHA-256 hash
verification_modeNoUse sasame_self_test_fixture only for SaSame's own synthetic release verification; it is excluded from demand/revenue KPIs
ownership_proof_urlNoSame-origin URL that will serve the returned ownership_proof_body; defaults to /.well-known/sasame-factory-claim.txt
analytics_correlation_idNoOptional opaque journey token generated by the caller. SaSame stores only its SHA-256 hash and uses it to correlate Web/MCP/Factory/checkout/fulfillment analytics; never put email, URL, credentials or personal data here.
self_test_capability_tokenNoRequired alongside self_test_free_distribution: a release-bound, single-use, short-lived token signed with SaSame's trust key. Mint with scripts/factory/mint-self-test-capability.mjs (VPS-only). Unrelated to any other argument; omitting it while self_test_free_distribution=true fails closed.
self_test_free_distributionNoSaSame-internal only: requires verification_mode=sasame_self_test_fixture AND a valid self_test_capability_token. Completes the full lifecycle (through DISTRIBUTION) with zero Stripe interaction and never touches the real public shelf — the receipt is stamped shelf=sasame_internal_self_test / plan_context=self_test_no_charge / north_star_counted=false so it can never be mistaken for a real listing. External creators cannot use this to skip payment; it throws for any non-fixture traffic or without a valid token.
stripe_live_payment_acknowledgedNoDeprecated compatibility field. factory_start never charges, and public Activation checkout creation is closed.

Schema Changelog

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

  1. Changed2 schema fields changed
    • changedInput schema / properties / principal_id / description
      Previous value: -"v2 principal binding; required for the membership-gated guided/underperforming journeys"New value: +"v2 principal binding; optional during free beta and used to preserve private account/lifecycle status. Required only when future membership gating is re-enabled for guided/underperforming journeys."
    • changedInput schema / properties / principal_key / description
      Previous value: -"v2 principal binding; required for the membership-gated guided/underperforming journeys"New value: +"v2 principal binding; optional during free beta and used to preserve private account/lifecycle status. Required only when future membership gating is re-enabled for guided/underperforming journeys."
  2. 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"
  3. Changed2 schema fields changed
    • addedInput schema / properties / analytics_correlation_id
      Added value: +{
      +  "description": "Optional opaque journey token generated by the caller. SaSame stores only its SHA-256 hash and uses it to correlate Web/MCP/Factory/checkout/fulfillment analytics; never put email, URL, credentials or personal data here.",
      +  "maxLength": 160,
      +  "minLength": 8,
      +  "pattern": "^[A-Za-z0-9._:-]+$",
      +  "type": "string"
      +}
    • changedInput schema / properties / stripe_live_payment_acknowledged / description
      Previous value: -"Optional acknowledgement that, IF a later factory_checkout is used for a fixture/legacy activation lifecycle, completing that Checkout charges REAL money via Stripe LIVE mode. factory_start itself never charges."New value: +"Deprecated compatibility field. factory_start never charges, and public Activation checkout creation is closed."
  4. Changed2 schema fields changed
    • addedInput schema / properties / self_test_capability_token
      Added value: +{
      +  "description": "Required alongside self_test_free_distribution: a release-bound, single-use, short-lived token signed with SaSame's trust key. Mint with scripts/factory/mint-self-test-capability.mjs (VPS-only). Unrelated to any other argument; omitting it while self_test_free_distribution=true fails closed.",
      +  "type": "string"
      +}
    • changedInput schema / properties / self_test_free_distribution / description
      Previous value: -"SaSame-internal only: requires verification_mode=sasame_self_test_fixture. Completes the full lifecycle (through DISTRIBUTION) with zero Stripe interaction and never touches the real public shelf — the receipt is stamped shelf=sasame_internal_self_test / plan_context=self_test_no_charge / north_star_counted=false so it can never be mistaken for a real listing. External creators cannot use this to skip payment; it throws for any non-fixture traffic."New value: +"SaSame-internal only: requires verification_mode=sasame_self_test_fixture AND a valid self_test_capability_token. Completes the full lifecycle (through DISTRIBUTION) with zero Stripe interaction and never touches the real public shelf — the receipt is stamped shelf=sasame_internal_self_test / plan_context=self_test_no_charge / north_star_counted=false so it can never be mistaken for a real listing. External creators cannot use this to skip payment; it throws for any non-fixture traffic or without a valid token."
  5. Changed1 schema field changed
    • addedInput schema / properties / self_test_free_distribution
      Added value: +{
      +  "description": "SaSame-internal only: requires verification_mode=sasame_self_test_fixture. Completes the full lifecycle (through DISTRIBUTION) with zero Stripe interaction and never touches the real public shelf — the receipt is stamped shelf=sasame_internal_self_test / plan_context=self_test_no_charge / north_star_counted=false so it can never be mistaken for a real listing. External creators cannot use this to skip payment; it throws for any non-fixture traffic.",
      +  "type": "boolean"
      +}
  6. Changed7 schema fields changed
    • changedInput schema / properties / buyer_email / description
      Previous value: -"Stripe live buyer email; SaSame persists only its SHA-256 binding"New value: +"Only needed for a fixture/legacy activation checkout journey; membership/free journeys bill at the account level and never bind an email"
    • changedInput schema / properties / endpoint_url / description
      Previous value: -"Public MCP endpoint owned or operated by the creator; currently required for real inspection, claim and Stripe LIVE fulfillment in every entry type"New value: +"Public MCP endpoint owned/operated by the creator. REQUIRED for live_entry/underperforming_entry/monitoring_entry; OPTIONAL for the four guided-build journeys (provide it later via factory_provide_endpoint)"
    • addedInput schema / properties / organization_id
      Added value: +{
      +  "description": "v2 principal binding; legacy identity fields remain accepted",
      +  "minLength": 8,
      +  "type": "string"
      +}
    • addedInput schema / properties / principal_id
      Added value: +{
      +  "description": "v2 principal binding; required for the membership-gated guided/underperforming journeys",
      +  "minLength": 8,
      +  "type": "string"
      +}
    • addedInput schema / properties / principal_key
      Added value: +{
      +  "description": "v2 principal binding; required for the membership-gated guided/underperforming journeys",
      +  "minLength": 32,
      +  "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. Reading tools never charges."New value: +"Optional acknowledgement that, IF a later factory_checkout is used for a fixture/legacy activation lifecycle, completing that Checkout charges REAL money via Stripe LIVE mode. factory_start itself never charges."
    • changedInput schema / required
      Previous value: -[
      -  "endpoint_url",
      -  "creator_identity",
      -  "buyer_email",
      -  "stripe_live_payment_acknowledged"
      -]New value: +[
      +  "creator_identity"
      +]
  7. Changed5 schema fields changed
    • changedInput schema / properties / buyer_email / description
      Previous value: -"Stripe test buyer email; SaSame persists only its SHA-256 binding"New value: +"Stripe live buyer email; SaSame persists only its SHA-256 binding"
    • changedInput schema / properties / endpoint_url / description
      Previous value: -"Public MCP endpoint owned or operated by the creator; currently required for real inspection, claim and Stripe TEST fulfillment in every entry type"New value: +"Public MCP endpoint owned or operated by the creator; currently required for real inspection, claim and Stripe LIVE fulfillment in every entry type"
    • addedInput schema / properties / stripe_live_payment_acknowledged
      Added value: +{
      +  "const": true,
      +  "description": "Required acknowledgement that completing the returned Checkout charges REAL money via Stripe LIVE mode at the owner-set activation price. Reading tools never charges.",
      +  "type": "boolean"
      +}
    • removedInput schema / properties / stripe_test_only_acknowledged
      Removed value: -{
      -  "const": true,
      -  "description": "Required acknowledgement that this conveyor accepts Stripe test-mode payment only",
      -  "type": "boolean"
      -}
    • changedInput schema / required
      Previous value: -[
      -  "endpoint_url",
      -  "creator_identity",
      -  "buyer_email",
      -  "stripe_test_only_acknowledged"
      -]New value: +[
      +  "endpoint_url",
      +  "creator_identity",
      +  "buyer_email",
      +  "stripe_live_payment_acknowledged"
      +]
  8. Changed3 schema fields changed
    • changedInput schema / properties / endpoint_url / description
      Previous value: -"Public MCP endpoint owned or operated by the creator"New value: +"Public MCP endpoint owned or operated by the creator; currently required for real inspection, claim and Stripe TEST fulfillment in every entry type"
    • addedInput schema / properties / entry_type
      Added value: +{
      +  "description": "Where this creator enters the one Factory lifecycle; defaults to live_entry for backward compatibility",
      +  "enum": [
      +    "idea_entry",
      +    "blueprint_entry",
      +    "building_entry",
      +    "ready_entry",
      +    "live_entry",
      +    "underperforming_entry",
      +    "monitoring_entry"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / journey_id
      Added value: +{
      +  "description": "Alias for entry_type. If both are supplied they must match; disagreement fails closed",
      +  "enum": [
      +    "idea_entry",
      +    "blueprint_entry",
      +    "building_entry",
      +    "ready_entry",
      +    "live_entry",
      +    "underperforming_entry",
      +    "monitoring_entry"
      +  ],
      +  "type": "string"
      +}
  9. Added

TDQS

A4/5.0
Behavior4/5

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

Annotations provide only idempotentHint=false and openWorldHint=true, while the description carries the heavier burden: it discloses the beta payment gating rule(s), the fact that this starts a real (non-simulated) lifecycle, that it never creates a checkout, that a redirect does not grant access, and that subscriber continuity is preserved. This includes the key side-effect boundary (no auth in a beta, but endpoint_url becomes both live/maintenance) — all beyond what hints convey. The only missing bit is what a successful call hands back, which is behaviorally significant for an openWorld tool but not a full gap given the 100% parameter coverage. No contradiction with the annotations found.

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 purpose sentence is front-loaded and the remaining three sentences are each utilitarian, covering payment requirements/costs, membership-gate transitions and the redirect guarantees. It is dense rather than verbose — every sentence earns its slot, though the second sentence strings together beta + payment + endpoint_url + guided-build caveats into one long stretch. The wall of text could be split for readability, but no sentence is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 14 parameters, a single required field, and no output schema, the description explains the most confusing surrounding context (beta payment rules, which journeys require endpoint_url, future-gating branch, self-test fixture leaving) and the schema covers every parameter. However, the no-output-schema constraint means the description needed to say at least roughly what the call produces or what happens after success, but never does — it only states a redirect does not grant access. So for a tool of real complexity it is largely complete on input and behavior but incomplete on its response/result contract.

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 coverage is 100% and the input schema already documents every parameter in detail, including which entry types demand endpoint_url and the internal-only/fails-closed nature of self_test_free_distribution. The description adds only a small amount of usage-level clarification (e.g., endpoint_url can be delivered later; the gating applies to specific journeys) that mostly just paraphrases the schema text. Baseline 3 is correct since the description does not misfire but also does not compensate or add net-new semantic meaning over the schema.

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?

Opens with a specific verb+resource: 'Start the real SaSame MCP Factory lifecycle from one of seven canonical creator entry types.' The explicit negative contracts ('No checkout is created at start; a redirect never grants access') clearly separate it from the checkout siblings (factory_checkout, factory_membership_checkout, factory_membership_status, factory_health, factory_station...), while the 7 entry types pin down what makes this tool the lifecycle starter rather than e.g. the generic factory_resolve_dead_letter. Both the description and the annotation title ('Start a Factory conveyor lifecycle') agree on the same verb.

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

Usage Guidelines4/5

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

Provides concrete call conditions: during beta, no payment method is needed for four journey types, and endpoint_url is required only for live/underperforming/monitoring entries and 'can be supplied later for guided builds' (explicitly naming factory_provide_endpoint as the later mechanism). It explains the timeline (paid checkout disabled now, existing subscribers preserved, future re-enabling reverts to account-level gate) and the boundary that this tool never grants access. It does not explicitly name a sibling to use instead when a real purchase/checkout is needed, which costs a point when an alternative is strictly expected.

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.

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.