Skip to main content
Glama

KreatorMesh

by com.kreatormesh
OverviewDiscussionsAdmin

Create a hook test

create_hook_test

Start a hook test: publish several openings for the same idea and measure which one holds attention on this account. THIS SCHEDULES REAL POSTS — one per variant per round, spaced out over days — so confirm with the person before calling it, and tell them how many posts it scheduled (postsScheduled). Each post's views are recorded seven days after it goes out and a winner is only declared when it clearly beats the others and the account's usual range; "no winner" is a common, real result. Results become the rules that list_hook_rules and check_draft read. The posts appear in list_posts, but cancel_post and update_post refuse them while the test runs, because changing one would spoil the measurement.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ideaYesThe one idea every variant expresses, e.g. 'Batch-editing a week of videos in one sitting saves hours'. Only the opening should differ between variants.
titleYesA short name the person will recognise in the app, e.g. 'Question vs story — editing tips'.
roundsNoHow many times each variant is posted, from 2 up. Defaults to 3; with 3 variants that is 9 posts. Fewer than 2 can never conclude.
variantsYesTwo to four opening lines to compare, each a genuinely different way into the same idea, e.g. ["Why do your edits take all week?", "I edit a week of videos in one afternoon."].
accountIdYesId of the account to run the test on, from list_connections. The platform must report views: TikTok, Instagram, YouTube, X, Facebook, Threads or Pinterest — not LinkedIn or Bluesky.
archetypesYesOne archetype per variant, in the same order: question, contrarian, number, story or direct. This is not a label — it decides the rule the test can produce, and the opening must actually match it (question ends with '?', number starts with a figure, contrarian starts with stop/nobody/everyone/most/forget/unpopular/the reason, story starts with I/we/last/yesterday/when I/my client).
slotHourUtcNoHour of day to post at, 0 to 23, in UTC — convert from the person's time zone first. Defaults to 18. Every variant uses the same hour so time of day cannot decide the result.
spacingDaysNoDays between consecutive posts. Defaults to 3, which spreads the variants across different days of the week.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changed
    • changedInput schema / properties / accountId / description
      Previous value: -"Account id from list_connections to run the test on."New value: +"Id of the account to run the test on, from list_connections. The platform must report views: TikTok, Instagram, YouTube, X, Facebook, Threads or Pinterest — not LinkedIn or Bluesky."
    • changedInput schema / properties / idea / description
      Previous value: -"The single idea every variant expresses. Only the opening should differ."New value: +"The one idea every variant expresses, e.g. 'Batch-editing a week of videos in one sitting saves hours'. Only the opening should differ between variants."
    • changedInput schema / properties / rounds / description
      Previous value: -"How many times each variant is posted. Defaults to 3. Fewer than 2 cannot conclude."New value: +"How many times each variant is posted, from 2 up. Defaults to 3; with 3 variants that is 9 posts. Fewer than 2 can never conclude."
    • changedInput schema / properties / slotHourUtc / description
      Previous value: -"Hour of day (UTC) to post at. Defaults to 18."New value: +"Hour of day to post at, 0 to 23, in UTC — convert from the person's time zone first. Defaults to 18. Every variant uses the same hour so time of day cannot decide the result."
    • changedInput schema / properties / spacingDays / description
      Previous value: -"Days between posts. Defaults to 3."New value: +"Days between consecutive posts. Defaults to 3, which spreads the variants across different days of the week."
    • changedInput schema / properties / title / description
      Previous value: -"Short name for the test, e.g. 'Hook style — scheduling posts'."New value: +"A short name the person will recognise in the app, e.g. 'Question vs story — editing tips'."
    • changedInput schema / properties / variants / description
      Previous value: -"2-4 opening lines to compare. Same idea, genuinely different openings."New value: +"Two to four opening lines to compare, each a genuinely different way into the same idea, e.g. [\"Why do your edits take all week?\", \"I edit a week of videos in one afternoon.\"]."
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Adds substantial behavior beyond annotations: it schedules real posts spaced over days, results are recorded seven days later, a winner requires beating both peers and the account's usual range, 'no winner' is common, and it locks the posts against cancel_post/update_post while running. This is exactly the kind of downstream-effect disclosure annotations (readOnlyHint=false, openWorldHint=true) cannot provide.

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?

Front-loaded with the core action, then the critical scheduling warning, then measurement/lockout details. It is somewhat long, but every sentence carries a distinct operational fact (scheduling, timing, winner logic, downstream effects, lockout) so little feels 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 an 8-parameter mutation tool with no output schema, it covers the full lifecycle: what gets created, when results arrive, how a winner is decided, what the results feed into, and how conflicts are handled. An agent has enough to call it safely pending human confirmation.

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 schema already documents every parameter richly. The description nonetheless maps behavioral meaning onto parameters (posts scheduled per variant per round, results become list_hook_rules input), adding context the schema does not carry. Baseline 3 is exceeded because it ties parameters to the experiment's semantics.

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+resource ('Start a hook test') and immediately defines the mechanism ('publish several openings for the same idea and measure which one holds attention'). It is clearly distinguishable from sibling write tools like schedule_post because it describes a multi-variant measurement experiment.

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 strong usage context: confirm with the person before calling, this is for measuring hook variants on accounts whose platform reports views. It implicitly routes away from LinkedIn/Bluesky but does not name an explicit alternative tool for single-post scheduling (schedule_post), so the when-to-use is clear but the when-not is only partially covered.

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

All KreatorMesh toolsInspect
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