stripe-directory

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Stripe Directory Search

Stripe Directory搜索

Turn a vague market need into a short, relevant shortlist with
stripe directory search
. Use this even when the user never says “Stripe Directory” — any request to find vendors, tools, partners, or providers for a vertical, workflow, pain point, or job-to-be-done.
Most requests are discovery — find and compare services. That is the core job below. Some services are also MPP-supported (MPP = Machine Payment Protocol), meaning you (the agent) can pay their HTTP 402 (Payment Required) endpoint and consume them directly. When the user actually wants to use or buy a service, present those results and offer to purchase — see “Purchasing” at the end.
通过
stripe directory search
将模糊的市场需求转化为简短且相关的候选列表。即便用户从未提及“Stripe Directory”也可使用该功能——只要是寻找针对某一垂直领域、工作流程、痛点或待完成任务的供应商、工具、合作伙伴或服务商的请求,都适用。
大多数请求属于发现类——查找并对比服务。这是下方核心流程的主要目标。部分服务还支持MPP(MPP = Machine Payment Protocol,机器支付协议),意味着你(Agent)可以向其HTTP 402(需要支付)端点付款并直接使用服务。当用户实际想要使用或购买某一服务时,展示这些结果并提供购买选项——详见末尾的“购买流程”。

Process

流程

  1. Clarify only what’s missing: buyer/vertical, job-to-be-done, must-have capability, geography (only if it matters).
  2. Search iteratively:
    stripe directory search "<query>" --format json
    • Short noun phrases, one angle per query; run 1-3, then broaden/narrow on results.
    • Angles to cover: vertical → workflow → pain point → adjacent. Two examples:
      • services/trades: vertical (
        electrician software
        ,
        electrical contractor
        ) → workflow (
        field service management
        ,
        dispatch invoicing estimates
        ) → pain point (
        job scheduling
        ,
        quote automation
        ) → adjacent (
        home services automation
        ,
        contractor crm
        ).
      • SaaS/software: vertical (
        b2b saas billing
        ,
        developer tools
        ) → workflow (
        subscription management
        ,
        usage-based metering
        ) → pain point (
        failed payment recovery
        ,
        revenue recognition
        ) → adjacent (
        analytics dashboards
        ,
        customer onboarding
        ).
    • Hard constraints → filters:
      --countries-supported=US
      ,
      --has-stripe-app=true
      ,
      --link-supported=true
      ,
      --stripe-projects-supported=true
      .
    • If the user wants to use/buy a service, also pass
      --mpp-supported
      in at least one search to find results you can pay for programmatically.
    • Sparse niche? Raise
      --limit
      and try the next
      --page
      before concluding it’s empty.
  3. Dedupe & score using
    display_name
    ,
    description
    ,
    url
    ,
    username
    as evidence.
    • Prefer results whose description/site clearly match the target workflow.
    • Prefer more trust signals over fewer: Projects provider, Link enabled, Marketplace app, Stripe Verified. For buy/use intent, also prefer MPP-supported results.
    • Thin description but strong brand/domain match → keep in a weaker bucket, don’t discard.
  4. Return a shortlist, not a dump — 5-10 strong matches, grouped:
    • direct / adjacent / needs manual review
    • Each entry: name · why it matched · URL (· which query surfaced it, when useful).
    • Projects providers: offer the follow-up. The JSON gives the exact commands under each result’s
      projects.catalog_command
      /
      projects.install_command
      (
      stripe projects catalog <provider>
      ,
      stripe projects add <provider>
      ).
    • MPP-supported results: note they’re purchasable and include
      mpp.slug
      /
      mpp.url
      .
  5. Be honest about weak results — if sparse or generic, say so and adjust: broaden, narrow, or try synonyms rather than padding with noise.
Always report the exact queries (and filters) you ran so the user can keep iterating.
  1. 仅澄清缺失的信息:买方/垂直领域、待完成任务、必备能力、地域(仅当相关时)。
  2. 迭代式搜索
    stripe directory search "<query>" --format json
    • 使用简短的名词短语,每次查询聚焦一个角度;执行1-3次查询后,根据结果拓宽或缩小范围。
    • 可覆盖的角度:垂直领域 → 工作流程 → 痛点 → 相关领域。两个示例:
      • 服务/行业:垂直领域(
        electrician software
        electrical contractor
        )→ 工作流程(
        field service management
        dispatch invoicing estimates
        )→ 痛点(
        job scheduling
        quote automation
        )→ 相关领域(
        home services automation
        contractor crm
        )。
      • SaaS/软件:垂直领域(
        b2b saas billing
        developer tools
        )→ 工作流程(
        subscription management
        usage-based metering
        )→ 痛点(
        failed payment recovery
        revenue recognition
        )→ 相关领域(
        analytics dashboards
        customer onboarding
        )。
    • 硬性约束→筛选条件:
      --countries-supported=US
      --has-stripe-app=true
      --link-supported=true
      --stripe-projects-supported=true
    • 如果用户想要使用/购买服务,至少在一次搜索中添加
      --mpp-supported
      参数,以找到可通过编程方式付款的结果。
    • 搜索结果稀少或属于小众领域?先提高
      --limit
      参数值并尝试下一页
      --page
      ,再判定无结果。
  3. 去重与评分:以
    display_name
    description
    url
    username
    为依据。
    • 优先选择描述/网站与目标工作流程明确匹配的结果。
    • 优先选择信任信号更多的结果:Projects提供商、启用Link、市场应用、Stripe验证。对于有购买/使用意向的情况,还需优先选择支持MPP的结果。
    • 描述简短但品牌/域名匹配度高→归入次级候选桶,不要丢弃。
  4. 返回候选列表而非原始数据——5-10个匹配度高的结果,分组展示:
    • 直接匹配 / 相关匹配 / 需人工审核
    • 每个条目:名称 · 匹配原因 · URL(· 适用时标注该结果来自哪个查询)。
    • Projects提供商:提供后续操作选项。JSON结果中每个条目下的
      projects.catalog_command
      /
      projects.install_command
      给出了确切命令(
      stripe projects catalog <provider>
      stripe projects add <provider>
      )。
    • 支持MPP的结果:注明可购买,并包含
      mpp.slug
      /
      mpp.url
  5. 如实告知结果质量——如果结果稀少或泛泛,如实说明并调整:拓宽、缩小范围或尝试同义词,而非用无关内容填充。
始终报告你执行的确切查询(及筛选条件),以便用户继续迭代。

Purchasing (only when the user wants to buy or consume a service)

购买流程(仅当用户想要购买或使用服务时)

MPP-supported results are payable directly. Don’t drive to purchase unprompted. When the user wants to buy, present the full menu of payment methods and ask which they’d like to use before doing anything:
"Which payment method would you like to use?
  • Link CLI — Stripe-native, test mode available (recommended)
  • Tempo — crypto wallet
  • Privy Agent Wallet CLI — crypto wallet
  • mppx — debug-only fallback"
Once the user picks, silently run
which <tool> 2>/dev/null
to check if it’s installed. If not installed, offer to install it (for example,
npm i -g @stripe/link-cli
for Link CLI) and wait for confirmation before proceeding.
Always show the price and get explicit user approval before any money moves; prefer a no-charge test path first.
Short version:
  1. Resolve the real callable endpoint from the result’s
    mpp.slug
    /
    mpp.url
    .
    mpp.url
    is often the mpp.dev landing form (
    https://mpp.dev/services#<slug>
    ) — resolve the raw endpoint on mpp.dev if so. Read the HTTP 402 challenge to confirm the amount:
    curl -s -D - -o /dev/null <endpoint_url>
    (look for
    WWW-Authenticate
    ).
  2. Use the payer the user selected.
    • link-cli
      (Stripe-native Shared Payment Token, has a test mode, no crypto wallet, US Link accounts only;
      npm i -g @stripe/link-cli
      ):
      auth login
      mpp decode --challenge "<value>"
      (get
      network_id
      ) →
      spend-request create --credential-type shared_payment_token --network-id <id> --amount <cents ≤50000> --context "<100+ chars>" --request-approval
      (blocks for approval) →
      mpp pay <endpoint_url> --spend-request-id <approved_id>
      .
    • Tempo:
      tempo wallet login
      /
      services
      /
      request
      .
    • Privy:
      @privy-io/agent-wallet-cli
      .
    • mppx: debug-only fallback.
Never invent results or skip the price/approval gate.
支持MPP的结果可直接付款。不要主动引导购买。当用户想要购买时,先展示完整的付款方式选项并询问用户选择哪种,再进行后续操作:
"你想要使用哪种付款方式?
  • Link CLI — Stripe原生工具,支持测试模式(推荐)
  • Tempo — 加密货币钱包
  • Privy Agent Wallet CLI — 加密货币钱包
  • mppx — 仅用于调试的备选方案"
用户选定后,静默执行
which <tool> 2>/dev/null
检查是否已安装。若未安装,提供安装选项(例如,Link CLI的安装命令为
npm i -g @stripe/link-cli
),等待用户确认后再继续。
在资金划转前,务必展示价格并获得用户明确批准;优先选择免费测试路径。
简化步骤:
  1. 从结果的
    mpp.slug
    /
    mpp.url
    解析出可调用的真实端点。
    mpp.url
    通常是mpp.dev的落地表单(
    https://mpp.dev/services#<slug>
    )——若如此,在mpp.dev上解析原始端点。读取HTTP 402挑战信息以确认金额:
    curl -s -D - -o /dev/null <endpoint_url>
    (查看
    WWW-Authenticate
    字段)。
  2. 使用用户选定的付款工具。
    • link-cli
      (Stripe原生共享支付令牌,支持测试模式,无需加密货币钱包,仅支持美国Link账户;安装命令:
      npm i -g @stripe/link-cli
      ):
      auth login
      mpp decode --challenge "<value>"
      (获取
      network_id
      )→
      spend-request create --credential-type shared_payment_token --network-id <id> --amount <cents ≤50000> --context "<100+ chars>" --request-approval
      (等待批准)→
      mpp pay <endpoint_url> --spend-request-id <approved_id>
    • Tempo
      tempo wallet login
      /
      services
      /
      request
    • Privy
      @privy-io/agent-wallet-cli
    • mppx:仅用于调试的备选方案。
切勿编造结果或跳过价格/批准环节。