Skip to main content
Glama
Sign In

OneLence

by com.onelence
OverviewDiscussionsAdmin

Define a conversion event

onelence_save_event_definition

Adds a conversion event so OneLence reports it, e.g. "Demo booked" sent by the SDK as demo_booked. The preview needs name, event_name. Two steps: call with the change to get a summary and a confirmation_id, show the summary to the user, and only after they agree call again with just confirmation_id.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "onelence_save_event_definition"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoDisplay name, e.g. "Demo booked".
event_nameNoEvent name the SDK sends, e.g. demo_booked.
confirmation_idNoOnly when applying: the confirmation_id from the preview, after the user agreed.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "oneOf": [
+    {
+      "properties": {
+        "confirmation_id": {
+          "type": "string"
+        },
+        "expires_at": {
+          "type": "string"
+        },
+        "next_step": {
+          "type": "string"
+        },
+        "object": {
+          "const": "write_preview",
+          "type": "string"
+        },
+        "status": {
+          "const": "confirmation_required",
+          "type": "string"
+        },
+        "summary": {
+          "properties": {
+            "details": {
+              "items": {
+                "type": "string"
+              },
+              "type": "array"
+            },
+            "title": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "title",
+            "details"
+          ],
+          "type": "object"
+        }
+      },
+      "required": [
+        "object",
+        "status",
+        "confirmation_id",
+        "expires_at",
+        "summary",
+        "next_step"
+      ],
+      "type": "object"
+    },
+    {
+      "properties": {
+        "object": {
+          "const": "write_result",
+          "type": "string"
+        },
+        "result": {
+          "anyOf": [
+            {
+              "properties": {
+                "created_at": {
+                  "anyOf": [
+                    {
+                      "type": "string"
+                    },
+                    {
+                      "type": "null"
+                    }
+                  ]
+                },
+                "event_name": {
+                  "type": "string"
+                },
+                "id": {
+                  "type": "string"
+                },
+                "kind": {
+                  "anyOf": [
+                    {
+                      "type": "string"
+                    },
+                    {
+                      "type": "null"
+                    }
+                  ]
+                },
+                "name": {
+                  "type": "string"
+                },
+                "object": {
+                  "const": "event_definition",
+                  "type": "string"
+                }
+              },
+              "required": [
+                "object",
+                "id",
+                "name",
+                "event_name",
+                "kind",
+                "created_at"
+              ],
+              "type": "object"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "status": {
+          "const": "applied",
+          "type": "string"
+        }
+      },
+      "required": [
+        "object",
+        "status",
+        "result"
+      ],
+      "type": "object"
+    }
+  ],
+  "type": "object"
+}
  2. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only say this is a non-readonly, non-destructive, non-idempotent, closed-world write. The description adds the crucial behavior annotations cannot express: the write is staged through a preview that returns a summary plus a confirmation_id, and nothing is applied until a second call. It also implicitly warns the agent to surface the summary to the user before committing.

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?

Three tight sentences: purpose plus example first, then the preview requirements, then the two-step protocol in execution order. No filler, and the ordering mirrors how the agent must actually call the tool.

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?

An output schema exists, so return values need not be explained, and the description still covers the one thing the schema omits: the schema marks zero required parameters, yet the description states the preview needs name and event_name. Combined with the full commit protocol, nothing essential for correct invocation 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 100%, so the baseline is 3, but the description adds phase-level meaning the schema only states per-field: name and event_name belong to the preview call, while confirmation_id alone is used on the apply call. That clarifies the mutual-exclusion pattern across calls, which the flat property list does not convey.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Adds a conversion event so OneLence reports it" names a specific verb (adds/saves) and resource (conversion event), reinforced by a concrete example mapping "Demo booked" to demo_booked. It doesn't explicitly distinguish itself from the sibling update_event_definition or delete_event_definition, which an agent could conflate with the generic "save" naming.

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 spells out a clear operating protocol: first call with the change to get a summary and confirmation_id, show the user, then call again with only confirmation_id. That is strong when-to-use guidance for the two phases. It stops short of saying when NOT to use it (e.g. modifying an existing event versus creating a new one, or testing with send_test_event).

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

All OneLence 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