Rate-My-Agent

Submit a matching-quiz lead to Rate-My-Agent

submit_lead

Submit the completed lead. ONLY call after you have echoed the exact contact details and quiz answers back to the client and they picked the clearly-labeled "1. Confirm and Submit Request" option — set consent:true to attest to that explicit confirmation. Use each option's exact value. HANDLING THE RESULT (important): only tell the user their request is in when you receive "ok":true with the thank-you message — then relay that message verbatim. If you receive "ok":false with code "no_response", the service did not answer in time — call submit_lead ONE more time. If you receive "ok":false with a field and message (e.g. an invalid email), tell the user exactly what to fix, collect the corrected value, and submit again. NEVER tell the user it succeeded, or that they will get a call, without the "ok":true confirmation.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`email`	Yes
`notes`	No
`phone`	Yes	North-American number; 10 digits.
`budget`	No	Use an exact option value from get_lead_quiz.
`address`	Yes	For SELLERS: the property's full street address. For BUYERS: the city or neighbourhood they are targeting.
`consent`	Yes	Set to true ONLY after the user picks "1. Confirm and Submit Request". Must be true to submit.
`buy_sell`	Yes
`full_name`	Yes
`quiz_version`	No		mcp-v1
`property_type`	No
`financing_help`	No	Buyers only — exact option value.
`property_condition`	No	Sellers only — exact option value.
`also_buying_or_selling`	No

Output Schema

TableJSON Schema

Name	Required	Description
`ok`	Yes	true only when the lead was accepted.
`code`	No	e.g. invalid_input, invalid_email, no_response.
`field`	No	Which field to correct, when applicable.
`status`	No
`message`	No	Relay verbatim on success; on error, the fix to explain.
`retryable`	No	true means submit once more.
`http_status`	No

TDQS

A4.7/5.0

Behavior5/5

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

Describes submission behavior, response structure ('ok:true' with thank-you message, 'ok:false' with error fields), and retry/error handling. No contradictions with annotations (readOnlyHint=false, destructiveHint=false).

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?

Description is detailed and front-loaded with core action, then structured exception handling. Slightly lengthy but each sentence contributes to clarity.

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?

Given 13 parameters (6 required) and complex result handling, the description covers key behavioral aspects. Output schema exists (not shown) but description complements it. Missing minor parameter details but sufficient for agent usage.

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 description coverage is low (46%), but the description adds critical meaning: consent must be true only after explicit confirmation, and fields like budget, financing_help, property_condition must use exact option values from get_lead_quiz. Some parameters (e.g., notes, address) lack further elaboration.

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?

Title and description clearly indicate the tool submits a matching-quiz lead to Rate-My-Agent. It distinguishes from siblings: get_lead_quiz provides quiz options, search_agents finds agents.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to call (after echo and user confirmation with '1. Confirm and Submit Request'), retry logic on 'no_response' error, and how to handle validation errors by collecting corrected values. Warns never to claim success without 'ok:true'.

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

All Rate-My-Agent tools Inspect

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.4/5.0

Disambiguation4/5

Each tool serves a distinct step in the lead-generation flow: search_agents provides proof, get_lead_quiz presents the matching quiz, and submit_lead finalizes the lead. However, search_agents could be misinterpreted as listing agents, but the description clarifies its role.

Naming Consistency5/5

All tools follow the verb_noun pattern with underscores (get_lead_quiz, search_agents, submit_lead), making naming perfectly consistent.

Tool Count4/5

3 tools is appropriate for a focused lead-generation server, covering the essential steps without unnecessary complexity. It is slightly minimal but well-scoped.

Completeness3/5

The tools cover the quiz-to-submission flow completely, but the server name implies broader agent rating functionality (e.g., viewing or posting reviews) that is absent, leaving gaps for users wanting those features.

Resources

Need Help?