render_shortlistShow a comparison that compare_listings returned as a visual shortlist card. Use this after compare_listings when the host can display app cards; pass the comparison unchanged.
| Name | Required | Description | Default |
|---|---|---|---|
| ranking | No | ||
| listings | Yes | ||
| comparedAt | No | ||
| canonicalUrls | No | ||
| criteriaSummary | No | ||
| missingDataNotes | No | ||
| sameHomeListingIds | No | ||
| unavailableListingIds | No |
Changes observed during successful MCP inspections.
Input schema / properties / listings / items / properties / reasonsAdded value: +{
+ "items": {
+ "maxLength": 180,
+ "minLength": 1,
+ "type": "string"
+ },
+ "maxItems": 12,
+ "type": "array"
+}Input schema / properties / listings / items / properties / score / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Input schema / properties / ranking / items / properties / score / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Input schema / properties / sameHomeListingIdsAdded value: +{
+ "items": {
+ "maxLength": 120,
+ "minLength": 1,
+ "type": "string"
+ },
+ "maxItems": 6,
+ "type": "array"
+}Input schema / properties / listings / items / properties / bookingUrlAdded value: +{
+ "format": "uri",
+ "maxLength": 300,
+ "type": "string"
+}Input schema / properties / listings / items / properties / squareFeet / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that the comparison should be passed unchanged and that the result is a visual card for hosts that can display app cards, but it does not describe validation behavior, failure modes, or exactly what rendering produces.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tight sentences, front-loading the purpose and then the usage condition. Every phrase earns its place, with no redundant restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a large, complex input schema with 8 parameters and no output schema, while the description gives only high-level context. It says the result is a visual shortlist card and that the comparison should be passed unchanged, but it does not compensate for the lack of parameter descriptions or clarify what rendering returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 8 parameters, so the schema provides field names but no semantic explanations. The description only says to pass the comparison unchanged, which helps avoid transforming the input, but it does not explain required listings, ranking, comparedAt, criteriaSummary, or other parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it shows a comparison returned by compare_listings as a visual shortlist card. It clearly distinguishes rendering from computing by naming compare_listings as the producer and telling the agent to pass its comparison unchanged.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear usage condition: use this after compare_listings when the host can display app cards. That is strong sequencing guidance, though it does not explicitly state when not to use it or name a fallback alternative for hosts that cannot display app cards.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.