Skip to main content
Glama

Live

onelence_get_live
Read-onlyIdempotent

What is happening right now: active visitors, events and conversions in the last few minutes (default 30, from 5 to 240). complete is false when the window held more activity than one snapshot reads, so the counts are lower bounds. Use it to watch a launch or a campaign going live; to check that a specific event arrives use onelence_verify_tracking, and for a period use onelence_get_performance.

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_get_live"
  }
}

Input Schema

NameRequiredDescriptionDefault
siteNoSite domain (e.g. example.com) or site id. Defaults to the workspace's newest active site.
minutesNo

Output Schema

NameRequiredDescriptionDefault
noteYes
siteYes
eventsYes
objectYes
completeYes
conversionsYes
window_minutesYes
active_visitorsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "active_visitors": {
      +      "anyOf": [
      +        {
      +          "type": "number"
      +        },
      +        {
      +          "type": "null"
      +        }
      +      ]
      +    },
      +    "complete": {
      +      "type": "boolean"
      +    },
      +    "conversions": {
      +      "anyOf": [
      +        {
      +          "type": "number"
      +        },
      +        {
      +          "type": "null"
      +        }
      +      ]
      +    },
      +    "events": {
      +      "anyOf": [
      +        {
      +          "type": "number"
      +        },
      +        {
      +          "type": "null"
      +        }
      +      ]
      +    },
      +    "note": {
      +      "type": "string"
      +    },
      +    "object": {
      +      "const": "live",
      +      "type": "string"
      +    },
      +    "site": {
      +      "properties": {
      +        "domain": {
      +          "type": "string"
      +        },
      +        "id": {
      +          "type": "string"
      +        }
      +      },
      +      "required": [
      +        "id",
      +        "domain"
      +      ],
      +      "type": "object"
      +    },
      +    "window_minutes": {
      +      "type": "number"
      +    }
      +  },
      +  "required": [
      +    "object",
      +    "note",
      +    "site",
      +    "window_minutes",
      +    "active_visitors",
      +    "events",
      +    "conversions",
      +    "complete"
      +  ],
      +  "type": "object"
      +}
  2. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare this a safe, idempotent, closed read, so the safety burden is light. The description still adds non-obvious behavior beyond the annotations: a `complete` flag that signals truncation and the caveat that returned counts are lower bounds when the window overflowed a single snapshot. It stops short of saying how the snapshot boundary is determined or whether results are cached, so it is strong but not exhaustive.

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?

Three sentences, front-loaded with the core meaning and the truncation caveat placed before the routing guidance. The parenthetical "(default 30, from 5 to 240)" partly duplicates schema bounds, but every sentence still carries routing or interpretation value.

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?

With an output schema present, return values need not be explained, and the description covers what matters for correct interpretation: recency window, truncation via `complete`, and lower-bound counts. What remains unstated are snapshot latency/size and whether counts are approximate by design, which would help an agent judge trustworthiness of the numbers.

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 50%: `site` is documented in-schema but `minutes` is not. The description compensates by supplying the missing default (30 minutes) and restating the 5–240 window, which is the key semantic an agent needs to size the query. Minor overlap with the schema's min/max, but it fills the actual gap.

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 description opens with a specific verb-and-resource framing ("What is happening right now: active visitors, events and conversions in the last few minutes") and immediately scopes it against two siblings, onelence_get_performance (period) and onelence_verify_tracking (single event). An agent can place it in the toolset without reading any 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?

It gives a positive use case ("watch a launch or a campaign going live") and names two explicit alternatives with the conditions that select them: event-arrival checks go to onelence_verify_tracking, period analysis goes to onelence_get_performance. Both when-to-use and when-not-to-use are present.

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.