Troubleshooting and Known Ambiguity
Good docs should not hide ambiguity. This page collects the known edges where teams may hit rollout questions, language drift, or partially confirmed behavior so the Knowledge Base stays honest and operationally useful.
Project key and active pack access
The current docs truth confirms project-key authentication for telemetry ingestion. It does not confirm a blanket rule that active pointer or artifact access always requires the project key.
When teams ask whether project-key possession is the gating requirement for runtime delivery, docs should answer carefully: that behavior remains ambiguous and should be manually validated in the deployment context.
Verification ambiguity
Verification is a modeled concept, but the audited truth does not support strong claims about a separate mature execution-time verification subsystem for HTTP or Hook runs.
If a team is troubleshooting execution quality, focus first on schema alignment, runtime outcomes, and telemetry-backed health rather than assuming there is a larger hidden verification engine making the decision.
Current Artifact is a UI term first
Current Artifact should be read as the artifact file for the active version. That is the stable explanation that matches the docs truth.
Troubleshooting gets harder when teams treat Current Artifact as if it were an independent backend resource with separate lifecycle rules. Keep the term anchored to active version state.
Same-hostname cross-project behavior
Multiple domains per project are confirmed. Global hostname uniqueness across projects is not. The current truth suggests uniqueness is scoped per project, but same-hostname behavior across multiple projects is still an area where docs should not overclaim.
If this matters in rollout planning, teams should test the exact project and hostname combination rather than relying on a stronger uniqueness assumption from the docs.
Old terminology drift
- Use tool as the main external noun, even if older implementation surfaces still mention manual tool or capability.
- Use pack for the release bundle and artifact for the signed JSON file, even if older language blurs those concepts together.
- Define Current Artifact explicitly rather than assuming users will infer it correctly from old UI wording.
- Avoid scanner-first language when writing knowledge-base docs for the current WebMCP tool platform.
A practical troubleshooting order
- 1
Check project and domain scope
Confirm the right project owns the domains and tools you expect the runtime to load.
- 2
Check publish and active version state
Make sure the expected version is active before you chase runtime behavior.
- 3
Check runtime delivery
Inspect active-pointer resolution, artifact fetch, signature verification, and eligibility-based registration.
- 4
Check telemetry-backed health
Use analytics and tool health to see whether failures are happening at runtime even when setup looked correct.