spawnpoint

Get project visits

get_project_visits

Read-onlyIdempotent

Report who has opened a spawnpoint project, per invited email: whether they have actually opened it, when first and last (RFC3339), and a visit count (activity is counted at most once a minute, so this is sessions-ish, not page views). An invited email with no first_opened has never opened the link. A domain shared as @company.com has a row marked domain, and each person at it who opened the link has a row of their own with via naming the domain. Viewers appear here by verifying their email at the gate, so for a restricted project this is the complete answer to "did they look at it". Visits without signing in (a public project, or a restricted one's public paths) are in public_traffic: page views and visitors per UTC day over the last 30 days, and the sites visitors came from. A visitor there is an approximate count of one address and browser on one day, nobody's identity; for how many people came, give visitors_in_window as a range, never the days added up.

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": {
      "project_id": "<project_id>"
    },
    "name": "get_project_visits"
  }
}

Input Schema

Name	Required	Description	Default
`project_id`	Yes	the id of the project to fetch

Output Schema

Name	Required	Description	Default
`note`	No
`viewers`	Yes
`project_id`	Yes
`visibility`	Yes
`public_paths`	No
`public_traffic`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 13, 2026

addedOutput schema / properties / public_traffic

Added value: +{
+  "properties": {
+    "days": {
+      "items": {
+        "properties": {
+          "day": {
+            "type": "string"
+          },
+          "views": {
+            "type": "integer"
+          },
+          "visitors": {
+            "type": "integer"
+          },
+          "visitors_incomplete": {
+            "type": "boolean"
+          }
+        },
+        "required": [
+          "day",
+          "visitors",
+          "views"
+        ],
+        "type": "object"
+      },
+      "type": [
+        "null",
+        "array"
+      ]
+    },
+    "from": {
+      "type": "string"
+    },
+    "note": {
+      "type": "string"
+    },
+    "referrers": {
+      "items": {
+        "properties": {
+          "host": {
+            "type": "string"
+          },
+          "views": {
+            "type": "integer"
+          }
+        },
+        "required": [
+          "host",
+          "views"
+        ],
+        "type": "object"
+      },
+      "type": [
+        "null",
+        "array"
+      ]
+    },
+    "to": {
+      "type": "string"
+    },
+    "views_today": {
+      "type": "integer"
+    },
+    "visitors_in_window": {
+      "properties": {
+        "at_least": {
+          "type": "integer"
+        },
+        "at_most": {
+          "type": [
+            "null",
+            "integer"
+          ]
+        }
+      },
+      "required": [
+        "at_least"
+      ],
+      "type": [
+        "null",
+        "object"
+      ]
+    },
+    "visitors_today": {
+      "type": "integer"
+    },
+    "visitors_today_incomplete": {
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "from",
+    "to",
+    "visitors_today",
+    "views_today",
+    "days",
+    "referrers",
+    "note"
+  ],
+  "type": [
+    "null",
+    "object"
+  ]
+}

Changed1 schema field changedNov 9, 2026

addedOutput schema / properties / public_paths

Added value: +{
+  "items": {
+    "properties": {
+      "failed_7_days": {
+        "type": "integer"
+      },
+      "failed_today": {
+        "type": "integer"
+      },
+      "last_request": {
+        "type": "string"
+      },
+      "path": {
+        "type": "string"
+      },
+      "requests_7_days": {
+        "type": "integer"
+      },
+      "requests_today": {
+        "type": "integer"
+      }
+    },
+    "required": [
+      "path",
+      "requests_today",
+      "failed_today",
+      "requests_7_days",
+      "failed_7_days"
+    ],
+    "type": "object"
+  },
+  "type": [
+    "null",
+    "array"
+  ]
+}

First observedOct 18, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Goes well past the readOnly/destructive annotations by disclosing counting semantics (activity counted at most once per minute, so 'sessions-ish, not page views'), the meaning of a domain row and its 'via' child rows, and that an absent first_opened means never opened. It also warns that public_traffic visitors are approximate and must be reported as visitors_in_window rather than summed — the kind of interpretation guidance an agent could not infer from the schema.

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

Conciseness5/5

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

placeholder

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?

Given a read-only tool with rich return semantics, the description covers everything an agent needs to interpret the response correctly, including the caveat that anonymous visitor counts are approximate address/browser/day estimates. Nothing material is missing for correct use.

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?

Only one parameter, project_id, and schema description coverage is 100%, so the input side is fully documented in structured data. The description adds no additional meaning about project_id itself; its added value is entirely on the output semantics side, which the output schema already covers.

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?

Opens with a concrete verb+resource: 'Report who has opened a spawnpoint project, per invited email,' which tells an agent exactly what data comes back. It never explicitly names a sibling (e.g., get_project_logs) to contrast against, so the differentiation is inferred from the subject matter rather than stated.

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?

Gives a clear decision rule for interpreting results ('for a restricted project this is the complete answer to "did they look at it"') and separates signed-in visits from anonymous traffic within the same response. It does not state when to prefer it over a sibling analytics/log tool, but the context for calling it is unambiguous.

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

All spawnpoint 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.