Lianex — Australian price comparison

The published product-comparison index

lianex_vs

Read-onlyIdempotent

List published comparisons whose products remain cached, ordered by slug, with updated_at freshness. Omitting limit returns the full published index. Otherwise use offset, page_size and has_more; ignored lists unusable paging parameters. Results may change between requests. Cache-only.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "lianex_vs"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No	How many pairs to return, clamped to 50. OMIT IT and you get the whole index — this is the sitemap's own source, so it is never truncated by default.
`offset`	No	How many pairs to skip. Unusable values are ignored and named in `ignored`; a negative value is clamped to 0.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed14 schema fields changedNov 2, 2026
- removedOutput schema / $defs / VsIndexEntry / properties / slug / description
```
Removed value: -"The `{slug}` of `/api/public/vs/{slug}`."
```
- removedOutput schema / $defs / VsIndexEntry / properties / slug / title
```
Removed value: -"Slug"
```
- removedOutput schema / $defs / VsIndexEntry / properties / updated_at / description
```
Removed value: -"ISO-8601 freshness of the fresher side, or `null`."
```
- removedOutput schema / $defs / VsIndexEntry / properties / updated_at / title
```
Removed value: -"Updated At"
```
- removedOutput schema / $defs / VsIndexEntry / title
```
Removed value: -"VsIndexEntry"
```
- removedOutput schema / $defs / VsIndexResponse / description
```
Removed value: -"Published comparisons ordered by slug. Omit limit to return the full index; page_size is then null. Results may change between requests."
```
- removedOutput schema / $defs / VsIndexResponse / properties / has_more / description
```
Removed value: -"Read this instead of a total; no total is reported."
```
- removedOutput schema / $defs / VsIndexResponse / properties / has_more / title
```
Removed value: -"Has More"
```
- removedOutput schema / $defs / VsIndexResponse / properties / ignored / title
```
Removed value: -"Ignored"
```
- removedOutput schema / $defs / VsIndexResponse / properties / offset / title
```
Removed value: -"Offset"
```
- removedOutput schema / $defs / VsIndexResponse / properties / page_size / title
```
Removed value: -"Page Size"
```
- removedOutput schema / $defs / VsIndexResponse / properties / pairs / title
```
Removed value: -"Pairs"
```
- removedOutput schema / $defs / VsIndexResponse / title
```
Removed value: -"VsIndexResponse"
```
- removedOutput schema / title
```
Removed value: -"Response Public Vs Index Api Public Vs Get"
```

Changed6 schema fields changedOct 29, 2026

addedInput schema / properties / limit / anyOf

Added value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "pattern": "^-?[0-9]+$",
+    "type": "string"
+  }
+]

removedInput schema / properties / limit / default
```
Removed value: -""
```
removedInput schema / properties / limit / type
```
Removed value: -"string"
```

addedInput schema / properties / offset / anyOf

Added value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "pattern": "^-?[0-9]+$",
+    "type": "string"
+  }
+]

removedInput schema / properties / offset / default
```
Removed value: -""
```
removedInput schema / properties / offset / type
```
Removed value: -"string"
```

First observedOct 22, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already cover readOnly, idempotent, closed-world and non-destructive, so the bar is lower. The description still adds substantive context beyond them: "Cache-only" (non-cached products are silently excluded), the ordering/freshness contract, and the caveat that "Results may change between requests," which warns the agent against treating a prior listing as a stable snapshot.

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 purpose and scope, zero marketing filler. The phrase "ignored lists unusable paging parameters" is telegraphic to the point of being hard to parse on first read, costing a point.

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 an output schema present, the description needn't explain return values, and it correctly scopes itself to listing semantics and defaults. The only real gap is that it never positions the tool relative to lianex_vs_by_slug, and its allusion to non-existent input params (page_size, has_more) is left ambiguous.

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 the property descriptions already explain clamping to 50, the omit-for-full-index behavior, and negative-offset normalization. The prose restates those facts and introduces page_size/has_more, which map to no input property at all, adding mild confusion rather than meaning. Baseline 3 with schema doing the heavy lifting.

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 ("List published comparisons") plus two qualifying scopes: products must remain cached, and output is ordered by slug with updated_at freshness. The scope is genuinely differentiating, but it never names a sibling such as lianex_vs_by_slug or lianex_browse, so the agent must infer why it would pick this over those.

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

Usage Guidelines3/5

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

The description gives clear guidance on the pagination decision ("Omitting limit returns the full published index"), which is real usage advice, but it offers no when-to-use/when-not-to-use framing against the eight siblings, nor any exclusions. It also references page_size and has_more, which are not input parameters, leaving the agent to guess whether they are call arguments or response fields.

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

All Lianex — Australian price comparison tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?