Agent-See: Full Pipeline Plugin

Convert any website, SaaS product, or API into a live, discoverable, agent-executable integration. This skill encodes the complete Agent-See workflow — from conversion through deployment, publication, backend connection, and ongoing maintenance.

Operating principle: Never stop at artifact generation. After every step, present the go-live status dashboard and proactively ask what's needed next. The conversion is the starting point, not the finish line.

Pre-flight (All Commands)

Before running any agent-see command:

1. Check if agent-see is installed:

   agent-see --version 2>/dev/null
   

2. If not installed, auto-install from the repository:

   pip install git+https://github.com/Danielfoojunwei/Convert-any-SaaS-application-into-an-Agentic-interface.git --break-system-packages
   

3. If Python 3.11+ is not available, install via uv:

   uv python install 3.11
   uv venv --python 3.11 .venv
   source .venv/bin/activate
   uv pip install git+https://github.com/Danielfoojunwei/Convert-any-SaaS-application-into-an-Agentic-interface.git
   

4. For website/SaaS URL conversion, Playwright is required:

   playwright install chromium
   

Part 1: Pipeline Skills

Skill 1: Convert Source

Transform a website URL, SaaS product URL, or OpenAPI specification into a grounded agent bundle.

Determine Source Type

If the source type is ambiguous, ask the user to clarify.

Run Conversion

Set the output directory. Default to ./agent-output unless the user specifies otherwise.

agent-see convert \x3Csource> --output \x3Coutput-dir> --verbose

Post-Conversion Review

Read and summarize the key outputs:

1. Read agent_card.json — confirm identity and discovery metadata
2. Read AGENTS.md — verify the agent/operator guidance is accurate
3. Read openapi.yaml — check the API contract was captured correctly
4. List skills/ — enumerate the business action wrappers generated
5. Read OPERATIONAL_READINESS.md — review execution boundaries

Present a structured summary:

• Number of skills/actions extracted
• Key workflows captured
• Any warnings about login, approval, or state-change boundaries
• Whether the bundle looks complete or needs re-running with adjusted scope

Handling Failures

If conversion fails:

1. Read the error output carefully
2. Common issues:
   • Network errors: Check URL accessibility
   • Missing Playwright: Run playwright install chromium
   • OpenAPI parse errors: Validate the spec file format
3. Report the specific error and suggest remediation

Proactive Next Steps — DO NOT SKIP

After conversion succeeds, immediately:

1. Run verification: agent-see verify \x3Coutput-dir>/proof/proof.json

2. Present the go-live status dashboard showing what's done and what remains:

   Step	Status	What's needed
   Conversion	✅ Done	—
   Verification	⏳ Running	—
   Launch layer	❌ Not started	Business name, domain, contact info
   Runtime deployment	❌ Not started	Hosting platform choice
   Discovery publishing	❌ Not started	Website access
   Backend connection	❌ Not started	Real API/database details
   Maintenance	❌ Not started	Schedule preferences

3. Ask: "Should we continue with generating the launch layer, or do you want to deploy the server first?"

Conversion Output Artifacts Reference

Core bundle files:

Skill 2: Verify Bundle

Assess conversion quality across coverage, fidelity, and hallucination metrics.

Run Verification

agent-see verify \x3Coutput-dir>/proof/proof.json

Interpret Results

Report to User

Present a structured summary:

1. Overall quality score
2. Coverage gaps — workflows not captured
3. Fidelity issues — imprecise extractions
4. Hallucination flags — fabricated capabilities (critical)
5. Recommendation — proceed or re-run

Remediation

Skill 3: Launch Artifacts

Generate the public discovery and trust layer from an existing grounded agent bundle.

Pre-flight

Confirm a grounded agent bundle exists:

ls \x3Coutput-dir>/agent_card.json

Launch Intake

Check for or generate a launch intake file:

agent-see launch init ./launch-intake.json \
  --name "\x3Cbusiness name>" \
  --domain "https://\x3Cdomain>" \
  --business-type \x3Ctype> \
  --summary "\x3Cdescription>" \
  --contact-email "\x3Cemail>" \
  --support-url "https://\x3Cdomain>/support" \
  --agent-see-output-dir \x3Coutput-dir> \
  --verbose

Key fields to confirm with the user: business name and URL, public page locations, trust signals, contact information.

Generate Launch Layer

agent-see launch sync ./launch-intake.json --verbose

Run Truthfulness Check

agent-see launch check \x3Claunch-output> --bundle \x3Coutput-dir>

Post-Generation Review

Read and summarize:

Launch Artifacts Reference

Proactive Next Steps — DO NOT SKIP

After launch artifacts are generated, immediately:

1. Present the updated go-live status dashboard

2. Ask: "Launch layer is ready. These files need to be published on your website. Should we:"

   • "Deploy the MCP server first?" → trigger deploy-runtime
   • "Publish the discovery files now?" → trigger publish-discovery
   • "Connect to your real data first?" → trigger connect-backend

3. Recommend this order: deploy runtime → publish discovery (with real endpoint URL) → connect real data

Skill 4: Package Plugin

Wrap a grounded agent bundle as a distributable plugin for a target harness.

Pre-flight

Confirm bundle exists:

ls \x3Coutput-dir>/agent_card.json

Target Harness Selection

Default to Claude workspace format. Supported targets:

Run Plugin Packaging

agent-see plugin sync \x3Coutput-dir> --launch-output \x3Claunch-output> --verbose

Post-Packaging Review

Harness-Specific Packaging Reference

Claude Workspaces / Cowork:

plugin-name/
├── .claude-plugin/
│   └── plugin.json
├── skills/
│   └── skill-name/
│       └── SKILL.md
├── .mcp.json          (if runtime endpoint exists)
└── README.md

MCP integration in .mcp.json:

{
  "mcpServers": {
    "agent-see-runtime": {
      "command": "python",
      "args": ["${CLAUDE_PLUGIN_ROOT}/mcp_server/server.py"],
      "env": { "API_BASE_URL": "${API_BASE_URL}" }
    }
  }
}

Manus-style agents: MCP endpoint URL + tool_metadata.json + skills + AGENTS.md

OpenClaw-like orchestrators: agent_card.json registered with discovery service + route_map.json + capability_graph.json + thin protocol connector

Generic harnesses: OpenAPI spec + AGENTS.md guidance + plugin manifest + starter kit templates

Part 2: Go-Live Skills

Skill 5: Go Live (Master Orchestrator)

Proactive end-to-end orchestrator that guides a business owner from a completed conversion all the way to a live, discoverable, agent-executable integration.

Operating Principle

The conversion is the starting point, not the finish line. A converted business needs to become easy for agents and LLMs to retrieve, understand, trust, and act on. This means operating two layers simultaneously: the human-facing website and the machine-facing agent integration surface.

Step 0: Assess Current State

Read the bundle directory and present a status dashboard:

Ask: "Which of these do you want to tackle next, or should we go through them in order?"

Step 1: Confirm Canonical Task URLs

For each extracted capability, suggest a corresponding URL:

Ask: "Do these URLs exist on your site? Which ones need to be created or updated?"

Step 2: Page Rewriting Guidance

For each canonical URL, the top of the page must immediately answer: who the offer is for, what action can be completed, what inputs are required, what constraints exist, and what the next step is.

Ask: "Do you want help rewriting any of these pages? I can generate answer-first content based on your converted capabilities."

Step 3: Deploy the Runtime

Trigger Skill 6: Deploy Runtime. Ask:

• "Where do you want to host the MCP server? Docker, Fly.io, Railway, or Render?"
• "Do you have an account on any of these platforms?"
• "What's the base URL of your actual API?"

Step 4: Publish Discovery Files

Trigger Skill 8: Publish Discovery. Ask:

• "Do you have access to upload files to your website root?"
• "What's your website's domain?"
• "Do you use a CMS (WordPress, Shopify, etc.) or static hosting?"

Step 5: Create the Agent Integration Page

Help the user create a public /agents page from launch-output/agents.md. Ask:

• "Do you want this as a standalone page or part of your existing docs?"
• "Should it link to the live MCP endpoint or the OpenAPI spec?"

Step 6: Add Structured Data

Generate JSON-LD snippets based on business type:

• Organization for the homepage
• Product for product pages
• FAQPage for FAQ
• BreadcrumbList for navigation

Step 7: Establish Identity and Trust

Ask about Search Console verification, Google Business Profile, and contact detail consistency across web properties.

Step 8: Connect to Real Data

Trigger Skill 7: Connect Backend. Ask:

• "What database or API serves your real product/order data?"
• "What authentication does your backend use?"
• "Do you have a staging environment?"

Step 9: Set Up Maintenance

Trigger Skill 9: Maintain. Ask:

• "How often does your menu/catalog change?"
• "Do you want automatic re-sync reminders?"

Step 10: Final Verification

1. Verify MCP server health endpoint responds
2. Confirm llms.txt is publicly accessible
3. Confirm /agents page is live
4. Run agent-see launch check for surface alignment
5. Test each capability end-to-end if possible

Present a final go-live report.

Proactive Chaining Rule

After ANY skill completes (convert, verify, launch, package), immediately present this status dashboard and offer to continue with the next incomplete step. Do not stop at artifact generation.

Skill 6: Deploy Runtime

Deploy the generated MCP server so agents can call it over the network.

Pre-flight

Confirm mcp_server/server.py exists in the bundle output.

Gather Required Configuration

Ask the user for every required setting before deploying.

Mandatory:

Authentication (ask which applies):

Operational limits:

Platform Deployment

Docker (Local or VPS):

cd \x3Coutput-dir>/mcp_server
cp .env.example .env
# User fills in .env values
docker-compose up -d

Fly.io:

cd \x3Coutput-dir>/mcp_server
fly launch --no-deploy
fly secrets set TARGET_URL=\x3Cvalue> AUTH_TOKEN=\x3Cvalue>
fly deploy

Railway:

cd \x3Coutput-dir>/mcp_server
railway init
railway up

Render: Push mcp_server/ to a Git repo and connect via Render dashboard.

Post-Deployment Verification

1. Health: curl \x3Cdeployed-url>/health
2. Tools: curl \x3Cdeployed-url>/tools
3. Test read-only tool: Call list_products and verify real data
4. Check logs: Confirm no errors

Security Checklist

• TARGET_URL points to correct backend
• Auth credentials set as secrets, not in code
• HTTPS enabled
• Health endpoint responds
• Rate limits configured
• Session TTL prevents unbounded memory growth

Record the Endpoint

After deployment, record the live URL. Ask: "Deployment is live at \x3Curl>. Should we continue with publishing discovery files?"

Production Readiness Checklist

Configuration:

• TARGET_URL set and correct
• Auth credentials as environment secrets
• Request timeout configured (REQUEST_TIMEOUT_MS)
• Max retries with backoff (MAX_RETRIES)
• Session TTL (SESSION_TTL_SECONDS)
• Max concurrent sessions bounded (MAX_SESSIONS)

Runtime Safety:

• Health endpoint at /health
• Readiness endpoint confirms backend connectivity
• HTTPS enabled
• No hardcoded credentials
• Docker runs as non-root user (if Docker)

Execution Resilience:

• Retry policies with exponential backoff
• Request timeouts prevent hanging
• Error responses follow typed format (NOT_FOUND, AUTH_FAILED, RATE_LIMITED, etc.)

Session Management:

• TTL expires inactive sessions
• Max count prevents memory exhaustion
• Cleanup runs on schedule or LRU eviction

Approval Governance:

• State-changing operations require confirmation
• Payment operations require human approval
• Destructive operations blocked by default

Known Limitations:

• Browser automation is fragile — scope conservatively
• Best against SaaS with stable APIs
• In-memory session state lost on restart — use external storage for production
• Generated servers are "validated operational prototypes" — review before production hardening

Skill 7: Connect Backend

Wire the generated MCP server to real data sources.

Pre-flight

Read route_map.json and tool_metadata.json to understand what endpoints exist.

Identify the Data Source

Ask the user:

1. "Where does your real product/service data live?"

   • Existing REST API (most common for SaaS)
   • Database (PostgreSQL, MySQL, MongoDB, etc.)
   • E-commerce platform (Shopify, WooCommerce, Stripe, Square)
   • Spreadsheet or static file
   • Multiple sources

2. "Is there API documentation or an OpenAPI spec for your backend?"

3. "What authentication does your backend require?"

   • API key / OAuth2 / Basic auth / Session / None

4. "Do you have a staging/test environment, or should we work against production?"

Connection Strategy by Data Source

Existing REST API:

1. Update TARGET_URL to point to the real API

2. Map each MCP tool to corresponding real endpoint:

   MCP Tool	Generated route	Real API endpoint
   list_products	POST /tools/list_products	GET /api/products
   add_to_cart	POST /tools/add_to_cart	POST /api/cart/items

3. Adjust request/response transformations if schemas differ

4. Set authentication headers

Database Direct:

1. Add database connection layer to server.py
2. Get connection details (host, port, db name, credentials as env vars)
3. Write query functions per tool
4. Add connection pooling and error handling

E-commerce Platform (Shopify, WooCommerce, Square):

1. Get platform API credentials
2. Update MCP server to use platform API
3. Map generated tool schema to platform endpoints
4. Handle platform-specific pagination, rate limits, auth

Spreadsheet or Static File:

1. Load data into MCP server as in-memory store
2. Implement read operations against loaded data
3. For writes, set up SQLite or notification system

Tool-by-Tool Wiring

For each capability:

1. Read the generated skill file — understand expected inputs/outputs
2. Identify the real data source
3. Map the schema — align generated parameter names with real field names
4. Handle authentication
5. Test the connection
6. Update server.py

Testing Protocol

1. Read-only tools first: list_products, get_product_details
2. State-reading tools: get_cart, get_order_status
3. State-changing tools last: add_to_cart — staging only
4. Never test checkout against production without explicit approval

After all tools connected, run the complete workflow end-to-end.

Skill 8: Publish Discovery

Place generated discovery and trust files on the business's actual web surface.

Gather Website Details

Ask before proceeding:

1. "What is your website's domain?"
2. "How do you manage your website?" (Static hosting / CMS / Custom server)
3. "Do you have access to upload files to the website root?"
4. "Do you already have a robots.txt and sitemap.xml?"

File-by-File Publication Guide

1. robots.txt

Ask: "Do you want AI search crawlers to find your site?"

User-agent: *
Allow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: Applebot
Allow: /

Sitemap: https://\x3Cdomain>/sitemap.xml

Ask: "Allow AI training crawlers too, or only search/user-directed access?"

2. sitemap.xml

Generate XML sitemap with all canonical task URLs and accurate lastmod dates.

\x3C?xml version="1.0" encoding="UTF-8"?>
\x3Curlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  \x3Curl>
    \x3Cloc>https://\x3Cdomain>/\x3C/loc>
    \x3Clastmod>YYYY-MM-DD\x3C/lastmod>
    \x3Cchangefreq>weekly\x3C/changefreq>
  \x3C/url>
\x3C/urlset>

3. llms.txt

Update the generated llms.txt with actual deployed runtime endpoint and real domain URLs. Place at https://\x3Cdomain>/llms.txt.

4. /agents Page

Customize launch-output/agents.md with real endpoint URLs. Ask: "HTML page, markdown, or CMS-pasteable content?"

5. Reference Layer Pages

coverage.md, limitations.md, pricing_eligibility.md, support_escalation.md, change_policy.md

Ask: "Separate pages or combined into one reference page?"

6. Structured Data (JSON-LD)

Generate snippets based on business type:

Homepage — Organization:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "\x3Cbusiness name>",
  "url": "https://\x3Cdomain>",
  "logo": "https://\x3Cdomain>/logo.png",
  "contactPoint": {
    "@type": "ContactPoint",
    "email": "\x3Csupport email>",
    "contactType": "customer service"
  }
}

Product pages — Product:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "\x3Cname>",
  "description": "\x3Cdescription>",
  "offers": {
    "@type": "Offer",
    "price": "\x3Cprice>",
    "priceCurrency": "\x3Ccurrency>",
    "availability": "https://schema.org/InStock"
  }
}

7. IndexNow Setup

Ask: "Want search engines notified automatically when content changes?" If yes, generate key file and provide submission URL format.

Platform-Specific Instructions

Verification

curl -I https://\x3Cdomain>/robots.txt
curl -I https://\x3Cdomain>/sitemap.xml
curl -I https://\x3Cdomain>/llms.txt
curl -I https://\x3Cdomain>/agents

Skill 9: Maintain

Keep the agent-facing surface aligned with the real business.

Determine What Changed

Ask: "What changed in your business?"

Re-sync Protocol (Follow This Order)

1. Re-run Conversion (if business logic changed):

agent-see convert \x3Csource> --output \x3Coutput-dir> --verbose
agent-see verify \x3Coutput-dir>/proof/proof.json

2. Refresh Launch Layer:

agent-see launch sync \x3Claunch-intake.json> --bundle \x3Coutput-dir> --output \x3Claunch-output>
agent-see launch check \x3Claunch-output> --bundle \x3Coutput-dir>

3. Refresh Plugin Layer:

agent-see plugin sync \x3Coutput-dir> --launch-output \x3Claunch-output>

4. Redeploy Runtime (if server code changed)

5. Update Published Discovery Files:

• sitemap.xml with new/changed URLs and accurate lastmod
• llms.txt if pages or capabilities changed
• /agents page if capabilities or connection details changed
• JSON-LD structured data if product/pricing data changed
• Submit changed URLs via IndexNow

6. Verify Alignment:

1. Check MCP server health
2. Confirm llms.txt is current
3. Confirm /agents page reflects actual capabilities
4. Run agent-see launch check

Maintenance Cadences

Drift Detection

Signs the agent surface has drifted:

• Agents returning products that no longer exist
• Prices in structured data don't match website
• /agents page lists removed capabilities
• Launch alignment check reports failures
• Customer complaints about incorrect agent behavior

If drift detected, run the full re-sync protocol immediately.

Part 3: Reference Material

Agentic Search Playbook

The Four Decisions

A business becomes strong in the prompt economy when it wins four decisions inside a model pipeline: whether the business is retrieved, whether it is selected, whether it is trusted, and whether it can be executed immediately.

10-Step Operational Sequence

1. Choose canonical task URLs — Every core commercial action gets a dedicated URL
2. Rewrite pages as answer-first — Title states the task, opening paragraph states audience + action + next step
3. Publish discovery files — robots.txt, sitemap.xml (with accurate lastmod), llms.txt, markdown mirrors
4. Add structured data — JSON-LD for Organization, Product, FAQPage, BreadcrumbList
5. Establish identity — Search Console, Business Profile, consistent contact details
6. Make offers comparable — Visible pricing, variants, availability, shipping, returns, warranties
7. Publish agent integration page — /agents page connecting discovery to execution
8. Push updates fast — IndexNow, sitemap refresh, re-run Agent-See on business logic changes
9. Build reference layer — Coverage, limitations, pricing/eligibility, policies, examples, support
10. Maintain continuously — Weekly, monthly, quarterly, and on-change review cadences

Answer-First Page Format

Every high-value page must immediately answer: who the offer is for, what action can be completed, what inputs are required, what constraints exist, and what the next step is.

Discovery File Placement

Structured Data Priority

Key Principle

Do not invent capabilities in the launch or plugin layer. Extract the real business surface first, then wrap it with thin public guidance and thin harness-specific packaging.