Marsell

Learning write

learning_write

Write down one sentence this business has learned, with the evidence: the work ids or the experiment that show it, and the measured numbers. Confidence is set from the evidence, not by you. Refused without evidence. Pass contradicts with a learning id when this overturns an earlier one. kind correction is the owner correcting what is the business's own (a product, a work, a page or a name that is not theirs); notOurs then names each such thing exactly as written, in any language, so Brand strikes it wherever it shows. notOurs is [] for every other kind. The same sentence again adds its evidence to the one on file. Returns the learning's id and its confidence (low, medium or high); memory_search reads them back. It needs an act key.

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": {
      "text": "<text>",
      "kind": "<kind>",
      "evidence": "<evidence>",
      "contradicts": "<contradicts>",
      "notOurs": "<notOurs>"
    },
    "name": "learning_write"
  }
}

Input Schema

Name	Required	Description
`kind`	Yes	worked (something that worked), did_not (something that did not), audience, channel, timing, offer or product (what was learned about each), correction (the owner correcting what is the business's own).
`text`	Yes	The learning, one plain sentence.
`notOurs`	Yes	With kind correction: each thing that is not the business's own, exactly as written; [] for every other kind.
`project`	No	The project's id or exact name. Optional when the account has one project.
`evidence`	Yes	At least one of work ids, a test or measured numbers.
`contradicts`	Yes	The id of an earlier learning this overturns, which is then marked contradicted; null for none.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 4, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint false, destructiveHint false, openWorld false) it discloses the behaviors that matter for a write tool: confidence is computed from the evidence rather than supplied by the caller, the call is refused without evidence, a prior learning is marked contradicted, repeating the same sentence merges evidence instead of duplicating, and an act key is required. It also names what gets rejected (ids not on the ledger, rehearsals on simulated numbers), which the annotations cannot express.

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 sentence carries a rule that changes caller behavior. It is information-dense to the point of being terse, packing several rules into single sentences, but there is no filler to cut.

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 nested-object write tool with no output schema, the description covers the required inputs, the evidence sufficiency rule, idempotency, contradiction semantics, and the return payload (learning id and confidence level). Nothing an agent needs in order 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.

Parameters4/5

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

Schema coverage is already 100%, so the baseline is 3, but the description adds real semantics the schema does not: `notOurs` must match things exactly as written in any language so Brand can strike them downstream, and `contradicts` causes the referenced learning to be marked contradicted rather than just linking them. It does not add detail on `project` or the metric window format beyond what the schema says.

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 opens with a specific verb and resource: write a one-sentence learning with its evidence (work ids, an experiment, or measured numbers). It distinguishes itself from the read-side sibling by noting that 'memory_search reads them back', so the write/read split is legible without opening either 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 clear conditions and constraints: refused without evidence, use `contradicts` when overturning an earlier learning, use `kind correction` only for the owner correcting what is the business's own, and `notOurs` is [] for every other kind. It stops short of naming a full alternative tool for adjacent cases (e.g. where to record a fact that is not a learning), so it is strong context rather than exhaustive routing.

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

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