Hustlin

Sync product context

sync_context

Push the product's context (the HUSTLIN.md fields) to Hustlin: what it is, who buys it, pricing, voice and allowed claims, the Look (what it looks like, plus photo URLs), the content mix (what a week of posts is about), goals, where tracked links go, and the permission mode. Only the fields given are changed. Owner only. Field reference: https://hustlin.ai/mcp.

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": {
      "productId": "<productId>"
    },
    "name": "sync_context"
  }
}

Input Schema

Name	Required	Description
`url`	No	Public URL.
`look`	No	What the product physically looks like, for every generated picture: packaging, size, color, texture of the product itself, how it is served or used, where it lives, the light. A few sentences.
`mode`	No	Permission mode: observe, approve or auto.
`goals`	No	Current growth goals, one sentence each.
`stage`	No	Where the product is.
`title`	No	Product name.
`voice`	No	How Hustlin should write for this product: tone, words to use and avoid, claims that are allowed and claims that are not.
`pricing`	No	How it makes money.
`lookNever`	No	Things no picture may show (including the generic version of the category), comma separated.
`northStar`	No	The one metric that matters.
`productId`	Yes	The product id (from products or create_product).
`contentMix`	No	What a week of autopilot posts is about, as a percent per mode: hero (the product), pairing (on the real food or task it is for), moment (holidays, seasons, weekday rituals), humor (a dry one-liner, product in shot), behind (the making, the founder, the place). E.g. "pairing 35, moment 20, humor 20, hero 15, behind 10". An empty string returns to the default for the product's kind.
`lookAlways`	No	Things every picture should include, comma separated.
`description`	No	What it does and for whom.
`lookPhotoUrls`	No	Public https URLs of photos of the real product (JPEG, PNG or WebP, up to 10 MB each). Fetched once and kept as reference images; replaces the product's photos. Up to 5.
`targetAudience`	No	Who buys it (the ICP).
`funnelDestination`	No	Where tracked links send people (signup page, store listing).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 9, 2026

addedInput schema / properties / contentMix

Added value: +{
+  "description": "What a week of autopilot posts is about, as a percent per mode: hero (the product), pairing (on the real food or task it is for), moment (holidays, seasons, weekday rituals), humor (a dry one-liner, product in shot), behind (the making, the founder, the place). E.g. \"pairing 35, moment 20, humor 20, hero 15, behind 10\". An empty string returns to the default for the product's kind.",
+  "maxLength": 200,
+  "type": "string"
+}

Changed4 schema fields changedNov 9, 2026

addedInput schema / properties / look

Added value: +{
+  "description": "What the product physically looks like, for every generated picture: packaging, size, color, texture of the product itself, how it is served or used, where it lives, the light. A few sentences.",
+  "maxLength": 1200,
+  "type": "string"
+}

addedInput schema / properties / lookAlways

Added value: +{
+  "description": "Things every picture should include, comma separated.",
+  "maxLength": 600,
+  "type": "string"
+}

addedInput schema / properties / lookNever

Added value: +{
+  "description": "Things no picture may show (including the generic version of the category), comma separated.",
+  "maxLength": 600,
+  "type": "string"
+}

addedInput schema / properties / lookPhotoUrls

Added value: +{
+  "description": "Public https URLs of photos of the real product (JPEG, PNG or WebP, up to 10 MB each). Fetched once and kept as reference images; replaces the product's photos. Up to 5.",
+  "items": {
+    "type": "string"
+  },
+  "maxItems": 5,
+  "type": "array"
+}

First observedNov 9, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, but the description adds real value beyond them: partial-update semantics (unspecified fields are untouched) and an authorization requirement (owner only). It does not mention that lookPhotoUrls replaces existing reference photos, but that detail lives in the schema.

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 in the first clause, and the two trailing sentences carry the partial-update rule and the ownership restriction. The long mid-sentence enumeration of fields is somewhat redundant with the schema, but it gives a fast scope read and nothing is truly filler.

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?

For a 17-parameter mutation tool with dense enum and limit annotations already handled by the schema, the description covers the essential extras: partial update, owner-only auth, and a field reference link. Return behavior is unspecified, but with no output schema and a simple sync result this is a minor gap.

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%, so the schema already explains every parameter including enums and limits. The description's field enumeration ('what it is, who buys it, pricing, voice ...') largely restates those properties in prose and adds no format or constraint information beyond the schema; 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 ('Push ... context') plus the resource (HUSTLIN.md fields on Hustlin) and enumerates the field groups covered. 'Only the fields given are changed' distinguishes it from a create-style sibling such as create_product, so an agent can tell what this does without reading 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 Guidelines3/5

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

Usage is implied by the partial-update sentence ('Only the fields given are changed') and the 'Owner only' restriction, which tells the agent this is an update path for an existing product rather than a creation path. However, no sibling is named and there is no explicit when-not guidance (e.g., use create_product first if the product does not exist).

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

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