GenHTTP Lambda

Read who visits a lambda

analytics

DestructiveIdempotent

How people reach a lambda, as its owner sees it in the editor: visitors, pages opened and requests per day, and the pages, referring sites, countries, devices, browsers, operating systems and crawlers (search engines, AIs, link previews) behind them. Counted by day in UTC and written down every few minutes; a year is kept, of which a free lambda shows the last 7 days and a premium one all. Off until switched on - nothing is counted before. enable: true switches it on, only when the user asks; switching off deletes what was counted and is the owner's to do in the editor. Use it to answer what the user asks about their visitors, or to see which pages matter before changing them.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "privateKey": "<privateKey>"
    },
    "name": "analytics"
  }
}

Input Schema

Name	Required	Description
`days`	No	How many days, today included. Left out, as many as the lambda's tier shows, which is also the most.
`enable`	No	Switch analytics on, counting from the next request - only when the user asked for it.
`privateKey`	Yes	The editor key.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 2, 2026
- changedInput schema / properties / days / type
```
Previous value: -"integer"New value: +[
+  "integer",
+  "null"
+]
```
- addedInput schema / properties / enable / default
```
Added value: +false
```
AddedOct 12, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations (readOnlyHint=false, destructiveHint=true, idempotentHint=true) leave the destructive flag unexplained, and the description fills that gap well: counting is off until enabled, nothing is counted beforehand, enabling starts from the next request, and switching off deletes the collected data. It also discloses UTC day bucketing, a few-minute write cadence, and tier-based retention (7 days free, a year premium). It stops short of clarifying whether this tool itself can delete anything, leaving a small ambiguity against destructiveHint=true.

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

Conciseness3/5

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

The payload is real and front-loaded, but the first sentence is a long comma-chained list and the cadence/UTC/retention details are crammed into a second dense sentence. Structure is serviceable rather than clean; several clauses could be tightened without losing information.

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 no output schema, the description carries the burden of describing what comes back, and it does so thoroughly, including granularity, retention and the enable lifecycle. The only residual gap is the exact relationship between the tool's destructiveHint and the fact that disabling happens elsewhere.

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; the description still adds value by tying the default day count to the tier ceiling and by restricting enable to an explicit user request. The privateKey is not discussed, but the schema covers it adequately.

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

Purpose4/5

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

The opening sentence names the resource and enumerates exactly what is returned: visitors, pages opened, requests per day, plus referrers, countries, devices, browsers, OS and crawlers. It is a read tool for site analytics, clearly distinct from read_logs or read_database in substance, although no sibling is named to make the distinction explicit.

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?

"Use it to answer what the user asks about their visitors, or to see which pages matter before changing them" gives concrete usage contexts, and the enable guidance is conditional and explicit ("only when the user asks"). It also warns that disabling is not this tool's job but the owner's in the editor. No sibling comparison is offered, which keeps it from a 5.

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

All GenHTTP Lambda tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.