Tracklution

Get installation scripts

get_installation_scripts

Read-only

Returns paste-safe tracking snippets, webhook templates, recommended events, common mistakes and verification instructions for a framework. framework_snippets keys: init and page_view (always needed), purchase (checkout / order-success flow, has_checkout=true), lead (lead-gen funnel), contact_info (authenticated user views, has_login=true). Without contact_info on a site with login, verify_and_score keeps verification.scoring_complete=false. common_mistakes[] per snippet are optimal-vs-acceptable notes, not breakage warnings: the tracker deduplicates repeat purchases, accepts late ContactInfo and absorbs React Strict Mode double-fires. The _sensitive_webhook block carries a live URL and appears only in structuredContent.

Input Schema

Name	Required	Description	Default
`framework`	Yes
`has_login`	No
`auth_token`	No	SENSITIVE: JWT from register_and_provision. Optional when `container_hash` is supplied — the MCP server then auto-attaches the JWT cached at register time. Pass this explicitly when you have it from structuredContent.
`event_goal`	No
`server_name`	No	Which 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.
`app_dir_path`	No		src/app
`container_id`	Yes
`has_checkout`	No
`container_hash`	No	SECRET: 32-char hash from register_and_provision's data.container.hash. Required ONLY when auth_token is omitted; lets the MCP server look up the cached JWT without exposing it on the wire.
`nextjs_version`	No

Output Schema

Name	Required	Description	Default
`data`	No
`field`	No
`errors`	No
`status`	No
`details`	No
`warnings`	No
`rate_limit`	No
`http_status`	No
`next_action`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 21, 2026
- removedOutput schema / properties / _request_id
```
Removed value: -{
-  "type": "string"
-}
```
AddedOct 13, 2026
RemovedOct 13, 2026
First observedSep 18, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already establish read-only, non-destructive, non-open-world behavior. The description adds real value beyond that: the `_sensitive_webhook` block carries a live URL and only appears in `structuredContent`, and it clarifies that `common_mistakes[]` are optimal-vs-acceptable notes rather than breakage warnings, preventing an agent from over-reacting to them.

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?

Front-loaded with the core purpose, then organized by output key with backtick notation. Dense but every clause carries meaning; the jargon-heavy style is efficient rather than padded.

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?

An output schema exists, so return values need not be re-explained, yet the description adds useful structural hints about keys and where sensitive data lives. For a 10-parameter tool it leaves some parameter-level gaps, but covers the behavioral and output-shape essentials an agent needs.

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?

Schema coverage is only 30%, so the description must compensate. It does explain the conditional flags (`has_checkout`, `has_login`) and indirectly maps `event_goal` values to `framework_snippets` keys, but several parameters (`app_dir_path`, `nextjs_version`, `container_id`, `event_goal` semantics) remain undocumented in the description.

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?

States a specific verb and resource — returns paste-safe tracking snippets, webhook templates, recommended events, mistakes, and verification instructions for a framework. An agent can distinguish this from siblings like select_installation_method or verify_and_score 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 Guidelines3/5

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

Usage is implied rather than stated: the conditional notes (`has_checkout=true` for purchase, `has_login=true` for contact_info) and the link to `verify_and_score` scoring hint at the workflow, but there is no explicit 'call this after X' or 'use this instead of Y' guidance against the many sibling installation tools.

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

All Tracklution tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?