Skip to main content
Glama
sepehr071

technolife-mcp

by sepehr071
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Compare products

tl_compare
Read-onlyIdempotent

Compare 2 to 5 product codes side by side for price, stock, rating, and full specifications.

Instructions

Compare 2-5 products side by side: price, stock, rating and every spec.

specs is {section: {spec: values}} with one value per product, in the order of products; empty specs are left out. Same-category products compare best. For sellers and colors use tl_product.

Input Schema

NameRequiredDescriptionDefault
product_codesYes2 to 5 product codes, e.g. ['TLP-60492', 'TLP-133524'].

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.3.0
    • changedInput schema / properties / product_codes / items / description
      Previous value: -"Product code from a search or list, e.g. 'TLP-60492' (the bare number works too)."New value: +"Product code, e.g. 'TLP-60492' (bare number works)."
    • removedInput schema / properties / product_codes / title
      Removed value: -"Product Codes"
    • removedInput schema / title
      Removed value: -"tl_compareArguments"
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "title": "tl_compareDictOutput",
-  "type": "object"
-}New value: +null
  2. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description usefully adds return semantics absent from the schema: specs is {section: {spec: values}} with one value per product, aligned to input order, and empty specs are omitted — genuinely helpful since there is no output schema. No contradiction with annotations.

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?

Four short sentences, front-loaded with the core action and result set, then details on shape and caveats. Efficient overall, though the undefined tokens `products` and `specs` cost a little clarity for the space they take.

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

Completeness4/5

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

With no output schema, the description compensates by sketching the returned specs structure and the omission rule, and the annotations cover safety and open-world behavior. It remains incomplete on edge cases (incomparable categories, codes that fail lookup) and uses a parameter name that isn't in the schema.

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% for the single parameter (product_codes, with format/example and min/max items), so the schema does the heavy lifting and a 3 is the baseline. The description adds ordering intent but refers to an input called `products` that does not exist in the schema, introducing a naming mismatch that could misroute the agent.

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?

States a specific verb and resource — compare 2-5 products side by side on price, stock, rating and specs — which an agent can immediately distinguish from list/search siblings. Sibling routing is only partially covered: tl_product is named for sellers and colors, but no differentiation from tl_find_cheapest or tl_search.

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?

Gives a real usage constraint ('Same-category products compare best') and one explicit alternative ('For sellers and colors use tl_product'). It lacks broader when-not guidance, e.g. what to use for a single product or for cross-category basket pricing (tl_price_basket), so it stops short of a 5.

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

Deploy Server

Other Tools