Troubleshooting 

Everything in the extension degrades silently on purpose — a missing manifest, an absent ModelContext or a malformed config simply registers nothing. That is good for visitors but means failures are quiet. Expand the symptom that matches and work through the checks in order.

Check, from the outside in:

  1. Is the JSON block on the page? View source and look for <script type="application/json" id="webmcp-config">. In the console:

    Console — read the config block
    document.getElementById('webmcp-config')?.textContent
    Copied!

    Empty or missing → the manifest was not rendered. Verify the Fluid snippet (Step 2 in Quickstart) is in your template and that the variable name matches the data processor's as (default webmcpConfigJson).

  2. Does the block contain your tool?

    Console — list the registered tools
    JSON.parse(document.getElementById('webmcp-config').textContent).tools
    Copied!

    Empty array → no provider yielded a manifest. Either the provider is not registered (see the next item) or its manifest() returned null for this request.

  3. Is the runtime loaded? Confirm webmcp.js is included in the page footer (the includeJSFooter TypoScript).
  4. Is there a ModelContext to register against?

    Console — check for an agent surface
    document.modelContext || navigator.modelContext
    Copied!

    undefined in both → the browser has no agent surface. This is expected in a normal browser; the runtime intentionally does nothing. Test with an agent-capable client or Chrome with the WebMCP origin trial enabled.

The provider is a service tagged webmcp.tool. If it is not picked up:

  • Confirm your extension enables autoconfiguration in Configuration/Services.yaml (_defaults with autoconfigure: true). The tag is inherited from the interface's #[AutoconfigureTag('webmcp.tool')] only when autoconfiguration is on.
  • Otherwise tag the service manually (see the note in Quickstart).
  • Clear the TYPO3 caches after adding a new service.

Providers receive $processedData from data processors that ran before the \Neoblack\Webmcp\DataProcessing\ToolManifestProcessor in the same content object. If your provider builds on, say, a MenuProcessor output, that processor must have a lower key so it runs first (see the ordered example in Configuration).

  • Is analytics enabled? Check analyticsEnabled in the extension configuration. When off, /webmcp-event is passed through and nothing is stored.
  • Is the tool name whitelisted? Only names returned by a registered provider's name() are logged, and name() must equal the Manifest name. A mismatch silently drops the event.
  • Getting 429s? You are hitting the rate limit (analyticsRateLimit calls per IP per minute). Raise it or set 0 to disable — see Analytics.
  • Getting 204 but no row? A 204 is also returned for cross-site posts rejected by the Sec-Fetch-Site guard and for the normal success path. Confirm the beacon is a genuine same-origin POST to /webmcp-event.

Tool values are embedded verbatim inside a <script> block. The processor escapes < > & ' " as \uXXXX (JSON_HEX_*), so a </script> inside an editor-controlled value cannot break out.