BlogSEO

Create hosted blog

create_hosted_blog

Creates the hosted blog: a blog served by BlogSEO on a subdomain of the user's domain (blog. by default) over HTTPS, with a sitemap, an RSS feed, Open Graph images, structured data and the website's branding. Returns the CNAME record to add at the DNS provider; nothing is live until DNS points to the target, so call get_hosted_blog_status afterwards. Subdomains only (no apex domain), one hosted blog per organization, and not next to a CMS integration such as WordPress or Shopify. Every generated article is published automatically once connected. Free. Pass website_id when the account has several websites (see get_account).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`hostname`	No	Subdomain for the blog, e.g. blog.example.com. Defaults to blog.<website domain>.
`website_id`	No	Website id from get_account. Optional when the account has a single website.

Output Schema

TableJSON Schema

Name	Required	Description
`status`	Yes
`blog_url`	Yes
`hostname`	Yes	Subdomain serving the blog.
`config_id`	Yes
`next_step`	Yes	What to do next for the current status: records to add, DNS and SSL wait times, or the article URL pattern once connected.
`registrar`	Yes
`created_at`	Yes
`last_error`	Yes
`updated_at`	Yes
`website_id`	Yes
`dns_records`	Yes	Records still to add at the DNS provider.
`is_connected`	Yes	true once DNS resolves and the certificate is issued.
`status_label`	Yes
`dashboard_url`	Yes
`dns_verified_at`	Yes
`registrar_warning`	Yes	Instruction specific to the detected DNS provider to follow when adding the records; null when none applies.
`ssl_provisioned_at`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 7, 2026

addedOutput schema / properties / next_step

Added value: +{
+  "description": "What to do next for the current status: records to add, DNS and SSL wait times, or the article URL pattern once connected.",
+  "type": "string"
+}

addedOutput schema / properties / registrar_warning

Added value: +{
+  "description": "Instruction specific to the detected DNS provider to follow when adding the records; null when none applies.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

changedOutput schema / required

Previous value: -[
-  "config_id",
-  "website_id",
-  "hostname",
-  "blog_url",
-  "status",
-  "status_label",
-  "is_connected",
-  "dns_records",
-  "last_error",
-  "registrar",
-  "dns_verified_at",
-  "ssl_provisioned_at",
-  "created_at",
-  "updated_at",
-  "dashboard_url"
-]New value: +[
+  "config_id",
+  "website_id",
+  "hostname",
+  "blog_url",
+  "status",
+  "status_label",
+  "is_connected",
+  "dns_records",
+  "last_error",
+  "registrar",
+  "dns_verified_at",
+  "ssl_provisioned_at",
+  "created_at",
+  "updated_at",
+  "dashboard_url",
+  "registrar_warning",
+  "next_step"
+]

First observedSep 19, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare the generic write/open-world profile; the description adds the operationally critical behavior that nothing is live until DNS points at the target, that a CNAME record is returned, that articles publish automatically once connected, and that the feature is free. It also discloses the side-effect semantics an agent needs before calling.

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?

The core action is front-loaded and every clause carries functional information (constraints, return value, follow-up tool, cost). It is delivered as one dense run-on paragraph rather than being chunked, which slightly hurts scannability but nothing is wasted.

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 two-parameter mutation with an output schema, the description covers everything an agent needs: constraints, prerequisite-free call, DNS dependency, follow-up status check, and multi-website disambiguation. Return-value detail is rightly left 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?

Schema description coverage is 100%, and the schema already documents the hostname default (blog.<website domain>) and the website_id behavior including the get_account reference. The description mostly restates that guidance, adding no new syntax or format details, so the baseline 3 applies.

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?

States a specific verb (creates) and a precisely defined resource (a hosted blog served by BlogSEO on a subdomain, with sitemap/RSS/OG/structured data). It is unmistakably distinct from siblings like get_hosted_blog_status or sync_article_to_cms, and even explains the mechanism (HTTPS subdomain hosting).

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

Usage Guidelines5/5

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

Explicitly gives preconditions and exclusions: subdomains only, one hosted blog per organization, not alongside a CMS integration like WordPress or Shopify, and pass website_id when the account has multiple websites (routing to get_account). It also names the required follow-up tool, get_hosted_blog_status, after the call.

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

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