Skip to main content
Glama

Tracklution

verify_and_score

Force-process recent events, recalculate scoring, and return a strict verification diagnosis. Mutating — requires an agent-supplied idempotency_key. Every response includes _request_id in structuredContent.

COMPLETION CONTRACT (read this every time): The success signal is the envelope's top-level status, NOT verification.scoring_complete. A fresh install can sit at scoring_complete=false indefinitely because of organic metrics (e.g. recovery-rate-based scoring) that mature only as real traffic accumulates — using scoring_complete as the completion gate would mean no install ever appears done. Use status + verification.not_ready_reason (equivalently: not_ready_reason === null) as the gate.

READING status + verification.not_ready_reason — three behavioral classes:

(A) DONE / hand-off-to-user (no retry, transition to Turn 5 scored hand-off):

  • status='ok' (not_ready_reason === null) — install complete on both sides. Call get_next_steps to grab overall_progress + next_steps[], then create_login_link (target_page=dashboard), then send the Turn 5 scored hand-off (see agent-install.md Step 5).

  • not_ready_reason='awaiting_connector_activation' — your code is done; user activates connector in dashboard. Call create_login_link (target_page=connectors), send the scored hand-off naming the connector step, and EXIT. retry.max_retries_recommended === 0.

  • not_ready_reason='awaiting_first_party_mode' — same shape, target_page=dns. EXIT.

  • SERVER RULE for the hand-off: on the main Tracklution server call create_login_link; on any OTHER connected server next_action.tool is null and data.manual_handoff names the server — tell the user to open that server's dashboard and STOP. Never call create_login_link for a container on another server; the MCP refuses it (container_pinned_to_other_server).

  • not_ready_reason='only_pageview_seen' — code is in, loader works, only PageView received. This is the EXPECTED day-0 state for a fresh install: the user hasn't performed a Purchase/Lead yet, and a 30-second wait will NOT make them click 'Buy' on their own site. Do NOT retry. Transition to the Turn 5 scored hand-off, surface the score, and instruct the user to trigger a real event on the live site, then reply verify for a re-check.

  • not_ready_reason='missing_bottom_funnel_event' — same semantics as only_pageview_seen (no bottom-funnel event yet). Do NOT retry. Transition to scored hand-off; user must trigger the missing event on the live site.

(B) TRANSIENT / retry with budget (3 × 30s, then graceful exit):

  • not_ready_reason='no_events_after_install' — loader hasn't reported yet (post-deploy delay or local-dev environment). Retry per retry.retry_after_seconds / retry.max_retries_recommended. On budget exhaustion, transition to the Turn 5 scored hand-off with events haven't arrived yet — trigger a PageView on the site and reply 'verify' instead of declaring failure.

  • not_ready_reason='script_not_seen' — bootstrap script not loaded. Same retry shape as above.

  • not_ready_reason='event_not_received_yet' — a specific expected_event hasn't arrived. Same retry shape.

  • not_ready_reason='events_processing' — initial-calculate race. Same retry shape; on exhaustion say events are flowing; final scoring will catch up within a few minutes and exit.

(C) CODE-FIX / retry ONCE after fix (do not loop):

  • not_ready_reason='missing_contact_info'tlq('set','ContactInfo',...) not seen. Apply the missing snippet (see get_installation_scripts.framework_snippets.contact_info), then call this tool ONCE more. If still missing, transition to scored hand-off; the next_steps list will name implement_contact_info as a remaining task.

  • not_ready_reason='domain_mismatch' — events arrived from the wrong host. Inspect deploy target, fix, retry ONCE. On failure, transition to scored hand-off.

DATA FIELDS YOU MUST READ:

  • data.event_names_seen[] — distinct track-type events received (PageView, Purchase, Lead, ...).

  • data.set_events_seen[] — distinct set-type metadata received (ContactInfo, ...). Do NOT expect ContactInfo to appear in event_names_seen; it lives ONLY in set_events_seen because tlq('set', 'ContactInfo', ...) is metadata, not an event.

  • data.verification.not_ready_reason — stable enum, full list: no_events_after_install, event_not_received_yet, script_not_seen, only_pageview_seen, missing_bottom_funnel_event, missing_contact_info, domain_mismatch, awaiting_connector_activation, awaiting_first_party_mode, events_processing. Map verbatim to user-friendly copy via verification.message.

IDEMPOTENCY: use the SAME idempotency_key to dedupe within a 30s window (returns the cached response). Use a FRESH idempotency_key after the window to trigger a new force-process pass over recent events.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
auth_tokenNo
server_nameNoWhich connected Tracklution server the container lives on (the server name shown at Connect time, e.g. `Main`). Required when this MCP session is connected to more than one server; pass the SAME server_name on every follow-up installation call for the container — the MCP fills it into `next_action.args` / `next_steps[].tool_args` for you. Ignored when only one server is connected.
container_idYes
container_hashNoSECRET: required when auth_token is omitted. See get_installation_scripts for the rationale.
expected_domainNo
expected_eventsNo
idempotency_keyYes
onboarding_session_idNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataNo
fieldNo
errorsNo
statusNo
detailsNo
warningsNo
rate_limitNo
_request_idNo
http_statusNo
next_actionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden and does it thoroughly: it discloses mutation, the force-process behavior, the 30-second idempotency dedupe window, the success-signal trap (`status` vs `scoring_complete`), the server-pinning refusal rule, and the full stable enum of `not_ready_reason`. This goes far beyond a typical tool description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long, but the length is justified by a ten-value state machine and explicit action contract; it is front-loaded with a one-line purpose, then organized into labeled classes and bullets. It is not truly concise, but every section earns its place for this tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the operational context an agent needs: which output fields to read, how to interpret `status` + `not_ready_reason`, when to retry vs exit, and which sibling tools to call for hand-off. It omits guidance on several input parameters and relies on an external `agent-install.md` reference, but for this complex verification flow it is substantially complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds real semantic value for `idempotency_key` (same key dedupes within 30s, fresh key triggers a new pass) and implies the role of `expected_events` via the `event_not_received_yet` case. With only 25% schema coverage and six parameters left unexplained by both schema and description, however, it does not fully compensate for the low coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names a specific verb/resource outcome: 'Force-process recent events, recalculate scoring, and return a strict verification diagnosis.' It also flags the mutating nature, which separates it from read-only sibling status/summary tools, so an agent can distinguish it without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides an exhaustive decision tree for every `not_ready_reason`, including retry budgets, 'do NOT retry' rules, and explicit follow-up sibling calls (`get_next_steps`, `create_login_link`). It does not, however, explicitly contrast this tool with alternative status/verification tools such as `get_status`, leaving a small inference gap.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources