rybbit-mcp

Get Site ID by Domain

rybbit_get_site_id

Read-onlyIdempotent

Look up a site by domain name to get the numeric siteId required for Rybbit Analytics API queries. For SDK tracking setup, use the hash siteId from site creation instead.

Instructions

Look up a site by domain name. Returns the numeric siteId used for analytics API queries. Note: for SDK tracking setup, use the hash siteId returned by rybbit_create_site instead.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`domain`	Yes	Domain to search for (e.g. 'example.com'). Partial match supported.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`matches`	No	Matching sites
`message`	No	Diagnostic message when no match

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.8.1Sep 28, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "matches": {
+      "description": "Matching sites",
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "domain": {
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          },
+          "organization": {
+            "type": "string"
+          },
+          "siteId": {
+            "type": [
+              "string",
+              "number"
+            ]
+          }
+        },
+        "required": [
+          "siteId",
+          "domain",
+          "name",
+          "organization"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "message": {
+      "description": "Diagnostic message when no match",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedv0.5.2Apr 2, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral value by disclosing the return type (numeric) and the important cross-tool nuance that SDK tracking uses a different, hash-form siteId from rybbit_create_site.

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?

Three tight sentences: purpose first, return value second, caveat last. No filler, and the most decision-relevant routing note is retained rather than padded.

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?

For a single-parameter, read-only lookup with an output schema and full annotation coverage, nothing an agent needs in order to call it correctly is missing; return-format detail is legitimately delegated to the output schema.

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 with 100% schema description coverage, including the partial-match behavior, so the schema does all the work. The description adds no syntax or matching detail beyond it, making the baseline 3 appropriate.

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?

States a specific verb and resource ('look up a site by domain name') and clarifies the return value ('numeric siteId'). The note explicitly distinguishes this tool's output from the hash siteId produced by rybbit_create_site, though it does not differentiate from rybbit_list_sites, which also surfaces sites.

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 clear context ('used for analytics API queries') and an explicit when-not with the named alternative for hash-based SDK tracking setup. It stops short of stating when to prefer this over rybbit_list_sites or whether it must be called before other siteId-taking tools.

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

Deploy Server