Skip to main content
Glama

get_new_matches

DEMO. New cars that started matching a saved search after it was saved (or after since).

Input Schema

NameRequiredDescriptionDefault
sinceNoOptional ISO 8601 time; only matches after it (use checked_at from your last call).
search_idYessearch_id from save_search.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

B3.1/5.0
Behavior3/5

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

With no annotations at all, the description carries the full burden. It does disclose one genuinely useful behavioral trait the schema cannot: results are a delta of cars that *started* matching after the save/since point, so already-known matches are not re-returned. It says nothing about read-only safety, empty-result behavior, result ordering, or what 'DEMO' implies about data fidelity.

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?

A single economical sentence with the scoping condition front-loaded, no filler. The unexplained 'DEMO.' prefix consumes the most prominent position without telling the agent what it means.

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

Completeness2/5

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

No annotations and no output schema, so the description is the only place to learn the return shape, pagination/limits, and whether search_id must come from save_search — none of which it covers. For a tool with zero structured behavioral metadata, one sentence is too thin.

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 description coverage is 100% and both parameters are documented there, including the checked_at idiom for `since`. The description only restates '(or after `since`)' without adding format or boundary semantics (inclusive/exclusive, timezone), so it stays at the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The clause 'New cars that started matching a saved search after it was saved' names a specific resource (new matches for a saved search) and a precise temporal scope, which distinguishes it from search_inventory (general browsing) and save_search (creation). The weak point is that the verb is only implied by the tool name and the leading 'DEMO.' is unexplained.

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

Usage Guidelines2/5

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

There is no statement of when to call this rather than search_inventory or save_search, and no prerequisites (e.g. 'requires a prior save_search'). Polling intent is only inferable from the phrase 'or after `since`', and the more actionable hint ('use checked_at from your last call') lives in the schema, not the description.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources