car-listing-check-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| check_car_listingA | Use this when the user supplies a dealer vehicle listing and wants a best-practice score, missing data and prioritised fixes. Accepts at least a title (up to 300 characters) or description (up to 20,000), optional fields and up to 100 photo URL strings or a count. It does not fetch or scrape any website, verify vehicle facts or inspect images. Results are English; German and English keywords are recognised. Do not use for retrieving listings, valuations, vehicle inspections, media generation or legal advice. No images or videos are generated. No listing is stored or changed; operational call metrics are logged. Recommendations are not portal limits or legal advice. |
| get_car_listing_checklistA | Use this when the user wants a static dealer vehicle-listing checklist for Germany, the US, the UK or a generic market, optionally for a new or used vehicle. Returns recommended fields, photo order, title pattern and description structure in English. It does not fetch or scrape any website or verify vehicle facts, and is not legal advice. No images or videos are generated. No listing is stored or changed; operational call metrics are logged. Do not use for checking live portal rules, retrieving ads, vehicle inspections or generating images or videos. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
The two tools target clearly different needs: check_car_listing evaluates a specific supplied listing and returns a score with fixes, while get_car_listing_checklist returns static market-specific guidance. Each description explicitly excludes the other's territory (no fetching, no inspecting) and states when not to use it, leaving little room for misselection.
Both names follow a clean verb_noun snake_case pattern (check_car_listing, get_car_listing_checklist) with a shared domain noun, making the action/object relationship obvious. No mixed conventions or vague verbs.
Two tools is thin even for a narrowly scoped listing checker; the checklist could plausibly be an argument of the check tool rather than a separate endpoint, and there is no batch or comparison capability. It is not egregiously over- or under-scoped, but it sits at the borderline of feeling sparse.
The core lifecycle of 'get guidance, then score a listing' is covered, including multi-market checklists and optional field/photo inputs. Minor gaps exist around batch checking of multiple listings or re-checking after edits, but agents can work around these by calling the tool repeatedly.