Skip to main content
Glama

Cromanion

by com.cromanion

cromanion_add_goal

Idempotent

Define a conversion to count, or change one you already defined. This is not one more setting: it is the numerator of every impact figure your human will read, so a goal that fires on every pageview makes the agent look brilliant and tells them nothing. Send type and value to create — idempotent, the same matcher twice creates one goal. Send goalId instead to rename, reprioritise or price an existing one, or with remove: true to stop counting it. Needs the goals permission.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeNoMatcher: css_click, form_submit, page_view, mailto, tel, outbound, scroll_depth, dwell, custom_event.
labelNoWhat your human will call it. Defaults to something readable.
valueNoWhat the matcher matches — a selector, a path, a percentage, seconds.
goalIdNoChange an EXISTING goal instead of creating one. Ids come from cromanion_config. With `remove: true` it stops counting that conversion; otherwise it applies the label, priority or dollarValue you send.
removeNoWith goalId: stop counting that conversion. Nothing already measured is rewritten.
siteIdNoWhich site this call is about. Only needed when your credential covers more than one — cromanion_grants lists them and says whether it is required. Omitting it with several is refused rather than guessed at.
priorityNoWith goalId: 1 is the primary goal, ascending. Rejected rather than clamped if out of range.
dollarValueNoOptional worth of one conversion, for revenue figures.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYes
noteNoPresent when nothing changed, saying why.
labelNoWhat your human sees it called, after the change.
goalIdYes
createdNoPresent on a create. False when this site already counted that conversion — the call succeeded either way and nothing was duplicated.
removedNoPresent when you sent remove: true.
updatedNoPresent on an edit: which fields changed.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • addedInput schema / properties / siteId
      Added value: +{
+  "description": "Which site this call is about. Only needed when your credential covers more than one — cromanion_grants lists them and says whether it is required. Omitting it with several is refused rather than guessed at.",
+  "type": "string"
+}
  2. Changed10 schema fields changed
    • addedInput schema / properties / goalId
      Added value: +{
+  "description": "Change an EXISTING goal instead of creating one. Ids come from cromanion_config. With `remove: true` it stops counting that conversion; otherwise it applies the label, priority or dollarValue you send.",
+  "type": "string"
+}
    • addedInput schema / properties / priority
      Added value: +{
+  "description": "With goalId: 1 is the primary goal, ascending. Rejected rather than clamped if out of range.",
+  "type": "number"
+}
    • addedInput schema / properties / remove
      Added value: +{
+  "description": "With goalId: stop counting that conversion. Nothing already measured is rewritten.",
+  "type": "boolean"
+}
    • changedInput schema / required
      Previous value: -[
-  "type"
-]New value: +[]
    • changedOutput schema / properties / created / description
      Previous value: -"False when this site already counted that conversion. The call succeeded either way; nothing was duplicated."New value: +"Present on a create. False when this site already counted that conversion — the call succeeded either way and nothing was duplicated."
    • changedOutput schema / properties / label / description
      Previous value: -"Present when created: what your human will see it called."New value: +"What your human sees it called, after the change."
    • changedOutput schema / properties / note / description
      Previous value: -"Present when it already existed."New value: +"Present when nothing changed, saying why."
    • addedOutput schema / properties / removed
      Added value: +{
+  "description": "Present when you sent remove: true.",
+  "type": "boolean"
+}
    • addedOutput schema / properties / updated
      Added value: +{
+  "description": "Present on an edit: which fields changed.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • changedOutput schema / required
      Previous value: -[
-  "ok",
-  "goalId",
-  "created"
-]New value: +[
+  "ok",
+  "goalId"
+]
  3. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "created": {
+      "description": "False when this site already counted that conversion. The call succeeded either way; nothing was duplicated.",
+      "type": "boolean"
+    },
+    "goalId": {
+      "type": "string"
+    },
+    "label": {
+      "description": "Present when created: what your human will see it called.",
+      "type": "string"
+    },
+    "note": {
+      "description": "Present when it already existed.",
+      "type": "string"
+    },
+    "ok": {
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "ok",
+    "goalId",
+    "created"
+  ],
+  "type": "object"
+}
  4. First observed

TDQS

A4.7/5.0
Behavior5/5

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

The idempotentHint annotation is reinforced and detailed by the description: 'the same matcher twice creates one goal.' The description also discloses mutation behavior for existing goals, removal semantics, and the permissions requirement. It is consistent with destructiveHint=false because removing a goal is described as 'stop counting it' rather than destroying historical data.

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?

The core verb and resource are front-loaded, and the create/edit/remove modes are each stated in compact, purposeful sentences. The conceptual warning about pageview-level goals earns its place because it prevents a common misuse of the tool. There is no filler or redundant restatement of schema fields.

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?

Given the 8-parameter schema and 100% coverage, the description supplies the missing combination rules and permission context that the schema alone does not make explicit. It also warns about low-value goals, which matters for the agent's decision-making. The output schema exists, so the description does not need to explain return values.

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?

Even though schema description coverage is 100%, the description adds relationship semantics beyond individual property docs: `type` and `value` together define a new matcher, `goalId` switches to modification mode, and `goalId` with `remove: true` means stop counting. It also maps 'rename, reprioritise or price' to label, priority, and dollarValue, which helps an agent combine parameters correctly.

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 'Define a conversion to count, or change one you already defined,' naming a specific resource and both creation and modification behaviors. It also contrasts the tool with 'one more setting,' which helps distinguish it from the cromanion_set_* sibling family. This is far more than a restatement of the tool name.

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?

The description clearly explains the two operational modes: send `type` and `value` to create, or send `goalId` to rename, reprioritise, price, or remove an existing goal. It also states the goals permission prerequisite. It does not explicitly name sibling alternatives or exclusion conditions, but the 'not one more setting' warning provides useful context for when this tool is appropriate.

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

All Cromanion toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources