MyClawn: Ask Me Anything

Publish my AI clone

publish_my_clone

Destructive

Use this when the user asks to create, update or publish their AI clone. It publishes a public chat page on the web where anyone with the link can ask the clone questions without an account. Include only what the user gave or approved in this conversation for publication, because it becomes public. It is an AI clone of the account holder only, never of another person. Headline and intro replace the earlier ones; facts are added to the existing facts.

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": {
      "headline": "<headline>",
      "about": "<about>",
      "facts": "<facts>"
    },
    "name": "publish_my_clone"
  }
}

Input Schema

Name	Required	Description
`about`	Yes	A short intro in the user's own words, approved for publication.
`facts`	Yes	Facts the clone may state about the user, one per item. Only what the user approved for publication.
`contact`	No	Optional: how people can reach the user, only if the user wants it public.
`headline`	Yes	One line saying who the user is and what they do, as the user approved it for publication.
`display_name`	No	The user's own name as it should appear on the page, for example "Ada Lovelace". Only the account holder's own name. Kept from the last time when left out.

Output Schema

Name	Required	Description	Default
`link`	Yes
`name`	Yes
`about`	Yes
`facts`	Yes
`public`	Yes
`contact`	Yes
`created`	Yes
`headline`	Yes
`fact_count`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already flag destructiveHint=true and openWorldHint=true, but the description adds material context they do not convey: the output is publicly reachable by anyone with the link and requires no account, and content must be limited to what the user approved in this conversation. It also discloses the merge semantics (headline/intro replace, facts append), which explains why the operation is not idempotent. It stops short of describing post-publish lifecycle (e.g. how to revoke) but that belongs to the sibling.

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?

Five tight sentences, front-loaded with the use condition, then what the tool produces, then the safety rule, then the scope limit, then the update semantics. No filler or restatement of the name, and each sentence carries a distinct decision-relevant fact.

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 an output schema present, return values need no explanation, and the description covers the high-risk aspects an agent needs: public exposure, approval-only content, identity scoping, and replace-vs-append behavior. The only gap is that it never mentions that the page persists under a link until explicitly unpublished, which an agent should know before calling a destructive, open-world tool.

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, but the description genuinely adds meaning the schema lacks: headline and intro replace prior values while facts are appended to existing ones, which changes how an agent should populate the facts array (all facts vs. new facts only). The publication-approved constraint also reinforces the intent behind headline, about and facts.

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?

The description names a specific action set (create/update/publish) on a specific resource (the user's AI clone as a public web chat page) and spells out what publishing actually produces: a link-accessible page where anyone can ask questions without an account. Siblings like get_my_clone and unpublish_my_clone are clearly different operations, so an agent can discriminate without opening the schema.

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?

It states an explicit trigger: "Use this when the user asks to create, update or publish their AI clone." It also imposes a hard scoping constraint (only the account holder's clone, never another person). It does not name alternatives such as unpublish_my_clone or teach_my_clone, but the trigger condition is unambiguous for the cases this tool covers.

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

All MyClawn: Ask Me Anything 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?