FeelingSurf

Create a site

create_site

Create a site. Only url is required; every other field defaults to a new-site configuration. Exceeding the account's slot count returns 403 site_limit_reached. Fields for creating a site. Only url is required; all others default to a new-site configuration. When template_id is given, that template's settings seed the defaults and any field set explicitly here overrides them (shallow, per top-level key).

Input Schema

Name	Required	Description
`url`	Yes	The website's URL.
`name`	No	User-chosen name; null clears it.
`labels`	No	IDs of labels to assign.
`limits`	No	Visit caps; null means no limit.
`paused`	No	Pause or resume visit delivery.
`actions`	No	Auto-actions performed during visits.
`cookies`	No	Cookies to set before each visit; replaces the stored list.
`devices`	No	Device targeting split, as percentages summing to 100.
`browsing`	No	Browsing options.
`schedule`	No	Active-hours scheduling.
`template_id`	No	A site template to apply as the base configuration. Must be one of your own templates; an unknown id returns 422. The template's settings become the defaults; any field you also send in this request overrides the template's value for that whole field (shallow merge, per top-level field).
`visit_duration`	No	Visit duration range, in seconds.
`blocked_domains`	No	Domains blocked during visits.
`traffic_quality`	No	Traffic quality controls.
`traffic_sources`	No	IDs of traffic sources to assign; an empty list assigns the default "Direct visits" source.
`location_targeting`	No	Country/continent targeting.
`visit_distribution`	No	How visits are paced — "even" spreads them across the day, "asap" delivers as fast as possible.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 11, 2026

removedInput schema / properties / actions / properties / items / items / properties / cookie

Removed value: -{
-  "description": "Present for cookie actions.",
-  "properties": {
-    "domain": {
-      "description": "Domain to set the cookie on.",
-      "type": "string"
-    },
-    "name": {
-      "description": "Cookie name.",
-      "type": "string"
-    },
-    "value": {
-      "description": "Cookie value.",
-      "type": "string"
-    }
-  },
-  "type": "object"
-}

changedInput schema / properties / actions / properties / items / items / properties / type / description

Previous value: -"What the app does — click a link, click an RSS or sitemap link, set a cookie, scroll, or refresh."New value: +"What the app does — click a link, click an RSS or sitemap link, scroll, or refresh."

changedInput schema / properties / actions / properties / items / items / properties / type / enum

Previous value: -[
-  "click",
-  "click_rss",
-  "click_sitemap",
-  "cookie",
-  "scroll",
-  "refresh"
-]New value: +[
+  "click",
+  "click_rss",
+  "click_sitemap",
+  "scroll",
+  "refresh"
+]

addedInput schema / properties / cookies

Added value: +{
+  "description": "Cookies to set before each visit; replaces the stored list.",
+  "items": {
+    "description": "A cookie set on the browser session before the visit begins.",
+    "properties": {
+      "domain": {
+        "description": "Domain to set the cookie on (a leading dot is dropped; subdomains are covered either way); null sets it on the visited site's host.",
+        "maxLength": 256,
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "name": {
+        "description": "Cookie name.",
+        "maxLength": 256,
+        "type": "string"
+      },
+      "value": {
+        "description": "Cookie value.",
+        "maxLength": 256,
+        "type": "string"
+      }
+    },
+    "required": [
+      "name",
+      "value"
+    ],
+    "type": "object"
+  },
+  "maxItems": 10,
+  "type": "array"
+}

First observedOct 6, 2026

TDQS

B3.2/5.0

Behavior4/5

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

Annotations already declare this is a non-read-only, non-idempotent, non-destructive write, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: exceeding the account's slot count returns 403 site_limit_reached, unset fields fall back to a new-site configuration, and template_id merges shallowly per top-level key with explicit fields overriding. It does not say what happens to nested sub-keys during the shallow merge beyond implying they are replaced wholesale.

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

Conciseness2/5

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

The same statement ('Only `url` is required; ...') appears twice nearly verbatim, and a leftover fragment from the schema ('Fields for creating a site.') sits mid-paragraph. This duplication and noise wastes space in an otherwise short description and hurts front-loading.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 17-parameter, deeply nested mutation with no output schema, the description covers the essentials (required field, defaults, template inheritance, limit error) but omits what the call returns and any auth/permission requirements. Adequate but with clear gaps given the complexity.

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% across all 17 parameters, so the baseline is 3. The description only adds semantics for url's optionality, the defaulting behavior of everything else, and the template merge rule; it adds nothing for the many nested/constrained fields the schema already documents well.

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 ('Create a site') that distinguishes it from update_site, create_site_template and other create_* siblings. However the text is cluttered by a duplicated sentence and a stray schema fragment ('Fields for creating a site.') that adds no clarity about the operation itself.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this versus update_site, create_site_template, or restore_site, nor any prerequisites such as required permissions or account slot availability beyond the error mention. The only conditional behavior described is the template_id seeding rule, which is more of a parameter note than usage guidance.

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

All FeelingSurf tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?