scrap-autos-mcp

Submit a Qualified Lead to ScrapAutos

submit_lead

After the end user has received a quote and provided their phone number, call this to notify the ScrapAutos team. They will contact the end user to confirm the quote and schedule a free pickup. Required: phone + year + make + model. Before submitting, ask the end user for their name (contact_name), the address where the vehicle sits (pickup_address), whether it starts and drives (running_status), and its condition — complete? missing parts? flat tires? (condition_notes). Include quote_id, city, province, pickup_time if available.

Input Schema

TableJSON Schema

Name	Required	Description
`city`	No
`make`	Yes
`year`	Yes
`model`	Yes
`phone`	Yes	Canadian phone number — xxx-xxx-xxxx
`quote_id`	No	The quote_id returned by get_vehicle_quote
`quote_max`	No
`weight_kg`	No
`agent_name`	No	Name of the calling agent (for attribution)
`quote_base`	No
`pickup_time`	No	Preferred pickup window (free text)
`contact_name`	No	The end user's name, if they shared it
`province_code`	No
`pickup_address`	No
`running_status`	No	Does the vehicle start/drive? e.g. 'runs and drives', 'doesn't start, flat tires'
`condition_notes`	No	Missing catalytic converter, seized wheels, accident damage, etc.
`conversation_summary`	No

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It discloses that the team will contact the user to confirm/schedule, but does not mention validation behavior, idempotency, error handling, or potential side effects beyond the submission itself.

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 concise (two sentences) and front-loaded with the trigger condition. The second sentence lists required and optional parameters, but it is somewhat lengthy; overall efficient with no redundancy.

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?

Given 17 parameters, no output schema, and no annotations, the description covers the core workflow and key user-facing fields but omits details about return values, error handling, and many schema parameters, leaving some gaps for the agent.

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 41% (7 of 17 parameters described). The description explains key required fields and suggests gathering optional ones (contact_name, pickup_address, etc.), but many parameters (quote_max, weight_kg, agent_name, conversation_summary) are not addressed, leaving meaning gaps.

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 clearly states the tool's purpose: notify ScrapAutos after a quote and phone number are obtained. It specifies required fields and the follow-up action (team contacts user). This distinguishes it from siblings like get_vehicle_quote (quote retrieval) and search_vehicles (lookup).

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 explicitly states when to use ('after end user has received a quote and provided their phone number') and lists required fields. It advises what to ask the user before submitting (name, address, etc.). However, it lacks explicit 'when not to use' or comparison with sibling tools.

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

All scrap-autos-mcp 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

Disambiguation5/5

Each tool has a clearly distinct purpose: getting a quote, listing rates, searching trims, and submitting a lead. The descriptions clarify boundaries, especially between search_vehicles and get_vehicle_quote.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case: get_vehicle_quote, list_provincial_rates, search_vehicles, submit_lead. Verbs are descriptive and uniform.

Tool Count5/5

With 4 tools, the set is well-scoped for the domain of scrap vehicle quotes. Each tool covers a necessary step without redundancy or clutter.

Completeness5/5

The tool set provides a complete workflow: search trims, get a quote, view regional rates, and submit a lead. No obvious gaps exist for the intended purpose.

Resources

Need Help?