Zovo Venn

Compare lists

compare_lists

Read-onlyIdempotent

Use this when the user wants to know which items 2 or 3 lists share and which are unique, without a diagram, for example "which names are on both lists" or "compare these three guest lists". Takes 2 or 3 named lists (up to 500 items each, 80 characters per item) and a case option. Returns each region (only A, only B, A and B, ...) with its count and items, the overlap percentage for each pair, and a CSV with each item's region. Does not read files, does not fuzzy-match spellings, and does not draw a diagram.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "sets": "<sets>"
    },
    "name": "compare_lists"
  }
}

Input Schema

Name	Required	Description	Default
`sets`	Yes	2 or 3 named lists to compare. Each set: {"name":"Team A","items":["Ann","Bo","Cy"]}. Names up to 40 characters; up to 500 items per set, each up to 80 characters.
`case_sensitive`	No	false (default): "Apple" and "apple" are the same item. true: case matters.

Output Schema

Name	Required	Description	Default
`sets`	Yes
`pairs`	Yes
`regions`	Yes
`warnings`	Yes
`downloads`	Yes
`set_count`	Yes
`union_count`	Yes
`normalization`	Yes
`items_complete`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already establish read-only, idempotent, closed-world, non-destructive behavior, and the description goes further with hard limits (2–3 lists, 500 items, 80 chars) and the important negative semantics: no file reading and no fuzzy matching. The one omission is error behavior when the list count is outside 2–3, though the constraint itself is stated clearly.

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?

Three front-loaded sentences: trigger, inputs/limits, outputs, then exclusions. Every clause carries information, though the return-value sentence partially restates what the output schema already declares and could be trimmed.

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?

With an output schema present, the description need not enumerate return fields, yet it summarizes them briefly while spending its budget on limits, matching semantics, and exclusions. Nothing an agent needs to select or invoke this tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, and the description adds real meaning by narrowing the schema's maxItems of 10 to an actual requirement of exactly 2 or 3 lists and by flagging the case option as a meaningful input. It does not explain the case-sensitivity default beyond what the schema already states.

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?

The description names a specific verb and resource (compare 2–3 lists) and immediately scopes what is computed: shared items, unique items, region counts, and pairwise overlap. It also distinguishes itself from the sibling make_venn by stating it produces no diagram, so an agent can route correctly without opening either schema.

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?

It gives an explicit trigger condition ("when the user wants to know which items 2 or 3 lists share"), two concrete example utterances, and an exclusion ("without a diagram") that effectively points at make_venn. Both the when-to-use and when-not-to-use cases are covered.

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

All Zovo Venn 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?