Skip to main content
Glama

Find similar products

find_similar_products
Read-onlyIdempotent

Find other lines in the open task in the same category as a named product. Use it for substitutes and alternatives among the lines in front of the buyer; to search the whole catalogue use search_catalogue with the category.

Input Schema

NameRequiredDescriptionDefault
entity_nameYesEntity name exactly as the user wrote it.

Output Schema

NameRequiredDescriptionDefault
rowsYesOne row per product line: sku, product, category, supplier, then the line's own measures.
scopeYesWhat population the rows were read from.
truncatedYesTrue when more rows matched than were returned.
populationNoPresent on an unfiltered read: a reminder the rows are a slice, not the whole business.
evidence_idYesHandle for these rows within this call's results. Not a citation.
completenessNoPresent when nothing matched: what the empty result does and does not mean.
returned_rowsYesRows in this response.
inputs_not_appliedNoInputs the snapshot could not apply.
source_evidence_idsYesWorkspace evidence IDs backing these rows. Empty when the source carries no evidence records.
total_matching_rowsYesRows that matched before any limit.
excluded_rows_without_metricNoRows left out of a ranking because they carry no figure for the metric.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / description
      Previous value: -"Rows from the current work-unit snapshot."New value: +"Rows from the current task snapshot."
  2. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and openWorldHint=false, so the safety profile is covered; the description adds the meaningful scoping behavior that results come only from the current task's lines, not the whole catalogue. It doesn't describe how similarity is determined or how many results are returned, but the output schema covers the return shape.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the scope constraint and followed by the disambiguation. Nothing is redundant.

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

Completeness5/5

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

For a one-parameter, read-only lookup with rich annotations and an output schema, the description covers purpose, scope and the sibling alternative. Nothing an agent needs in order to call it correctly is missing.

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?

There is a single parameter with 100% schema description coverage, so the schema already tells the agent to pass the entity name exactly as the user wrote it. The description only implies the name resolves to a product line; it adds no format or resolution guidance beyond the schema.

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?

States a specific verb and resource ('Find other lines ... in the same category as a named product') and constrains the scope to the open task. This makes it clearly distinct from search_catalogue, which the description names explicitly.

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?

Gives the use case ('substitutes and alternatives among the lines in front of the buyer') and names the alternative with its condition ('to search the whole catalogue use search_catalogue with the category'). The agent can route without inference.

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.