We gave our Grok Bots a concrete job: help build our products and make them easier to find.

The bots helped build the products, prepared their listings, checked what went live, and kept the receipts. The useful part is the system behind that work. You can give the same jobs to your own agent.

The job was simple to say and easy to fake: write down every product we actually have, help build the ones that were still in progress, list them where people and other agents look, then report what Google and the directories showed. Not what we hoped they showed.

I’m writing this as a how-to you can hand to your own agent. It is also about Agnostify, on purpose. I will walk you through the product inventory, the build process, the listings, and the results. Then you can copy the prompt and put the workflow to work on your own business.

The job behind the product launch

Shipping a product and getting it found are different jobs.

We had live pages for the things we run on: a free AI search scan called Cubsy, a weekly board of which brands AI answers name, a daily checked feed of AI releases called Context Pill, and a couple of interactive demos. We also had the usual pile of “submit your tool” forms, some of them free, many of them asking for a homepage badge or a paid skip.

If you have a product page and still handle every directory form yourself, this is the work you can hand over. You need a way to describe the product accurately, choose suitable places to list it, and check what happened afterward. The agent needs those decisions written down before it starts.

What the Grok Bot army was allowed to do

The bots needed a defined job and a permission boundary before they needed a clever prompt.

Our approved crew process has an agent write up a request, another build and test, and a person review before it reaches a client. The directory and site records show similar boundaries: approved free submission work, no unapproved paid upgrades, and a separate human decision for site changes. Those are the recorded instructions, not proof that every historical action followed the same route.

Here is how the recorded work breaks down by job. These labels explain responsibilities; they are not a claim that every label was a separately deployed bot or that the whole workflow ran unattended.

  • The inventory and copy bot kept a locked listing kit. Every product name, URL, short description, and price line had to come from a live page or an already published draft. No invented user counts, reviews, or results. If the kit did not have a screenshot, the bot did not invent one.
  • The directory bots researched free submission paths, filled forms from that kit, and logged status. The authorized listing runs included free submissions using the approved kit. They were not allowed to buy Featured, Priority, Fast Track, or “launch this week” upgrades. The instructions required a stop for my decision if a free listing needed a badge or footer backlink on our site.
  • The inbox bot read listing mail, including spam and promotions, and sorted replies into rejected, approved, pending, scheduled, or “needs a person.” An approval email was never treated as a visit.
  • The verification bot did the unglamorous part: it opened the public listing URL later and checked that the product name and our real page were actually there. Submitted is not live. Live on a directory is not a click on our site.
  • The build bots, usually in a coding workspace, implemented product and site changes as pull requests. They were told not to merge, not to deploy, and not to publish without an explicit yes. A branch needs a separate live check before we describe its features as available.
  • The measurement bots pulled Google Search Console when they could get signed-in access, and they kept those numbers apart from on-site analytics and apart from directory counts.

If you copy only one thing from our setup, copy the permission list:

  • Use only facts from the live site or the locked kit.
  • Stay on free paths unless a human approves a specific payment.
  • Do not add a badge, footer link, or legal page without a human.
  • Do not merge or deploy without a human.
  • Do not invent metrics to look more established on a form.
  • After any “you’re listed” email, verify the public URL.
  • Record Google impressions and clicks only from Search Console, with the property, date range, and filter written down. Do not substitute website analytics for that.

The useful handoff is the permission list together with a record of what the bot actually did. Keep both.

The product inventory, written down first

The catalog gave the listing work a source of truth.

The source of truth was a listing kit built from live pages on Agnostify site and Context Pill site. As of that kit, the public set was:

  • Agnostify itself, the agency: custom AI built into the tools a business already uses, run by two founders in Los Angeles.
  • Cubsy, a free AI search scan at Cubsy scan.
  • The Crew, an interactive office of AI helpers at The Crew demo.
  • Content Studio, a demo of helpers drafting a post for approval, at Content Studio demo.
  • Who AI Picks, a weekly public board at WhoAI Picks board.
  • Context Pill, a daily checked list of new AI releases and tools, at Context Pill site.
  • Agnostify City, teased as coming soon, with no product URL yet, so it was held back from most directories.

A quick name note: WhoAI Picks is the product the kit and many directories call Who AI Picks. Its live page now says “Who AI Sends Buyers.” They point to the same board. I use WhoAI Picks below so you can follow one product through the process.

On November 8, 2026, that public board described how often ChatGPT, Gemini, and Google AI Mode name brands for the same buyer questions, using logged-out US sessions. It showed six categories and an update date of November 2. These are published measurements of the brands in its reviewed list. Your brand does not automatically appear just because you visit the page.

Cubsy was live at Cubsy scan, titled “Cubsy AI Search Scan.” The page labels its flow Scan, Fix, Optimize, and Choices. Its published description says it checks whether ChatGPT, Gemini, Google AI Mode, and Perplexity name your business, and can check up to 10 website pages. The scan is free; a full report is a separate paid option. We checked the page and its published copy for this article, not a complete new scan or checkout. Treat those as the product’s stated capabilities, not a fresh performance test.

Context Pill was live on its own domain, with a working MCP endpoint at Context Pill MCP endpoint. More on that in a moment, because “we listed it on MCP” is the phrase that usually gets this process wrong.

We also checked the obvious company URL that people guess first. Company-level MCP path returned a page-not-found on Nov 8, 2026. There is not a live catch-all “Agnostify MCP” at that address.

THE BUILD: how products got built, tested, and released

The bots did not only fill out forms. They also helped build the things the forms point to.

The pattern is the same one we use for client work. An agent drafts the request, another agent builds and tests, and a person reviews before anything reaches the public. For our own site that usually means a coding agent opens a pull request, another pass checks it, and I decide whether it merges and deploys.

That distinction matters more than it sounds. A product can be designed, implemented, sitting on a branch, merged, deployed, submitted to a directory, approved by email, and actually visible on a public URL. Those are different states that need different evidence. We have work in more than one of them at the same time.

Context Pill is the clearest “built and released” example. The site is live. The MCP server is live at Context Pill MCP endpoint. On November 8, 2026, it answered initialization and returned three tools marked read-only: get_latest for checked items, search_claims for the published claim ledger, and list_sources for source records. A real get_latest call also returned published material without sign-in. That is a product other agents can use, not just a page people can read.

The weekly board is also live, and it now has its own MCP endpoint at WhoAI Picks MCP endpoint. A GET request there says, in substance, to send JSON-RPC over POST. A tools/list call on Nov 8 returned seven read-only tools: list_categories, list_questions, get_category_board, get_question, get_brand, get_movers, and describe_method. Initialization and a real list_categories tool call also succeeded without sign-in. That verifies a usable published-data connection, without claiming that every tool was individually tested here.

An older queue still described the board’s MCP as waiting for production verification. The live checks supersede that old endpoint assumption. They do not establish which pull request deployed it, who deployed it, or whether any catalog accepted it. That needs separate evidence.

Cubsy, The Crew, and Content Studio were already public demos or tools, not ideas waiting for a landing page. Agnostify City still was not, so it stayed out of most submissions.

Site changes followed the same gate. A separate SEO thread in our coding workspace pulled Search Console, proposed two internal links that already existed as phrases on the page, and waited for approval before editing. That is the release culture I want you to copy: the bot can prepare the work. The bot does not get to decide that the work is live.

Building an MCP is not the same as listing one

MCP, in ordinary language, is a standard way for an AI agent to use tools. Instead of hoping the model remembers your website, you give it a server it can call: fetch today’s items, look up a brand on the board, search a claim. For these products, the connection reads published information. It does not grant access to our private operations or make the product appear in every AI app.

The places you publish that server are directories and catalogs: the official MCP registry, sites like MCP Servers catalog, and the connector directories inside products such as Claude or ChatGPT. A catalog can help people and compatible apps discover a tool. A catalog entry does not guarantee that an assistant will select it or recommend its publisher. The server itself is how they use it.

We treated those as two jobs.

For Context Pill, both jobs have real receipts. The endpoint is live, as above. The official MCP registry lists it as com.contextpill/context-pill, version 0.1.0, remote URL Context Pill MCP endpoint, status active. The registry record checked November 8, 2026 records publication at October 18, 2026, 8:53 PM PDT. A separate listing path, MCP Servers catalog, sent an approval email on November 3, 2026 saying the Context Pill MCP server was approved and live. That approval is recorded in our email tracker. We do not have a freshly verified public listing page for it in this review, so it stays labeled as a recorded approval rather than a new public-page confirmation. Other catalog routes were researched and, in some cases, submitted or attempted: a free MCP Servers catalog form went in, a Cursor Marketplace submission was recorded as received, Glama was submitted, Google Connected Apps went onto a waitlist, and an xAI marketplace form showed an error twice, so we do not know if that one arrived. Claude’s and ChatGPT’s official directories were not completed, because they needed a paid plan, identity checks, a walkthrough video, or other human steps.

For Who AI Picks, the split is even sharper. The product MCP now answers at WhoAI Picks MCP endpoint, with the seven tools above. A search of the official MCP registry on Nov 8 for whoaipicks, agnostify, and ai-picks returned zero servers. A November 6, 2026 submission queue for that MCP is marked nothing submitted. It had been waiting on a verified production endpoint, a public repo for some catalogs, and a registry namespace decision. The live server is verified. A WhoAI Picks MCP catalog placement is not verified in the records reviewed. Those searches cover one registry and those terms; they cannot prove the server is absent from every catalog.

If your own agent later tries to “connect Agnostify’s MCP,” point it at the live tools that exist: Context Pill at Context Pill MCP endpoint, and the weekly board at WhoAI Picks MCP endpoint. Do not send it to company-level MCP path. That URL was a 404 on Nov 8.

How we chose directories, submitted, and checked what was live

The directory work was not “submit to every site on a Twitter screenshot.”

We started from public launch lists, then added directories that other people said AI answers cite often, then kept a running tracker. The recorded house rules were: avoid duplicate entries and follow each directory’s product rules, copy taken from the kit, free tier only, skip any path that required a badge or a backlink we had not approved, and never pay to jump a queue unless I said yes to that exact fee. The reviewed runs record those paid upgrades as skipped. A free form still represents the business publicly, so its destination and exact copy need approval before an agent submits it.

The records show a practical problem: directories do not all want the same kind of product.

Some want a usable tool a visitor can run. Cubsy fits that better than a weekly board. Some want a startup story or an agency profile, which is Agnostify itself. Some want software with screenshots, platforms, and a license. AlternativeTo declined Context Pill on October 25, 2026 because, in their words, the submission was missing too much information. That may have been an incomplete form. It may also have been a category problem, because their FAQ declines content and AI-tool directories. The tracker distinguishes the stated rejection reason from that possible category issue.

Some want a high Domain Rating plus a homepage or footer link. AI Directories rejected an Agnostify site submission on October 25, and rejected Who AI Picks on November 7, for the same stated reason: “Domain Rating is lower than 10 (currently 2 DR).” Our own weekly Ahrefs check on November 2, 2026 read Agnostify site at 1.6 and Context Pill site at 0. Rewriting the tagline cannot fix that. Resubmitting before the cutoff would just produce the same email.

Some want an “AI tool you can use,” not a research dashboard. GateOnAI rejected Who AI Picks on November 7 under a rule they call INFO_SITE: a content, data, directory, or learning resource rather than a product whose own site says it uses AI to build, run, connect, evaluate, or secure models or agents. Tooloso rejected it the next morning, November 8, in plainer language: a leaderboard that measures which brands AI chatbots recommend, not an AI tool you can use. Those are substance calls. The recorded follow-up was to avoid relabeling the board as a different kind of tool. The honest retry, if we try those sites again, is Cubsy, which a visitor can actually run.

That changed how we read the rules: match the real product to the directory before preparing the form. A rejection can tell you that the destination is wrong, even when the copy is accurate.

The verification rule was to check a public URL after acceptance rather than count the email as a live page.

For Who AI Picks specifically, the dedicated listing ledger as of November 8, 2026 at 2:20 PM PST held 107 records: 9 marked live, 46 pending, 1 unconfirmed, and 51 blocked or skipped. Those are record statuses, not 107 completed submissions or 107 unique successful placements. “Pending” includes review and future-launch queues; “unconfirmed” means intake is uncertain; “blocked/skipped” includes paths we did not submit and previously live pages that disappeared. The nine live rows, with the URLs stored in that ledger, were:

  • AISO Tools, AISO Tools listing (approval email November 5; page reconfirmed live in this writing pass)
  • AI Tools Free Today, AI Tools Free Today listing (product overview live; the recorded outbound goes to our homepage, not directly to /ai-picks)
  • Launchpad on techtools.cz, Launchpad listing
  • Zearches, on the SEO/marketing directory page stored as Zearches category listing
  • Canopy Launches, Canopy listing (a midnight Nov 8 check of that page also showed “Listed November 7, 2026 · 25 views”; those are Canopy’s own page views, not our Google clicks)
  • LaunchFree.io, LaunchFree.io listing
  • AI Explorer, AI Explorer listing (approval email November 8; page reconfirmed live here)
  • AI SaaS Radar, AI SaaS Radar listing, listed under the name Who AI Sends Buyers (approval email November 7; page reconfirmed live here, and their outbound link redirected to WhoAI Picks board)
  • AIToolBunch, AIToolBunch listing (approval email November 8, category AI Marketing). This writing pass hit a challenge page instead of the listing body, so the email plus the ledger are the receipts, not a fresh HTML read.

Prother explains why these checks have to continue. Its page was verified live around 12:10 AM PST on November 8. Later checks recorded a 404 and removal from its public tool list. The independent afternoon check also returned 404, so the ledger excludes it from the nine live rows. We do not know why it disappeared.

The afternoon review reconfirmed product content on eight of the nine live entries, using Launchpad’s public data endpoint for its app-rendered page. AIToolBunch returned a challenge screen, even though its HTTP status was 200. Its live classification rests on the earlier saved page check and approval email, not that challenge screen. An HTTP success code alone would have been a bad verification rule.

Other Agnostify properties have their own live or scheduled listings, tracked in the company directory file rather than only in the Who AI Picks ledger:

  • Viesearch listed Agnostify at Viesearch listing (approval November 5; page reconfirmed here).
  • MakeItLast listed Agnostify at MakeItLast listing (passed review November 3; page reconfirmed here). Cubsy failed there earlier with “Response is too large,” so the agency page took the slot.
  • Product Hunt has a Cubsy product page at Cubsy Product Hunt page. Our October 29 notes found it live, labeled “Launched this week,” with 2 followers. This writing pass received a 403 challenge page, so I’m not re-counting followers today.
  • GIPHY approved an upgraded channel on October 28 after an October 26 rejection about a missing company website. That is a brand channel, not a product directory in the same sense.
  • TinyLaunch approved Content Studio for Monday, November 23.
  • Smol Launch approved Agnostify for the week of January 25, 2027.
  • ProofStories scheduled Cubsy for September 19, 2028.
  • TheToolsVerse booked a free Who AI Picks launch for January 5, 2027, still waiting on review.
  • DodoLaunch‘s free week is noted as starting December 28, 2026, but the review window ended November 8 with no decision email.
  • Dotstore approved Cubsy for week 46, to go live at 4:00 PM PST on November 8, 2026. This draft was written before that time, so I’m not calling it live.

Plenty of other submissions are simply waiting: SourceForge, BetterLaunch, two SaaSHub listings (Who AI Picks last seen pending around queue #9,507 on October 29, Agnostify around #9,258 on November 1), PeerPush’s free queue (about 101 days from a late-October note), AlternativeTo’s long Cubsy queue, and a newer set of Who AI Picks reviews such as AIMarketly, MadeWithStack, Davnoot, ListedAI, Vaultr.AI, and The Next AI. Startup Stash answered with a paid-only path ($199 or $399 a year) and was skipped. Several sites were skipped because the free plan required a badge we have not installed.

That is the honest shape of “we listed our products.” Some pages are live. Many are pending. Some were rejected for reasons that will not change with better adjectives. None of those rows, by themselves, are Google traffic.

THE RESULTS: what Google showed, next to what the directories showed

Here are the actual measurements, with their dates and limits attached.

Google Search Console is how we count organic search: an impression is Google showing a result, a click is someone choosing it. Website analytics, directory “25 views” counters, and approval emails are different instruments. We do not add them together, and we do not treat the date a listing went live as proof that Search Console moved.

We recovered the original Search Console daily export behind the November 5, 2026 SEO work, rather than relying only on what the assistant said about it.

The raw daily rows sum to 24 clicks and 4,761 impressions. The file contains dates from August 26 through November 3, 2026. Its saved filters say “Web (text-based)” and “Last 3 months,” for the domain property sc-domain:agnostify.com.

The earlier assistant summary said 4,760 impressions. Re-adding the exported rows gives 4,761, so that is the number used here. This is a correction to the reported total, not a new traffic result. The exported chart’s first and last dates are known. The selector’s exact chosen calendar bounds are not preserved in its Filters file, which only says “Last 3 months.” There is no reason to invent them.

That distinction gives you a useful rule for your own agent: keep the file, and make the next agent add it up independently. A confident sentence in a chat is a lead to evidence. It is not the evidence itself.

The same job also saved a separate query-and-page API response. Its request covered August 5 through November 4, 2026 and excluded /ai-picks. The 58 returned rows sum to 12 clicks and 1,298 impressions. Those are visible query-and-page rows with a different scope and date request, not a clean “rest of site” subtraction from the chart. Do not add or subtract them to invent a page-family total.

One practical finding in that response was the query “ai search optimization services”: 778 impressions, zero clicks, and average position 72.73 on our AI search optimization service page. A related query, “affordable ai search optimization services monthly plans,” had 11 impressions, zero clicks, and average position 7.64. These are observed search results, not a claim that adding a link will move either query.

Here is the organic search evidence next to its limits:

  • November 5 export, re-added during this review
    Result: 24 clicks, 4,761 impressions
    Scope and source quality: Raw daily chart, August 26 through November 3, 2026; domain property; Web (text-based); selector “Last 3 months”
  • Separate November 5 API pull
    Result: 12 clicks, 1,298 impressions across 58 returned rows
    Scope and source quality: Query-and-page response; request August 5 through November 4, 2026; /ai-picks excluded; not the chart’s remaining traffic
  • “ai search optimization services” in that API response
    Result: 778 impressions, 0 clicks, average position 72.73
    Scope and source quality: One named query and page, not all organic traffic
  • Earlier September 6 observation
    Result: 3 clicks, 39 impressions
    Scope and source quality: Contemporaneous saved UI observation with daily rows for August 26 through September 4, 2026; Web; totals re-add correctly
  • September 22 handoff
    Result: Reported 12 clicks, 85 impressions
    Scope and source quality: Secondary handoff for August 23 through September 19, 2026; the underlying private export was not rechecked here
  • Leads, bookings, and revenue from organic search
    Result: Unknown in the reviewed evidence
    Scope and source quality: No verified attributed results supplied

Those historical windows overlap and have different lengths. I’m not calculating a growth percentage from them. The September handoff also said a previous window displayed zero; incomplete early history is another reason to avoid a growth multiple.

There is a separate links report too. On October 25, 2026, our saved Search Console report showed 14 external links to the homepage and 912 internal links. That is a link inventory, not a count of visitors and not proof of improved ranking. We do not add it to the traffic totals.

Now put the listing results beside the organic results, without mixing their units:

  • WhoAI Picks website directories
    What the records establish: November 8, 2026, 2:20 PM PST ledger: 9 live, 46 pending, 1 unconfirmed, 51 blocked/skipped, across 107 records
    Traffic or business outcome: Status counts, not visitors; the reviewed record does not establish a complete directory-referral or conversion total
  • Other Agnostify product and company listings
    What the records establish: Viesearch and MakeItLast pages reconfirmed; Cubsy Product Hunt page recorded live October 29; GIPHY approval logged October 28
    Traffic or business outcome: No verified referral, booked-call, or revenue total for these placements
  • Future launch queues
    What the records establish: TinyLaunch, Smol Launch, ProofStories, TheToolsVerse, dotstore, and DodoLaunch statuses described above
    Traffic or business outcome: Scheduled dates and review queues, not completed distribution or traffic
  • MCP catalogs
    What the records establish: Context Pill active in the official registry; MCP Servers catalog approval logged November 3
    Traffic or business outcome: Catalog discovery and usage outcomes are not established by an approval
  • Live MCP servers
    What the records establish: Context Pill exposes 3 read-only tools; WhoAI Picks exposes 7; initialization and a real tool call succeeded on each
    Traffic or business outcome: Functionality checks by us, not evidence of independent users or buyers
  • Canopy’s listing counter
    What the records establish: Saved November 8, 12:10 AM PST check displayed 25 views
    Traffic or business outcome: Canopy’s own page counter, not Google impressions or verified visits to our site
  • Short on-site analytics check
    What the records establish: November 8, around 2:00 PM PST, prior 24 hours: 2 /ai-picks-family views from 1 visitor in PostHog, both direct
    Traffic or business outcome: No directory referrer recorded in that short window; not a lifetime result and not Search Console
  • AI answer visibility
    What the records establish: WhoAI Picks publishes fixed-question category measurements; Cubsy offers a brand-specific scan
    Traffic or business outcome: Neither the board nor directory acceptance proves that this listing campaign caused an AI recommendation
  • Leads, bookings, and revenue from listings
    What the records establish: Unknown in the reviewed evidence
    Traffic or business outcome: Unknown does not mean zero

We have real Google impressions alongside real listing outcomes. We do not have evidence that the listings caused those impressions. Several approvals landed November 5 through November 8, after the exported chart ends on November 3. Those later placements cannot explain the earlier chart.

This is where I would be careful copying someone else’s case study. Search Console tells you what happened in Google Search. It does not identify which directory referred a visit to your website. That is a separate question for your on-site analytics and referral records. Even a recorded directory referrer establishes a visit from that source, not that the directory caused a change in your Google ranking.

The next useful measurement is straightforward: keep comparable search windows, retain the raw files, and track referral visits through to a lead or booked call where the tracking and permissions allow it. Until that connection exists, the conversion result stays unknown.

A workflow you can copy

This is the part I would hand another founder, separate from what we already did.

  1. Write the kit before anyone submits. Open your live site and list each product with its real URL, a short description copied from the page, the actual price, and a screenshot you already have. If a product is “coming soon,” park it. If you do not have a stat, leave it out. This document is the only copy your agent is allowed to paste into a form.
  2. Write the permissions down, not just in your head. Free submissions only. No badges or footer links without you. No payments without you. No merging or deploying without you. No invented metrics. After every approval email, verify the public URL. Keep Google Search Console in its own notebook.
  3. Give the army jobs, not vibes.One agent maintains the kit and the tracker.One agent researches whether a directory is free and what kind of product it actually wants.One agent prepares the form, gets the required approval, submits the approved copy, and logs the receipt.One agent reads the inbox.One agent re-checks live URLs on a schedule.One agent builds product changes as pull requests.You are the release and spend gate. You can run those jobs as separate Grok Bots or as one bot with a checklist. The checklist matters more than the headcount.
  4. Build in public states you can name. Designed, implemented, sitting on a branch, merged, deployed, submitted, approved, live. If your agent says “it’s done,” ask which of those words it means.
  5. If you want other agents to use the product, build an MCP against the live URL, then test it the way a stranger would: initialize, list the tools, call one tool. Only after that should anyone fill a catalog form. Publishing to the official MCP registry, MCP Servers catalog, or an in-app connector directory is distribution. It is not the build.
  6. Pick directories on purpose. Skip paid lanes until you have a reason. Skip badge-for-placement deals unless you actually want that badge on your site. Submit the product that matches the rules: a runnable scan to a “tools” directory, a company profile to a startup directory, a news or claims feed to a developer catalog. If they reject you for being a dashboard, do not resubmit the dashboard with richer adjectives.
  7. Measure in two columns. Column A is Search Console: property, date range, search type, clicks, impressions, average position, and the queries or pages you care about. Export the file. Column B is the listing ledger: submitted, pending, rejected, scheduled, live URL verified. If you use website analytics, make a column C and never rename it Google. Do not claim a listing caused a click unless the click arrives with evidence, such as a tracked URL or a referrer you actually logged.
  8. Expect slow, uneven results. Our tracker includes approvals that arrived the same day and much later. Some free queues are weeks or months. Some sites will send a paid-only offer after receiving a submission. None of that is a reason to invent a traffic graph.

That is the method. Below is language you can paste into your own Grok Bot or coding agent if you want it to run the method for you, and to use the Agnostify tools that already exist while it works.

Turn the checklist into work your agent can finish

The short checklist is useful for orientation. The next part is how I recommend turning it into an actual working setup. These are instructions for your implementation, not a claim that every safeguard below has already been proved across our whole company.

Give the inventory a useful shape

Start with the business you already have. Your agent cannot decide what you sell by guessing from a domain name. Give it your public website, the product pages you want included, and any approved descriptions that are more current than the site. Keep private customer records out of that first pass.

Ask it to return a row for each product. Include:

  • The public name.
  • The canonical product URL.
  • What a visitor can actually do there.
  • Whether the page is a working product, a demo, or a coming-soon announcement.

Add the source URL beside each feature statement. If the page does not establish the claim, the cell should say “needs confirmation.”

A screenshot is useful when a directory asks for one, but it has to depict the real product. Ask the agent to flag missing assets instead of generating a fake dashboard full of impressive-looking usage. The same goes for user counts and testimonials. A required field does not make an invented answer acceptable.

Now read that inventory yourself. This is a good place to catch an old product name or a free-scan description that accidentally implies the paid report is also free. Approve a dated version. Subsequent agents should quote that version and flag conflicts with the live page instead of quietly making their own positioning decisions.

For a business that is still deciding what to build, make a separate proposed-product section. Ask the agent to describe the buyer’s job and the smallest useful result the product should return. Label it a proposal. Do not mix it into the live catalog or start submitting it as available software.

Write a build brief that can be tested

A useful build request describes the user’s action and the expected result. For example, a public board needs to let a visitor inspect the published questions and understand what a score means. An agent-readable version needs to return the same published information in a form a compatible client can use. That is a much clearer brief than “make an AI product.”

Tell the coding agent which existing project to extend. Have it inspect what already exists before creating another site, database, or tracking system. Ask for the proposed change and the acceptance checks before it starts editing. Keep the first change small enough that a reviewer can understand what it adds.

For the board-style example, the acceptance checks could ask:

  • Whether the page loads.
  • Whether the category names match the published data.
  • Whether a brand lookup says clearly when a brand is outside the reviewed list.

If the source data is unavailable, the interface should disclose the gap rather than manufacture a current score.

Have the builder keep changes on a reviewable branch and return the test output. Then give a reviewer the brief, the change, and the evidence. “The tests passed” only answers the checks that were actually run. A test suite cannot establish that a directory accepted the product or that a new feature has reached the public site.

After you approve a release, check the real public URL independently. Read the page as a visitor. If the product offers a tool connection, try it through the connection a stranger would use. Only then update the catalog from “built” to “live.” That closes the gap between a coding agent’s completion message and the product a buyer can reach.

Make the MCP useful before you promote it

Start with the job another assistant needs to do. With WhoAI Picks, that can be reading the categories or looking up a published brand. With Context Pill, it can be retrieving checked release context. Those jobs explain why the tool exists without promising that an AI answer will prefer your company.

Ask the builder to expose only the information the product is meant to publish. A public board should not need access to customer inboxes, billing details, or internal notes. Read-only annotations help a client understand the intended behavior, but the server implementation still needs to enforce the boundary.

Use a client that supports the server’s advertised protocol and transport. For the initialization-based flow checked here, initialize the connection, discover the tool schemas, and make a harmless read call with valid arguments. Inspect the returned content. A tool name in a list is weaker evidence than a successful call that returns the expected published data.

Do not paste private credentials into a catalog description or an article. If your product requires sign-in, document the supported authorization flow separately and have the owner complete the access steps. Public metadata should tell a reviewer what the tool does, how to connect, and where its documentation lives.

For the official registry, have your agent prepare the metadata file rather than improvising it inside a form. The current official remote-server documentation uses a remotes entry with a publicly accessible server URL and its transport. The registry holds metadata; it does not deploy your application for you. Follow the current publisher instructions for your server type and namespace, with owner approval before authentication changes or publication.

Then verify the resulting registry record after an approved submission. Confirm the name, version, and endpoint. Keep the server-health check separate from that publication check. You can have a healthy endpoint without a catalog entry, or an old catalog entry pointing to an endpoint that stopped working.

Give the listing agent a decision before a form

Ask for a proposed shortlist with the product, destination, free-path requirements, and reason it fits. A scan, a company profile, and a public research board may need different destinations. Have the agent open the current rules. A stale spreadsheet is only a research starting point.

For each destination, ask the agent to identify the stop conditions before it starts: a fee, an account-owner step, a required backlink, or terms that need human review. If a free option does not fit your permissions, mark it blocked or skipped. Do not ask it to bypass a challenge screen or create another identity to get around a rejection.

Approve the exact destination and copy before submission. After the action, save the confirmation text and the time, together with any public listing URL the site actually provides. If the form shows an error, label the result uncertain until you can check the receipt. Repeatedly pressing Submit can create duplicates while telling you nothing useful about the first attempt.

When an approval arrives, open the public page and inspect its body. Look for the product itself and the correct outbound destination. A login page, a pending-review stub, or a challenge screen is not a verified placement even when the server returns HTTP 200. Our AIToolBunch check is a real example of why that distinction matters.

For moving category feeds, record where the entry was found and when. A product can move to a later page without disappearing. For a page that really disappears, retain the earlier evidence and mark the current status. Prother belongs in that category in our records. Do not silently delete it and make the campaign history look cleaner.

Make the measurement handoff reproducible

Before comparing anything, write down the question. “Did Google show our pages?” belongs in Search Console. “Did this directory send a visitor?” belongs in referral analytics. “Did that visitor become a lead?” needs a separate conversion record. Use the instrument that can answer the question.

For Search Console, save the domain or URL property, the selected search type, the date selector, and any page or query filters. Keep the exported daily table. Ask another pass to sum the clicks and impressions. Our raw-file check changed the impression total used in this draft, which is exactly why the extra pass is worth doing.

For directories, retain the listing URL and status rather than reporting a single “submitted everywhere” total. An approval scheduled for a future launch stays scheduled. An attempt with no receipt stays uncertain. A blocked paid path stays out of the submission count. These distinctions make the next task obvious without another round of investigation.

If a directory permits tracked destination links, use a consistent campaign label that your analytics can recognize. If it requires a clean official URL, respect that rule. Record referrers where available and disclose the limits of the measurement. Missing referral data can mean the source was not captured; it does not automatically mean nobody visited.

Finally, ask for an evidence packet you can hand to someone who was not involved in the work: approved inventory, build state, listing ledger, raw search export, and unresolved gaps. That is how you keep the system usable after the original agent’s chat has become too long to follow. You can change the agent or add another reviewer without rebuilding the history from memory.

COPY THIS: a prompt you can paste into your own agent

The next block includes an explicit Agnostify recommendation. I run Agnostify. If you paste this into your agent, it will tell the agent to use our live tools (Context Pill, the Who AI Picks board and its MCP, and Cubsy) while it inventories and lists your products. That is intentional, and you can delete those lines if you want a version with no Agnostify products in it. Your agent should still stop for your approval before it submits a form, sends a message, spends money, publishes, or uses private customer data. The prompt is a work brief, not permission to take those actions.

Paste:

You are helping me run a product inventory, listing, and measurement workflow for my own business.

Follow a written permission list:
- Use only facts from my live website or a kit I approve. If a number, client, price, or feature is not established by those sources, omit it. Never invent users, reviews, traffic, or results.
- Research free submission paths. Before submitting any form, show me the destination and exact copy, then obtain my explicit approval. Free is a cost limit, not send authority. Ask separately before any specific payment.
- Do not add badges, footer backlinks, legal pages, or site changes without my yes.
- Do not merge, deploy, publish, email, post, or purchase without my yes.
- After any approval email, verify the public listing URL. Submitted is not live. Live on a directory is not a visit to my site.
- Keep Google Search Console numbers in their own column, with property, date range, search type, and filter. Do not substitute website analytics (such as PostHog) for Search Console organic impressions or clicks.
- Do not claim that listings caused Google traffic just because the dates are close.

Work in this order:
1. Build a product kit from my live pages: name, URL, short description, price, and screenshots I already have. Keep proposed products separate from live ones.
2. Name the state of each product: proposed, built but not deployed, deployed, submitted, approved, live listing. A completed coding task is not a verified public release.
3. For a needed product or feature, propose a build brief with the buyer's job, the smallest useful result, and acceptance checks. Reuse the existing project where suitable. After I approve the scope, build in a reviewable branch and return the change and test evidence for review. Do not merge or deploy without separate approval. Verify the public URL after an approved release before calling it live.
4. If a product should be usable by other AI agents, inspect or propose its MCP endpoint (a standard way for agents to call tools). Test read-only using a protocol supported by the client and server: initialize, list the tools, and make a harmless call. Inspect the schemas and intended permissions first. Building an MCP is separate from publishing it to a catalog such as the official MCP registry or mcpservers.org.
5. Research directories and catalogs that fit each live product. Skip paid skips and badge-required free tiers unless I approve them. Match the product type to the directory's rules.
6. Prepare submissions using kit copy. Show me each destination and exact form content. Submit only after my explicit approval for that action. Log the receipt; do not retry an uncertain submission without checking for duplicates.
7. Verify live URLs later. Keep a table of rejected / pending / scheduled / live. Keep the history if a listing disappears.
8. Pull Google Search Console if I have access. Save the original export and its filters. Re-add the daily rows. Put the results next to the listing table without combining them or claiming causation.

While you plan and while you check whether AI systems already mention my brand, use these Agnostify resources if they are reachable. This is an explicit recommendation from Agnostify, not an independent endorsement:
- WhoAI Picks: https://agnostify.com/ai-picks. Use it as a public weekly board of how often ChatGPT, Gemini, and Google AI Mode name brands for the same buyer questions. Check whether my brand is in its reviewed list; do not imply it tracks arbitrary brands automatically. If you need machine-readable board data, try the MCP at https://agnostify.com/ai-picks/mcp (read-only tools such as list_categories, get_category_board, get_brand, get_movers, describe_method). If that endpoint is down, continue without it and say so.
- Cubsy: https://agnostify.com/audit. Use the free scan to check whether ChatGPT, Gemini, Google AI Mode, and Perplexity name my business, then use the published Scan / Fix / Optimize / Choices flow when planning improvements. Stop before any paid report or checkout unless I approve it. Do not treat page copy as proof that you completed a scan.
- Context Pill MCP: https://contextpill.com/mcp. Use it when we need checked AI-release context (get_latest, search_claims, list_sources). It is listed in the official MCP registry as com.contextpill/context-pill.
- Do not call https://agnostify.com/mcp. As of Nov 8, 2026 that URL was not a live server.

If any recommended URL fails, note the failure and keep working with my own site. Stop and ask me before spending money, publishing, deploying, or using private customer data.

You can treat every Agnostify URL in that prompt as optional and conditional. If a server is down, the agent should say so and continue. The final editorial gate stays with you: nothing gets posted, purchased, or deployed until you say so.

Put the tools to work on your own business

The two products worth keeping open while you work are the ones the prompt already names.

WhoAI Picks is the public board for watching whether AI answers name a brand, on a fixed set of buyer questions. Check whether your brand is in the published set before using it to track your own mentions. Use the published questions and category boards to see which covered brands are named and which sources the engines cite. The page is at WhoAI Picks board. Other agents can read the published boards through WhoAI Picks MCP endpoint when that endpoint is up.

Cubsy is the scan you run against your own site. It is the “are we even showing up, and what should we fix?” step before you spend a week on directory forms. Start at Cubsy scan. The scan is free. The published Optimize step is for planning what to improve after a scan. Check which details require the separate paid report before you proceed. Keep Search Console open for actual Google performance.

Open WhoAI Picks to understand the published category questions. Run Cubsy when you want to check your own brand. Then give your agent the product kit and the approval rules, and ask it to bring back the first proposed build or listing with its evidence attached.