Skip to main content
Glama

ZeroMind (OrigoZero game engine)

world.analytics

Read-only

How a world is actually doing: plays, players, playtime, the funnel from page view to a session that lasted, retention, and what boots are failing on. The same numbers the creator's dashboard shows, so an answer here and an answer there agree. Reads the world this conversation has open, or the one you name with world. Needs maintainer access: a world you have no role on answers not found. view picks the arrangement (series | breakdown | funnel | retention | performance). Ranges are whole UTC days, up to 400 of them, and a range over 120 days comes back bucketed by week. Counts and durations only: there is no per-player row here and never a name, a place or a session. Read clickhouse_configured before you report a zero, because a deployment that records nothing answers zeros.

Input Schema

NameRequiredDescriptionDefault
toNoInclusive UTC end day, YYYY-MM-DD. Defaults to today.
fromNoInclusive UTC start day, YYYY-MM-DD. Defaults to 27 days before `to`, which makes the default window four weeks.
guidNoThe same argument as `world`, under another name: give one of the two. A call giving them two different worlds is refused.
viewNoWhich arrangement of the numbers. Defaults to `series`. `series`: Each metric asked for, day by day over the range, with the range's total and the previous range's total beside it. `breakdown`: One metric split by the dimension it carries (a boot failure's class, a connection class), biggest first, each row with its share of the whole. `funnel`: The steps from opening the world's page to a session that lasted a minute, each step with its share of the step before it. `retention`: How many first-time players came back within a day, a week and a month, with the weekly cohort grid behind those rates. `performance`: Time to first frame, how far boots got through the engine's boot timeline, what the failures were and on what connection.
grainNoBucket size, `day` (default) or `week`. A range over 120 days is served by week whichever you ask for.
worldNoWorld guid. Defaults to the world this conversation has open, so a call after world.open or world.connect needs no argument at all.
metricNoThe ONE metric to split. Required by the `breakdown` view and ignored by the others. The metrics with a breakdown: boot_failed, device, platform, browser, renderer, source, referrer, phase_reached, boot_failed_stage, boot_failed_reason, connection_class.
metricsNoWhich metrics the `series` view answers, as a list or a comma-separated string, at most 32. Left off, you get the eight a dashboard leads with. A name outside the list is refused naming the list, never dropped. The metrics, by group: [overview] plays = Play sessions the engine actually opened on this world that day, not Launch button presses. players = People with an account who played at least once that day, counted once per day however many sessions they opened. anonymous_plays = Play sessions with no account behind them, so no person can be counted for them. agent_plays = Play sessions opened by an agent account rather than a person, kept apart so human numbers stay human numbers. playtime_ms = Time spent in play sessions, as the server measured it from heartbeats and rounded down per session, so it is a floor and never an estimate. avg_session_ms = Playtime divided by plays over the range asked for. long_sessions = Play sessions that lasted at least a minute. abandoned_sessions = Play sessions the reaper closed because the tab died or the network went, rather than the player leaving. [funnel] page_views = Opens of this world's page. card_impressions = Times a card for this world scrolled into somebody's view, counted once per card per page they looked at. card_clicks = Clicks on a card for this world anywhere on the site. launches = Launch presses. An intent to play, which is not yet a play. boot_started = Engine boots that began on this world. boot_rendered = Engine boots that drew their first frame. boot_failed = Engine boots that failed, broken down by the failure class the browser reported. [audience] device = Play sessions by the kind of machine they ran on, across the sessions whose browser said: desktop, mobile, tablet or other. platform = Play sessions by operating system, across the sessions whose browser said: Windows, macOS, Linux, Android, iOS or other. browser = Play sessions by browser, across the sessions that said: Chrome, Firefox, Safari, Edge or other. renderer = Play sessions by what the browser could draw with: a WebGPU adapter, WebGL2 only, or nothing. A world needs WebGPU. [acquisition] source = Play sessions by where the play was reached from, across the sessions that could say: a page on this site, another site, an embed, a shared link or an agent. referrer = Play sessions followed in from another site, by which family of site it was. Never a URL and never a search query. [performance] boot_ms_p50 = Median time from the page committing to a boot to its first frame, merged across the days asked for. boot_ms_p90 = The time to first frame nine boots in ten beat, merged across the days asked for. phase_reached = Boots that reached each stage of the engine's boot timeline; the drop-off is the difference between two stages. boot_failed_stage = Failed boots by the last step of the page's boot they reached: boot_start, boot_bundle, boot_worker, boot_canvas or boot_render. A boot that dies before the engine starts reaches no stage of phase_reached, and this is where it stopped. boot_failed_reason = Failed boots by what failed, finer than the class: the GPU, the network, memory, the engine starting or stopping, and the rest of a closed list. Boots from before reasons were recorded have none. connection_class = Boots by the connection class the browser reported: slow-2g, 2g, 3g or 4g. hidden_share_reports = Visits that reported how much of themselves ran with the tab hidden. The denominator of hidden_share_bp. hidden_share_bp_sum = Those visits' hidden shares added together, in basis points. The numerator of hidden_share_bp, and meaningless on its own. hidden_share_bp = The average share of a visit spent with the tab hidden, across the visits that reported one. [community] votes_up = Upvotes cast on this world. votes_down = Downvotes cast on this world. votes_cleared = Votes on this world that were taken back. ratings_liked = People who said they enjoyed this world. ratings_indifferent = People who said this world left them indifferent. ratings_disliked = People who said they did not enjoy this world. comments = Comments left on this world, threads and replies together. bookmarks_on = Times this world was bookmarked. bookmarks_off = Times a bookmark on this world was removed. follows_on = Times somebody started following this world. follows_off = Times somebody stopped following this world. reports = Reports filed against this world. A count only: the reason is never shown here. forks = Times this world was forked into a new one. [building] publishes = Commits finalized on this world. edit_sessions = Editor sessions opened on this world. edit_time_ms = Time spent in the editor on this world, measured the same way playtime is. chat_turns = Agent turns run against this world. chat_credits = Credits those agent turns spent, as a positive number. prs_opened = Pull requests opened against this world. prs_merged = Pull requests merged into this world. [reach] egress_bytes = Bytes of this world's content served out of the blob store.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already mark readOnly/openWorld/non-destructive, but the description adds substantial behavior beyond that: the 400-day cap, weekly bucketing past 120 days, the no-per-player/no-name/no-place guarantee, auth failure mode returning not-found, and the zero-vs-unconfigured caveat. This is exactly the extra context annotations cannot carry.

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-loads the purpose, then layers scope, auth, view, ranges, exclusions, and the zero caveat in dense but non-redundant sentences. It is long, but the bulk of the metric enumeration lives in the schema rather than the description, so little is wasted here.

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?

With no output schema and 8 parameters, the description carries the load well: it describes what is returned (counts and durations, funnel/retention/performance arrangements), the aggregation constraints, access requirements, and the caveat that a zero may mean unconfigured rather than inactive. Nothing an agent needs to call it correctly is missing.

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 description coverage is 100% and the schema itself is extraordinarily rich, documenting every parameter, enum, and metric semantics. The description's parameter content (view arrangement, default four-week window, breakdown-only metric) largely restates the schema, so it adds only marginal meaning beyond it.

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?

Opens with a specific verb+resource framing ("How a world is actually doing: plays, players, playtime, the funnel... retention... what boots are failing on"), and explicitly scopes itself against dashboard parity. An agent can immediately tell this is the read-only analytics surface, not world.list/open/manage siblings.

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?

Clear about when the tool works: reads the conversation's open world or one named with `world`, requires maintainer access (no role -> not found), and warns to check `clickhouse_configured` before reporting a zero. It gives prerequisites and context but names no explicit alternative sibling or when-not-to-use condition.

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.