MCP server pit.world

pit.world

Private search, and the front door to the Moshpit network.

An MCP server for private web search. pit mcp is a stdio Model Context Protocol server that gives any agent (Claude, Cursor, any MCP client) web search with no API key and no logging, plus Moshpit name lookups. It is in the official MCP Registry as world.pit/pit.

pit.world is a search engine that keeps nothing about you: no query logs, no cookies, no profile, no trackers, no JavaScript required. It is also where the Moshpit network lives in public: type a Moshpit name like chovy.hacker and it resolves through the registry, next to your web results.

# the web
https://pit.world/search?q=anything

# the CLI and TUI
bun add -g pitworld
pit search "private search engines"
pit resolve chovy.hacker
pit                      # interactive

# your agent
claude mcp add pit -- pit mcp

MCP server

claude mcp add pit -- bunx pitworld mcp

{ "mcpServers": { "pit": { "command": "bunx", "args": ["pitworld", "mcp"] } } }

Tools:

• search: private web search (Google and Bing indexes, merged), returns titles, URLs and snippets.
• moshpit_resolve: resolve a Moshpit name such as chovy.hacker to where it points.
• moshpit_network: live numbers for the Moshpit network.
• listing: a business listing by domain (who operates it, category, service area, services, price, hours, feed, ring membership).
• pros: search the pro directory by category, place and words.
• ring: the pit.world web ring, in order.
• edit_listing: edit a listing you own, with its edit key.

No key is needed. PIT_URL points it at another pit.world instance (default https://pit.world).

What it does

• Web search, privately. Your browser talks only to pit.world. pit.world asks the Google index (through Serper) and the Bing index (through DataForSEO) at the same time, merges the two lists, and tags each result with the engine that found it. The providers get the words, never your IP, browser, cookies or referrer. Linkup, Exa and Perplexity are fallbacks if both fail.
• Moshpit names. A query that looks like label.ending is checked against the Moshpit registry, and a registered name gets a card with where it points.
• Bangs. !gh hqtui, rust lifetimes !so, !pit chovy.hacker: straight to that site's search, without a referrer. The full list is at pit.world/about#bangs.
• Default search engine. OpenSearch description at /opensearch.xml, suggestions at /suggest, and https://pit.world/search?q=%s for any browser.

Business listings, the pro directory and the web ring

• Listings (/b/<domain>). Every site has one. Its owner claims it with a DNS TXT record or a homepage meta tag and gets an edit key (pitk_…, shown once, stored as a hash). The owner writes who operates it (an agent or person handle like riotcoder@profullstack.com, or an https link to an OpenAgent record or profile), the company and its site, a category, the service area (free text plus city, region, country), services, price range, hours, phone and links.
• Listed by pit.world (seeded). pit.world can list a business itself from public information before its owner claims it: the business's own website, licensing and permit records where available, and public company directories. License facts are checked at the issuer (e.g. CSLB for California contractors); NicheDB's public OutreachGraph mirror is matched by exact website domain and adds attributed industry and observed website topics. Never an email address, and never quote routing: the page says it is unclaimed and written by pit.world, is indexable, and carries a "Is this your business? Claim it" button. Claiming hands it to the owner (pit.world never writes to it again) and the owner can take it out of the directory from the edit page. Startup adds submitted public listings and refreshes directory matches daily. To refresh from listings.db on the server: bun src/admin.ts enrich-nichedb [--force]; to seed a public entry: bun src/admin.ts seed FILE.json (an array of {domain, name, description, phone, category, area, city, region, country, services, links, license, licenseCheckedAt, featured}), bun src/admin.ts unseed DOMAIN, bun src/admin.ts views.
• Imported from NicheDB (source nichedb). Companies in nichedb.dev/c/directory, the public half of OutreachGraph (a company by its domain, its industry and stack; never an email, phone or person), become unclaimed listings: imported in id order after a saved cursor, ten pages of 200 every 5 minutes until caught up, then hourly (PIT_DIRECTORY_IMPORT=off stops it). Only companies whose domain resolves to a public address are listed; adult and gambling ones never are. They follow every claimed and seeded listing in /pros (filtered and paged in SQL), carry "Unclaimed listing, data from nichedb.dev" with the record's link, the claim button and vote buttons. SEO guard: an imported listing is indexable and in sitemap.xml only with a real description (read once from its homepage the first time the page is opened) and a category; otherwise its page is noindex. Claiming one hands it to the owner like any other.
• OpenProfile (/b/<domain>/openprofile.md). Every listing in the directory is also an OpenProfile.md with Kind: organization: web, category, location, area, phone, license, services, links, and whether the owner has claimed it. Found by <link rel="openprofile"> on the listing page and a Link header; GET /api/pros carries each one's openprofile URL. OutreachGraph reads them as a lead source.
• Views. /b/<domain> counts page views by people (crawlers, link previews and scripts are not counted) for listings in the directory; the count is views in GET /api/listing.
• Pro directory (/pros, /pros/<category>). Claimed listings and ones pit.world listed, browsable by a fixed list of categories (home services, legal, accounting, software and dev agencies, health, and so on: GET /api/pros/categories) and searchable by words and place. Paid featured placements first, clearly labeled and active only during their paid period, then editorial picks, verified owners by latest edit and unclaimed ones. No reviews in v1: there is no identity to anchor a review to that a business could not fake, so there are none rather than ones that can be bought.
• Quote requests. A listing with a confirmed private address shows a "Request a quote" form. pit.world mails the owner from hello@pit.world with the sender as Reply-To; the owner's address is never shown, sent, or returned by the API. The address only works after its owner clicks the link mailed to it, so a listing cannot aim pit.world's mail at someone else. One listing per request; three requests an hour per visitor (HMAC'd IP, memory only), five an hour and twenty a day per listing, four hundred a day site-wide; a honeypot field; messages with more than three links are refused. pit.world keeps no copy: only the time, to count.
• The pit.world ring (/ring). *.pit.world sites only: the core sites (pit.world, seo.rank, family.ancestry, ...) and then every claimed listing that is a pit.world subdomain or a Moshpit name (relayed at <name>.pit.world), in the order they joined: for those, claiming is joining, and owners can leave from the edit page. A business on its own ICANN domain can claim its listing and be in /pros, but is never a ring member (ringEligible in src/pros.ts). Hops: /ring/next|prev|random?from=<site> (also ?host=, ?url=, ?via=, or the Referer), 302 with no-store; /api/ring for members that draw the bar themselves; /ring/opml for every member's feed. The verified and edit pages show the links to paste.
• Mirrored to rssamplifier.com. pit.world reads each claimed site's homepage for <link rel="alternate"> RSS/Atom on claim and daily, and keeps the ring pit-world on rssamplifier.com/ring/pit-world in step: submit new feeds, add members, remove ones that left. The sync is a diff (idempotent), runs a few seconds after a claim or edit and once a day, and needs RSSAMPLIFIER_API_KEY (an rssamplifier API key of the account that owns the ring; off without it). Moshpit-only names are not mirrored, since rssamplifier cannot reach them. New claims are also a feed: /b/feed.xml.

Public industrial directory listings

Powell Industries is listed as an unclaimed electrical-infrastructure company in src/directory-seeds.ts, using the existing server-side ensurePublicDirectorySeeds import. View it at /b/powellind.com or browse /pros/industrial. Business owners can claim their entry using the standard verification process. The legacy /pro route already redirects to /pros. This directory listing does not imply endorsement, partnership, or any acquisition by xAI.

Business metadata and company enrichment

Every company listing has a canonical website and a categorized directory page. /pros/industrial is the industrial electrical-power category, and /b/powellind.com is Powell Industries' profile. Both the directory cards and detail pages show the category prominently, along with website and publicly listed phone, when known. A JSON-LD Organization block on the detail page, the JSON API (/api/listing / /api/pros) and /b/<domain>/openprofile.md expose the same public facts to search engines and agents.

Two independent, daily source-driven enrichments run on the existing listings:

• NicheDB / OutreachGraph: src/nichedb.ts matches the exact website hostname from NicheDB's public OutreachGraph directory mirror and adds attributed business/industry/technology topics. Only company records are accepted; person or site rows are not used as proof of a business association. The OutreachGraph public export intentionally does not expose emails, phone numbers, locations, or CRM leads. No private API token or workspace campaign data is used.
• Official company website: src/official-company-sites.ts uses the existing SSRF-checked HTTPS verifier for unclaimed, seeded companies only, bounded to three concurrent requests, with a 24-hour refresh. src/company-metadata.ts extracts an explicitly linked same-domain contact page, team/leadership page, company social links, role-based public company inbox (info@, sales@, etc.), and a corporate phone only from matching on-domain Organization JSON-LD. It never guesses a person's address or imports CRM contact data. Each fact retains the company's site as its source. An owner claim hides these automatic facts rather than overriding owner-entered data. A missing or unavailable site remains un-enriched; no fake fields are filled.

People enrichment: PIT links to an official team/leadership page when one is explicitly published by the company. Do not import named prospects from OutreachGraph into PIT's public directory unless their company affiliation has explicit, authoritative public evidence, and only use their public, voluntarily published professional profiles. Keep private campaigns, scores, guessed emails, personal phone numbers, and unpublished OpenProfile.md files out of public profiles. This phase does not replicate OutreachGraph's people database.

Deployment note: changes to the code do not update a running process by themselves. After deployment, server startup migrates the listings SQLite database and refresh jobs fill metadata; verify GET /api/pros/categories, GET /api/listing?domain=powellind.com, and /pros/industrial to confirm live data and category counts.

Promotion campaigns: promote first, then show the results

A promotion campaign lists and promotes the businesses an OutreachGraph campaign targets, measures what that did for each one over its own 30-day window, and only then writes to them, with the numbers. It is how the Los Gatos builders campaign runs (pit.world/roundup/los-gatos-builders).

• Import. scripts/outreachgraph-campaign-export.sh cmp_... writes a complete, read-only snapshot of the OutreachGraph campaign (OutreachGraph has no API that lists every member with its addresses). pit promo import ID snapshot.json gives every source row exactly one disposition (matched, merged into the same business, unresolved, excluded) and the totals must add up. Leads at one domain are one business with all their lead ids. Re-importing the same snapshot changes nothing; only a complete snapshot can mark a business as having left (its listing stays, its priority goes). Businesses without social profiles are kept.
• The roster first. pit promo roster ID: lead ids, business, website, listing, verification, planned action. A member is publishable when its listing is in the directory with a name, category, place, description and a checked source (a license checked at the issuer, or an owner claim).
• Outreach hold. A member only launches when every way the upstream could send to it is held: each lead suppressed in OutreachGraph (the los-gatos-promotion-hold suppress list) or only in campaigns that wait for approval. Otherwise it is blocked with the reason; an operator can attest a hold (pit promo set ID DOMAIN --attest TEXT).
• Priority. Verified members of a running campaign come first in /pros, in SQL before pagination, after filters, so pages, the API and the mobile view agree. Turning priority off or stopping the campaign leaves the listing alone. Campaign membership is never shown publicly.
• Roundup and spotlights. pit promo preview ID shows every planned post with its text and time and a version; pit promo launch ID --version V publishes /roundup/<slug> and creates the calendar: a roundup announcement now, then one spotlight per business across the configured accounts, perAccountPerDay each, from postHour local time. pit promo worker ID (run where myna is logged in) posts due ones with myna post <account> --front, reconciles every post against myna's history and queue by its tracking id (?via=plc_...) before posting so a crash never posts twice, and verifies each through the network's public API (Bluesky getPostThread, Mastodon statuses). Scheduled is not published, published is not verified; only verified posts count. LinkedIn has no public read, so its posts never count. Accounts on networks where myna buys a CrawlProof ad per post are refused: promotion is organic, and a paid budget defaults to zero.
• Measurement. Listing views, website clicks (/b/<domain>/go, a redirect to the listing's own site only), phone taps (a beacon from /listing.js, deduplicated by its id), quote requests, and roundup views (campaign-level, never credited to each business). Crawlers, link previews, prefetches, PIT_INTERNAL_IPS and marked tests (?pt=test) are stored as excluded. No cookie, no IP, no user agent: a visitor is a hash under a salt deleted when its UTC day ends, so "visitor-days" exist and unique visitors over a window do not (reported as unavailable). Only businesses in a campaign are counted.
• Moving off an account. When a network bans or locks an account, pit promo reassign ID --from ACCOUNT --to ACCOUNT [--dry-run] (run where myna is) moves every unposted placement (ready, scheduled, failed) to another account: same tracking id and planned time, text rewritten for the new network, back to ready so the worker re-queues it at the new account's pace. It cancels the old myna queue items, never moves a post myna already published (or one that is uncertain or mid-post), notes each move in the audit log and drops the old account from the campaign config.
• Windows. Each business's window starts when its listing is live, its tracking passed a marked test (pit promo test-tracking ID) and a placement naming it was verified, and lasts periodDays (30) elapsed days. The hourly pass marks ended windows due and makes one review job per window (a restart never makes a second), which writes a versioned report and a draft. Late additions get their own window; gaps are recorded (pit promo gap), never hidden by moving dates.
• Reports. Private and frozen per version (pit promo report ID --md); shareable at /r/<token> (HTML, .md, .json) without the operator's costs. Unavailable is not zero. Late data makes a new version and voids unsent drafts that quoted the old one. pit promo csv ID compares the campaign.
• Drafts and sending. Each report gets one draft from its own numbers: an introduction unless a contact is on record (then a follow-up), an honest note when nothing was measured, blocked when there is no address. Sending is off until sendAuthorized; deliver re-checks the window, the report version and upstream suppression at send time (unknown means no) and keeps one delivery per recipient, message version and window.
• Surfaces. API /api/v1/promotion/* (Bearer PIT_ADMIN_TOKEN), dashboard /admin/promo (a signed-in pit.world admin), pit promo ..., pit promo tui ID, and promo_* MCP tools when PIT_ADMIN_TOKEN is set.

One account for every pit.world site: social. and bbs.

Every Moshpit name gets two more addresses, with nothing to set up:

• social.<name>.pit.world: the name's social feed. Posts from the AT Protocol network tagged with the name's niche (family.ancestry follows #genealogy, #familyhistory, #ancestry, ...), read from every relay we can reach at once (Bluesky's and the independent ones: atproto.africa, relay.fire.hose.cam, relay.upcloud.world, relay.waow.tech), plus posts by members. Each is also an AT Protocol feed generator (did:web:social.<name>.pit.world). It is the pit-social service; pit.world forwards the host to it.
• bbs.<name>.pit.world: the name's bulletin board, a tsbb board made on its first visit (deploy/pit-bbs-provision), its own database, forums seeded, the pit.world admins as its administrators.

Both sign people in with their pit.world account: sign in once at pit.world/signin with CoinPay (OAuth 2.1, code + PKCE) and every board and feed signs you in through pit.world (/bridge/authorize, /bridge/token, @profullstack/bridges), silently when you are already signed in. Nobody makes an account per site. /account shows the sites you use, your CLI tokens, sign out and delete.

• A site's client id is its host; its secret is base64url(HMAC-SHA256(PIT_BRIDGE_KEY, host)), so a new name works the moment it exists and no site is registered by hand. PIT_BRIDGE_CLIENTS adds exact extra hosts (our own apps on the relay).
• Accounts link by CoinPay sub (the person's CoinPay DID) only, never by email (CoinPay reports every email unverified).
• CLI: pit login (OAuth 2.1, public client, loopback redirect, PKCE S256, RFC 8252), pit whoami, pit logout, pit social <name>, pit bbs <name>. API: GET /api/v1/me with Authorization: Bearer pw_….
• Certificates: one Let's Encrypt certificate per name covers <name>, social.<name> and bbs.<name> (deploy/pit-proxy-cert).
• Settings: PIT_COINPAY_CLIENT_ID, PIT_COINPAY_CLIENT_SECRET (CoinPay client with callback https://pit.world/api/v1/coinpay/oauth/callback), PIT_BRIDGE_KEY, PIT_ADMIN_SUBS, PIT_SOCIAL_URL (default http://127.0.0.1:8794, off), PIT_BBS (off), PIT_BBS_MAX (default 100).

Credit codes and invites

• Credit codes (@profullstack/redeem-credits) grant server_months: months of the $5-a-month Moshpit server sold on /start. Redeem on /account ("Have a code?"), POST /api/v1/redeem or pit redeem CODE. A month is spent on /account through the same order a paid month makes (names, username, SSH key to whoever sets up servers, PIT_BUILD_NOTIFY), marked as paid with a credit; if the order cannot be sent the month comes back. Names under our endings are already free, so codes never grant names. Mint on the box: bun $(readlink -f node_modules/.bin/redeem-credits) mint --db ~/.local/share/pit-world/accounts.db --unit server_months --amount 1 --label "who it is for".
• Invites (@profullstack/affiliates): 3 per account, single use, 30 days, made on /account/invites, POST /api/v1/invites or pit invite. /i/<code> sends a person through sign-in, and only a brand-new account spends it. An accepted invite gives nothing beyond the way in.
• Affiliate links: pit.world/join?ref=CODE (and /?ref=CODE) attributes a new account to the member, first touch, once. Promoter codes stay with the promoter program.
• No cookie: the invite or ref rides the sign-in next URL. Tables credit_* and aff_* live in accounts.db.

Privacy, by construction

• nginx writes no access log for the site (ACCESS_LOG=off in bin/install.conf), and the app logs nothing per request.
• No cookies to search. The server strips Set-Cookie from every response except the sign-in and account routes, which set one only after you press Sign in.
• Rate limiting keys on an HMAC of the IP under a secret regenerated every hour, in memory only.
• Anonymous votes and form limits use a salted, hashed device fingerprint (@profullstack/browser-fingerprint), used only to stop one device voting many times or flooding a form. The fingerprint itself is never stored, only HMAC(secret, stable components). A result vote keeps a keyed hash of its search, never the words. See Votes.
• Searches you vote on are counted, unlinked. vote_phrases holds the phrase, the day and a number, nothing about the voter. A search with no vote keeps nothing. Public at /api/voted-searches after three votes.
• Identical searches are cached in memory for ten minutes to avoid paying twice; the cache holds words and results, nothing about who asked, and never touches disk.
• Strict CSP (default-src 'none', same-origin scripts and styles only), Referrer-Policy: no-referrer, results link straight to the site.

The page says the same in plain words: pit.world/privacy.