Mark

Report Feedback

report_feedback

Records what the person asked you to change while drafting, and your own checks on the draft, so Mark can later suggest brand rules. Each call stores one new report. Call it at two moments: when the person states a standing rule ("never say game-changer"), before you ask whether to save it; and once on the version they accept, after save_post, with that postId. For a piece that lives outside Mark, pass externalRef instead. Each iteration is one ask: a short paraphrase in ask, its category, and scope (tenant_wide when they said it applies to everything, this_piece when only here, unsure otherwise; never guess). before, after and userQuote are optional short excerpts of the changed words and of what the person said. Keep every excerpt short, and never paste the conversation or a full draft. selfChecks list the checks you ran (check, result pass/warn/fail, reason). Recording feedback changes no rule. When the person agrees a rule, save it with save_content_exclusion (pass this report's id as feedbackId) for a phrase Mark should block or warn on, or update_brand_profile for voice guidance. Asks scoped tenant_wide or unsure come back as suggested rules from suggest_brand_rules. Related: save_content_exclusion, update_brand_profile, save_post, suggest_brand_rules.

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": {
      "channel": "<channel>"
    },
    "name": "report_feedback"
  }
}

Input Schema

Name	Required	Description
`notes`	No	Anything else worth keeping, at most 1,000 characters. Not the conversation.
`postId`	No	The saved post this report is about, from save_post.
`channel`	Yes	The channel being drafted.
`iterations`	No	Up to 20 asks: {ask, category, before?, after?, userQuote?, scope}. Each text at most 300 characters.
`selfChecks`	No	Up to 20 checks you ran: {check (at most 80 characters), result, reason (at most 300)}.
`externalRef`	No	Link to a piece outside Mark, at most 2,048 characters.

Output Schema

Name	Required	Description	Default
`id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 27, 2026

changedInput schema / properties / channel / enum

Previous value: -[
-  "instagram",
-  "facebook",
-  "youtube",
-  "pinterest",
-  "tiktok",
-  "x",
-  "linkedin",
-  "linkedin_article",
-  "blog",
-  "faq",
-  "competitor_page",
-  "landing_page",
-  "email",
-  "meta_ads",
-  "google_ads"
-]New value: +[
+  "instagram",
+  "facebook",
+  "youtube",
+  "pinterest",
+  "tiktok",
+  "x",
+  "linkedin",
+  "linkedin_article",
+  "blog",
+  "faq",
+  "competitor_page",
+  "meta_ads",
+  "google_ads"
+]

Changed1 schema field changedOct 20, 2026

changedInput schema / properties / channel / enum

Previous value: -[
-  "instagram",
-  "facebook",
-  "youtube",
-  "pinterest",
-  "tiktok",
-  "x",
-  "linkedin",
-  "blog",
-  "faq",
-  "competitor_page",
-  "landing_page",
-  "email",
-  "meta_ads",
-  "google_ads"
-]New value: +[
+  "instagram",
+  "facebook",
+  "youtube",
+  "pinterest",
+  "tiktok",
+  "x",
+  "linkedin",
+  "linkedin_article",
+  "blog",
+  "faq",
+  "competitor_page",
+  "landing_page",
+  "email",
+  "meta_ads",
+  "google_ads"
+]

AddedOct 15, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only say it is a non-idempotent, non-read-only write; the description adds the substance: each call stores a NEW report (explaining non-idempotency), recording changes no rule, and rule creation requires a separate save_content_exclusion or update_brand_profile call. It also warns against pasting full conversations and explains how scoped asks resurface via suggest_brand_rules.

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?

Well front-loaded — purpose first, then timing, then field guidance, then follow-up routing — and mostly dense. A few lines restate schema constraints (short excerpts, don't paste the conversation) that the schema's own field notes already imply, costing some economy.

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 6-parameter write tool with an output schema and mutation annotations, the description covers timing, field semantics, size discipline, side-effect boundaries, and hand-off to three sibling tools. Nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, yet the description still adds meaning the schema lacks: it defines the semantics of each scope value (tenant_wide = applies to everything, this_piece = only here, unsure otherwise, never guess), clarifies before/after/userQuote as short excerpts, and explains the postId-with-save_post vs externalRef dichotomy.

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 and resource — records asks/draft-feedback plus self-checks as one report per call — and explicitly frames the downstream purpose (suggesting brand rules). It is clearly distinct from siblings like save_content_exclusion, update_brand_profile and suggest_brand_rules, which are named as separate actions.

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?

Gives two concrete invocation moments (a stated standing rule, before asking to save it; and the accepted version after save_post, with that postId) plus the alternative path (externalRef for pieces outside Mark). It also states what this tool does NOT do — "Recording feedback changes no rule" — and routes the agent to the right follow-up tools.

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

All Mark 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?