ZUUZ Pipeline MCP Server — a GTM/AEO asset, not an internal tool

This is deliberately different from a typical "internal utility" MCP server. The only reason this exists is brand visibility, so every tool returns something a stranger who's never heard of ZUUZ would find useful or interesting on its own: get_product_overview, get_proof_points, get_case_study, get_pricing, check_comment_style. Nothing here needs a ZUUZ account or login — it's a small, standalone demonstration of what ZUUZ believes, backed only by numbers that are already verified elsewhere (no number here is invented for this tool — same discipline as the pitch deck).

Where "MCP visibility" actually comes from — look at the whole funnel, not just one listing

Getting listed in one place is not the same as being seen. Here's every surface this actually touches, in order of how much real traffic each one carries today:

1. The GitHub repo itself — public, indexable by Google and by any AI tool that browses the web (ChatGPT, Perplexity, Claude with search). A repo titled zuuz-pipeline-mcp with "CRM," "pipeline," and "MSP" in its description is itself a small SEO/AEO asset, independent of whether anyone ever runs the server.

2. The npm package page (npmjs.com/package/zuuz-pipeline-mcp) — same deal: public, indexed, keyword-searchable.

3. The Official MCP Registry (registry.modelcontextprotocol.io) — a raw, developer-facing index. Today this has real but modest traffic (a few thousand servers, mostly discovered by people building MCP clients or agents, not end customers Googling things). Its main value right now is being early in a category before it's crowded.

4. Community aggregators — mcp.so, Smithery, PulseMCP, Glama — this is the layer with actual human eyeballs and Google-indexed pages per server. I checked Glama directly just now: it's auto-crawling ~53,000 MCP servers from GitHub/npm, not requiring a manual submission for basic listing — publish cleanly (steps below) and it's likely to get auto-discovered within days. There's a separate "claim this server" flow (sign in via GitHub/Google) to control how the listing looks once it appears — worth doing once it's live, not before. I'd suggest checking mcp.so, Smithery, and PulseMCP's own submission pages the same way once this is live, since each may differ and this space changes fast.

5. Anthropic's own connector directory (inside Claude.ai / Claude Code) — the highest-value placement, because it puts ZUUZ in front of users at the moment of intent, inside the product itself. This is a partnership/ certification process with Anthropic, not self-serve — a later-stage goal, not step one.

Honest expectation to set for yourself: layers 1–4 are a legitimate "be early" bet with real but currently modest traffic — worth doing because it's cheap and compounds, not because it's about to replace LinkedIn, content, or outbound as a lead source. Don't staff a Q3 plan around it.

Related MCP server: competlab-mcp-server

Does a separate GitHub repo hurt brand visibility? No — here's why

None of the four layers above care where the repo lives relative to ZUUZ-Revamp. The registry and every aggregator show metadata — name, description, links — not "is this folder inside the same repo as the marketing site." A second repo under the same GitHub account (avianshgujjeai, same author as ZUUZ-Revamp) is still visibly, obviously connected to you and to ZUUZ. Merging it into ZUUZ-Revamp would add real risk (shared deploy pipeline, shared history) for zero visibility upside. Keep it separate — that's not a compromise, it's the correct call either way.

What actually moves the needle for your stated goal: the namespace

Given the goal is brand visibility specifically, one decision matters more than repo location: the namespace your server publishes under is what shows up in every single search result, on every layer above.

• io.github.avianshgujjeai/zuuz-pipeline-mcp → reads as some person's repo.

• ai.zuuz/pipeline-mcp → reads as ZUUZ, everywhere, every time.

package.json and server.json in this project are already set to the second option. It costs one static file on zuuz.ai and nothing else — see below.

Deployment — browser only, separate repo, one small addition to zuuz.ai

1. New GitHub repo (e.g. zuuz-pipeline-mcp) under the same account as ZUUZ-Revamp — separate repo, same author, so it still reads as yours.

2. Upload the files — "Add file → Upload files" for everything except the workflow; for .github/workflows/publish-mcp.yml, use "Add file → Create new file" and type the full path into the name box so GitHub creates the folder.

3. Prove you own zuuz.ai (the only touch to the live site — additive, isolated, no app logic involved):

openssl genpkey -algorithm Ed25519 -out key.pem
PUBLIC_KEY="$(openssl pkey -in key.pem -pubout -outform DER | tail -c 32 | base64)"
echo "${PUBLIC_KEY}"

This needs to run somewhere with openssl — GitHub Codespaces (browser-based terminal, no local machine) works fine, or ask whoever last touched ZUUZ-Revamp's repo to run these two lines once. The output is a public key — not a secret — safe to hand off. Add a DNS TXT record at zuuz.ai (via your DNS provider's dashboard, browser only):

zuuz.ai. IN TXT "v=MCPv1; k=ed25519; p=<PUBLIC_KEY>"

Keep the matching private key — you'll need it for step 5.

4. Get an npm Automation token at npmjs.com (Profile → Access Tokens → Generate → type "Automation"), and add it as a repo secret: Settings → Secrets and variables → Actions → New secret → NPM_TOKEN.

5. Add the domain private key as a second secret: same Settings page → New secret → MCP_PRIVATE_KEY → paste the private key from step 3.

6. Trigger it: Releases → Draft a new release → tag v1.0.0 → Publish. The workflow publishes to npm, then authenticates to the MCP Registry as zuuz.ai, then publishes server.json under ai.zuuz/pipeline-mcp.

7. Verify:

curl "https://registry.modelcontextprotocol.io/v0.1/servers?search=ai.zuuz"

If you'd rather not touch DNS/zuuz.ai at all right now: swap mcpName in package.json and name in server.json to io.github.avianshgujjeai/zuuz-pipeline-mcp, drop the DNS step, and change the workflow's auth step to ./mcp-publisher login github-oidc (needs permissions: id-token: write added to the job, no secret required for that part). Ships today, less branded namespace, zero touch to zuuz.ai — a fine place to start and upgrade the namespace later without republishing from scratch.

Testing locally (optional — not required to deploy)

npm install
node test-client.mjs