When Tools Don't Register

The Tool Registration Check on your site's dashboard page opens your site in a real browser, waits for the WebMCP runtime, and asks it which tools are present. When something is missing, it names the cause and shows what it observed under What we saw. This page explains each cause and what to do about it.

You can run the check yourself at any time with Check now. It also runs on its own whenever you create, edit, or accept a tool.

The page never loaded our snippet

The browser recorded every request the page made, and none of them was for mcp-manager.js. The script tag is not on the page, or something kept it from running.

Work through these in order:

  1. View the page source (not the element inspector) and search for mcp-manager.js. The inspector shows the page after scripts have run; the source shows what your server actually sent.
  2. Check your cookie banner. Consent tools routinely rewrite third-party script tags to type="text/plain" until a visitor accepts, and our checker never clicks the banner. If our snippet is categorised as marketing or statistics, move it to the essential/functional category, or exclude it from consent blocking.
  3. On Shopify, open your theme and confirm the Aigentably app embed is switched on. Switching to a different theme leaves it off in the new one.
  4. Check which URL was tested. The check loads the site URL stored in your dashboard. If you installed the snippet on one page only, that page has to be the one we check.

The script tag points at a site we don't have

The snippet loaded, asked us for its tools, and we answered 404. The site= parameter in the script tag matches no site in your account.

Copy the tag from this site's dashboard page again and replace the one on your page. This usually happens after a site is deleted and re-added, or when a tag from another site was pasted by mistake.

The WebMCP runtime was blocked

Our snippet ran and asked the browser to load the WebMCP runtime, which never arrived. Without it there is nothing for tools to register on.

The usual cause is a Content-Security-Policy. If your site sends one, script-src has to include the domain the snippet comes from:

Content-Security-Policy: script-src 'self' https://aigentably.com;

We serve the runtime from the same domain as the snippet itself, so one entry covers both. Reload the page with the browser console open: a CSP refusal prints the exact directive that rejected the script.

If you are not sure whether you have a CSP, search your server, framework, or CDN configuration for Content-Security-Policy. Several hosting providers add one by default.

The snippet ran, but WebMCP never came up

Everything loaded and document.modelContext still never appeared. This is usually another script on the page failing earlier and taking ours down with it, or a second WebMCP implementation competing for the same object.

Open the page with the console open and look for errors that fire before ours. If nothing is obvious, send us the URL and the console output; this one is hard to see from the outside.

Some tools did not register

WebMCP came up and other tools registered, so the installation is fine. The ones listed with a red mark were rejected individually, usually because of an input schema the runtime would not accept, or an error thrown while registering.

We start generating a fix for each failed tool automatically, at no cost to your quota, because our own check found the problem rather than you asking for a rewrite. Come back in a minute and review the proposal.

You can also open a failing tool and use Test to run it against your page. The error it returns is normally the whole story.

This page is on your exclusion list

Not a fault. The page we checked matches a path in the site's exclusion settings, so the snippet stopped there on purpose and no tools were meant to register.

Remember that an excluded path covers everything below it: /checkout also excludes /checkout/payment.

The page answered with an error

We opened your site and the server answered 4xx or 5xx, so there was no page to check. A staging password, a Shopify store password, a maintenance page, or a bot filter all look like this.

Open the site in a private window to confirm it loads for an anonymous visitor. If a firewall or bot filter sits in front of it, allow our checker: it sends a normal Chrome user agent with Aigentably-ToolCheck/1.0 appended.

What the check does not cover

  • Page-scoped tools. The check only loads your site's main URL, so a tool restricted to /products/* is reported as skipped rather than failed. Use Test on a matching page for those.
  • Whether a tool works. Registration means an agent can see the tool and its schema. It says nothing about whether the code inside does the right thing. That is what testing a tool is for.