Skip to main content
Glama

Card sort analyzer

analyse_card_sort
Read-only

Analyze an open card sort (method after Donna Spencer, Card Sorting). Pass participants: an array with one entry per person, each a map of group name to a list of cards (or {id, groups: {...}}). Accepts 3 to 60 participants and 5 to 100 distinct cards. Returns a similarity matrix (percent of participants who grouped each pair), agreement per card pair, suggested categories from average-linkage hierarchical clustering cut at threshold percent agreement (default 50), cards with low agreement, and a table of the group labels people used with how many used each. Card names match case-insensitively; labels match on letters and digits only, so synonyms stay separate. Fewer than about 15 participants triggers a caution. It does not explain why people grouped cards, so follow up with interviews.

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": {
      "participants": "<participants>"
    },
    "name": "analyse_card_sort"
  }
}

Input Schema

NameRequiredDescriptionDefault
thresholdNoCluster cut-off as percent agreement, 10 to 95. Default 50.
participantsYesOne entry per participant: {"Group name": ["card", ...]} or {id, groups}.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover the read-only, non-destructive, closed-world profile, and the description still adds substantial behavior: the clustering method (average-linkage hierarchical, cut at `threshold`), exact matching rules (card names case-insensitive, labels normalized to letters/digits so synonyms stay separate), sampling caution, and an honest limitation about causal explanation. This is well beyond what the structured fields convey.

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?

Front-loaded with the verb and resource, then the input shape, then the returns and caveats — a sensible order with almost no filler. It is dense and long-ish, but each sentence carries new information; the label-matching rule is arguably the only line that 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?

There is no output schema, so the description must enumerate returns, and it does so thoroughly (five distinct output artifacts). Combined with input constraints, matching semantics, and the interpretive limitation, an agent has everything needed to call and act on this tool.

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 baseline is 3, but the description adds real meaning: `participants` may be either a group-name-to-cards map or an {id, groups} object, and `threshold` is explained as the percent-agreement cut for clustering rather than just a number with a default. It does not restate the 10-95 range, which the schema already handles.

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?

Names a specific analysis (open card sort) with the method attribution and precisely enumerates the outputs (similarity matrix, agreement per pair, clustering-derived categories, low-agreement cards, label table). No sibling tool overlaps, and an agent can tell exactly what it produces without opening any schema.

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?

States the input contract clearly (one entry per participant, 3-60 participants, 5-100 distinct cards) and warns that below ~15 participants a caution is raised, which guides when the result is trustworthy. It also tells the agent to follow up with interviews rather than relying on this alone. It stops short of explicit when-not-to-call framing, and there is no sibling alternative to route to.

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