Skip to main content
Glama
rooquiz

RooQuiz

get_lead

Read-only

Retrieve a lead by ID to review follow-up status, assignee, tags, respondent info, and next booking. Optionally add submission history, internal comments, or activity timeline.

Instructions

View one lead of the current team by leadId: follow-up status, assignee, colour tags, the respondent block, and the next upcoming booking. Optionally include the respondent's submission history (which quizzes they took, with score / level), the team's internal follow-up comments, and the change timeline (status / assignee / tag changes plus submissions). Reference a lead by its leadId and a respondent by examineeId, never by a masked email.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
leadIdYesThe lead id (the leadId returned by list_leads)
includeRecordsNoInclude the respondent's submission history (default true)
includeCommentsNoInclude the internal follow-up comments written by team members (default false)
includeActivitiesNoInclude the change timeline: status / assignee / tag changes and submissions (default false)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagsNoColour tag codes on this lead
leadIdNoLead id — address a lead by this, never by a masked email
statusNoFollow-up status code (team-defined, see list_lead_settings)
recordsNoSubmission history as { totalDocs, items } (unless includeRecords was false)
assigneeNoThe member handling this lead as { id, email, username }, or null
commentsNoInternal follow-up notes written by team members (only when includeComments)
createdAtNoISO datetime the lead was created
firstFormNoThe quiz that first captured this lead as { id, title }
activitiesNoChange timeline as { totalDocs, items } (only when includeActivities)
respondentNoThe respondent { id, examineeId, email, name, customData, ... }, PII masked
nextBookingNoThe next active booking of this respondent, or null
recordCountNoHow many times this respondent submitted
lastRecordAtNoISO datetime of the most recent submission
firstRecordAtNoISO datetime of the first submission

Schema Changelog

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

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already signal read-only and non-destructive behavior, and the description adds task-relevant context such as current-team scoping, optional inclusions, and the leadId/examineeId addressing rule. It does not cover error cases or defaults, but the annotation safety profile lowers the burden.

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 description is a single dense paragraph with a front-loaded purpose, a colon-delimited payload list, and a closing ID rule. It is information-dense without filler; only the somewhat run-on structure prevents a 5.

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

Completeness4/5

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

With annotations, an output schema, and full schema parameter coverage, the description is contextually adequate: it states what is returned, which flags affect breadth, and the team/ID scoping. It does not state exact when-to-use alternatives, but that is a minor gap for a single-item getter.

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 100%, so the baseline is 3. The description's optional-inclusions wording maps loosely to the boolean flags but adds no parameter details beyond what the schema already provides.

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?

Description names a specific verb ('View'), a resource ('one lead of the current team'), a key ('leadId'), and enumerates what is included. This clearly distinguishes get_lead from list_leads and get_examinee without needing to open the 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 gives clear context: use this for a single lead scoped to the current team, and it supplies an explicit identifier constraint ('never by a masked email'). It does not explicitly name sibling alternatives such as list_leads for multi-lead views, so it falls short of a full 5.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rooquiz/rooquiz-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server