Skip to main content
Glama

RingGuard — AI Receptionist for Trade Businesses

Convert trial signup to lead

convert_trial_to_lead

Turn a Shadow Trial signup into a lead in your pipeline at the shadow_trial stage. Two-step: draft, then confirm.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
confirmNoLeave false to get a draft of the change. Only set true after the user has seen the draft and approved it.
trial_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), and the description adds genuinely new behavior: the operation is staged as draft-then-confirm, so the agent learns a mutation is not committed on first call. It stops short of describing what happens on confirm failure or whether a trial can be converted twice.

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?

Two sentences, no filler, with the outcome stated before the two-step mechanics. Every clause carries information the agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter mutation with no output schema, the description covers the core flow but omits what the draft actually contains, what the confirmed result looks like, and prerequisite/error conditions (e.g. invalid or already-converted trial_id). Adequate but with clear gaps.

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 coverage is 50%: confirm is described in the schema, trial_id is only constrained by format/pattern. The description reinforces the confirm semantics ('draft, then confirm') but adds no format, resolution, or ID-sourcing detail beyond the schema. Baseline 3 is appropriate.

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?

States a specific verb ('Turn ... into') plus both the source (Shadow Trial signup) and destination (lead at shadow_trial stage), so the agent knows exactly what is produced. It does not explicitly contrast itself with the nearby siblings add_lead or new_trial_signups, which is the only thing keeping it from a 5.

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?

'Two-step: draft, then confirm' gives workflow context, and the confirm parameter clarifies the approval gate. However, it never says when to prefer this over add_lead (manual creation) or how it relates to new_trial_signups, so the alternative-selection guidance is implied rather than stated.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources