Skip to main content
Glama
Sign In

OneLence

by com.onelence
OverviewDiscussionsAdmin

Send a test event

onelence_send_test_event

Sends one test event for a site through the same ingest path as its tracking, flagged internal like staff and QA traffic (it can still show in the events list). Then verify tracking with that event name: if it arrives, ingest accepts the site and its key. It does not show that the site's own pages send events. Default event name ol_test_event. Two steps: call with the change to get a summary and a confirmation_id, show the summary to the user, and only after they agree call again with just confirmation_id.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "onelence_send_test_event"
  }
}

Input Schema

NameRequiredDescriptionDefault
siteNoSite domain (e.g. example.com) or site id. Defaults to the workspace's newest active site.
event_nameNoDefault ol_test_event.
confirmation_idNoOnly when applying: the confirmation_id from the preview, after the user agreed.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false), the description discloses that the event is flagged internal like staff/QA traffic, that it can still appear in the events list, and that the call is a two-phase preview-then-apply operation. This is exactly the behavioral context annotations cannot convey.

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 action and the verification caveat, and every sentence carries information. Some sentences are dense and run together (the ingest/flagging clause), which slightly hurts scannability.

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

Completeness5/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 needn't be described, and the description still explains that the first call yields a summary and confirmation_id. For a 3-param, zero-required tool with full schema coverage, nothing an agent needs is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains the confirmation_id workflow ('call again with just confirmation_id') and restates the default event name in context. It stops short of explaining the site default resolution, which the schema already covers.

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 ('Sends one test event for a site') and immediately scopes it to the ingest path, distinguishing it from siblings like onelence_verify_tracking and onelence_list_events. An agent can tell what it does 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 Guidelines5/5

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

Explicitly frames the use case (verify tracking with that event name), states the exclusion ('It does not show that the site's own pages send events'), and prescribes the two-step preview/confirm flow. Alternatives and when-not conditions are both covered.

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

All OneLence toolsInspect
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