Skip to main content
Glama

RooQuiz

by com.rooquiz.payload

update_lead

Move one lead of the current team to another follow-up status (e.g. new → contacted). The change is recorded on the lead's timeline. Status codes and tag codes are team-defined — call list_lead_settings first to get the valid ones, never guess.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
leadIdYesThe lead id (the leadId returned by list_leads)
statusYesThe target status code, must be one of list_lead_settings.statuses[].code

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
leadIdNoThe lead that was moved
statusNoStatus code after the move

TDQS

A4.3/5.0
Behavior4/5

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

The description adds meaningful side-effect context beyond the annotations: the status change is recorded on the lead's timeline, and valid status codes are team-defined rather than universal. It does not contradict the readOnlyHint=false or destructiveHint=false annotations.

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 description is three short sentences, front-loaded with the action and then providing necessary scope and prerequisite context. There is no filler or redundancy.

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 two-parameter update operation with rich annotations and output schema present, this description is complete: it identifies the scope (current team), the behavior (timeline recording), and the dependency (list_lead_settings). Nothing an agent needs to call it correctly seems missing.

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 description coverage is 100%, so the schemas already define leadId and status well. The description reinforces that status codes come from list_lead_settings and warns against guessing, but adds little new parameter-level meaning beyond the schema.

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 is specific: it names the verb ('move'), the resource ('one lead of the current team'), and the precise change (follow-up status, e.g. new → contacted). This clearly distinguishes update_lead from sibling tools like set_lead_tags or add_lead_comment.

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 gives an explicit prerequisite: call list_lead_settings first to get valid status codes and never guess. This is strong practical usage guidance, though it does not name alternative tools or explicitly say when not to use this one.

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

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

TDQS

A4.1/5.0
Disambiguation4/5

Most tools map to a distinct resource and action, and the descriptions actively disambiguate similar operations (e.g., get_form vs get_form_share_info vs get_form_stats). The main potential confusion is between list_records and list_leads and between get_record and get_lead, since both describe leads from slightly different angles.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun convention, with resources like form, question, lead, booking, examinee, translation, and tenant parallel across actions. The few non-CRUD verbs like prepare_/finalize_, duplicate_, and reschedule_ still fit the same uniform pattern.

Tool Count2/5

48 tools is well beyond the 3–15 ideal and even past the 25+ threshold, making the tool surface heavy for an agent to navigate. The broad platform scope explains some of the size, but the count still risks overwhelming context and increasing misselection.

Completeness4/5

The server covers form lifecycle, question editing, translations, CRM leads, examinees, records, bookings, team/tenant operations, image uploads, templates, and analytics extremely well. Minor gaps remain—such as no lead/record deletion, no member removal or role updates, and limited booking-settings management—but most workflows can be completed with the existing tools.

Resources