Add your tools to Captain

Help me add Captain tools to this repository, a fork of https://github.com/chatwoot/tools.

Start by asking me which service the tools should support and which GitHub username or organization to credit as the author. Do not make any files or assumptions until I answer.

Before writing files, inspect the service's official API documentation and the existing folders in this repository. Do not invent endpoints, authentication fields, parameters, or response behavior.

Create one short, lowercase, URL-safe folder at the repository root named after the service, for example stripe. It must not already exist. The folder contains:
- toolset.yml: the strict Captain manifest
- README.md: setup instructions, required permissions, and a concise description of every tool

Follow this manifest contract:
- The schema is implicitly v1. Do not add schema_version or toolset_version.
- Set version to a semantic release version such as 1.0.0.
- Set kind to exactly captain_toolset.
- Set author to the GitHub username or organization I gave you, without the @. It must be an existing GitHub account.
- Include name, description, and 1–50 tools. inputs and secrets are optional maps.
- Choose one category using its exact spelling: Commerce, Payments & billing, Shipping, CRM, Engineering & status, Scheduling, Business data & research, Identity & access, Marketing, Others. Omitted category defaults to Others; custom values and lists are rejected.
- Use inputs for non-sensitive configuration and secrets for credentials.
- Optional top-level headers apply to every tool. Use fixed string values only, with no credentials, control characters, or placeholders. Quote date-like YAML values, for example x-api-version: '2026-05-01'.
- Tool IDs must be stable snake_case matching ^[a-z][a-z0-9_]*$.
- Every tool needs id, title, description, http_method, endpoint_url, and auth_type.
- http_method must be GET, POST, PUT, PATCH, or DELETE.
- Use ${{ inputs.name }} and ${{ secrets.name }} for install-time values.
- Use {{ name }} for call-time values and declare each one in param_schema.
- Add request_template only when the request needs a body.
- Do not add undocumented fields or commit literal credentials.
- Write tool descriptions that explain when Captain should call the tool.

Exact schema:
- Top level: version (required semver string), kind (required literal captain_toolset), name (required, 1–100 characters), description (required, 1–500 characters), author (required GitHub username or organization, without the @), category (optional, one of the allowed categories above, defaults to Others), headers (optional map, defaults to {}), inputs (optional, defaults to {}), secrets (optional, defaults to {}), and tools (required, 1–50 items). No other top-level fields are valid.
- headers accepts up to 16 HTTP field names and literal string values of at most 1 KiB each. Names are case insensitive, cannot repeat, and must follow HTTP field name rules; no X- prefix is required. Authorization, Host, Content-Length, Content-Type, and any header starting with X-Chatwoot are reserved regardless of case. Values cannot contain control characters or placeholders.
- Each input or secret supports only label (required, 1–80 characters), type (optional: string, password, number, boolean, or select; defaults to string), placeholder (optional, up to 200 characters), required (optional boolean; defaults to false), and options (optional list of strings).
- Each tool supports only id, title, description, http_method, endpoint_url, auth_type, auth_config, param_schema, request_template, response_template, enabled, and requires_email_verification.
- Required tool fields: id; title (1–100 characters); description (1–500 characters); http_method; endpoint_url (1–2,000 characters); and auth_type (1–50 characters).
- Optional tool fields: auth_config (map), param_schema (list of maps), request_template (1–20,000 characters), response_template (Liquid string with no explicit length limit), enabled (boolean, defaults to true), and requires_email_verification (boolean, defaults to false).
- auth_config and each param_schema item are flexible maps interpreted by Chatwoot. The manifest, each input or secret, and each tool are strict objects.
- A param_schema item may have source: verified.email. In customer conversations, Chatwoot fills that parameter with the customer's verified email and hides it from Captain, so Captain cannot pass a different one. A parameter with a source must have type: string. verified.email is the only allowed source.
- A tool with a source parameter requires email verification even if requires_email_verification is false.

Placeholder rules:
- Every install-time placeholder must reference a declared input or secret.
- Every call-time placeholder must have a param_schema item with the same name.
- Placeholders may appear in endpoint_url, auth_config values, and request_template.
- response_template formats the HTTP response as plain text using strict Liquid. Its syntax, global variables, and filters are validated when the catalog indexes the manifest.
- In response_template, response contains the parsed JSON body or raw response string; r is an alias for the same value.
- If response_template is omitted or blank, Captain receives the raw response body.
- Response status and headers are not available to the Liquid template.

Use this minimal valid manifest as a structural reference:

version: 1.0.0
kind: captain_toolset
name: Example Support Tools
category: Others
description: Look up account information for support conversations.
author: your-github-username

headers:
  x-api-version: '2026-05-01'

secrets:
  api_token:
    label: API token
    type: password
    required: true

tools:
  - id: get_account
    title: Get Account
    description: Retrieve an account when support needs current account details.
    http_method: GET
    endpoint_url: https://api.example.com/accounts/{{ account_id }}
    auth_type: bearer
    auth_config:
      token: ${{ secrets.api_token }}
    param_schema:
      - name: account_id
        type: string
        description: The account identifier supplied by the customer.
        required: true
    enabled: true

Keep the first version focused on safe, useful support workflows. Prefer read operations unless a write action is explicitly requested.

Protect customer data. If a tool returns or changes a customer's own data, such as billing, bookings, or CRM records, set requires_email_verification: true so it runs only after the customer verifies their email with a one-time code. If the tool looks the customer up by email, give that parameter source: verified.email instead.

Before finishing:
1. Validate the completed manifest with:
   curl -X POST /api/captain/tools/validate -H 'Content-Type: application/yaml' --data-binary @path/to/toolset.yml
   Resolve every returned issue and repeat until the response has valid: true.
2. Check the YAML for duplicate keys and aliases; neither is allowed.
3. Check every object against the exact allowed fields above.
4. Check every placeholder against its input, secret, or param_schema declaration.
5. Confirm every endpoint, method, authentication setting, and parameter against official documentation.
6. Summarize the files, tools, inputs, and secrets you added. Do not commit or open a pull request unless asked.