Skip to main content
Glama
Sign In

Kaiku

by tech.kaiku.mcp
OverviewDiscussionsAdmin

List persons

list_persons
Read-only

A project's register of persons — the people its texts name — each with their spellings by script and form, each spelling's source and whether it is checked (see find_person), facts (born, died, wikidata, mathGenealogy, orcid, mrAuthor) the same way, and the project's note on why they are here. 'state' is 'confirmed', 'proposed' (found in the texts, waiting for a person — set_person with state decides it) or 'rejected'; proposed and rejected ones only to members who may write. 'reading' says whether the project has its texts read for persons. 'q' narrows to persons with a spelling holding those words. To a member who may write, 'similar' pairs two persons that look like one, with the two spellings and why — 'form' (the same up to the form of the words, «Гупта» / «Гупты»), 'letter' (one letter apart in a long Latin name, «Sjogren» / «Sjorgren»), 'transliteration' («Сьёгрен» / «Sjogren») or 'initials' («N. D. Gupta» / «Narayan D. Gupta») — a hint for the person to decide, never a fact: merge_persons only when they agree, distinct_persons when they say the two are different people — 'distinct' lists those answers. 'merged' lists the persons merged into one, whose spellings and facts are shown among its own with 'mergedFrom'. Only spellings whose source you may open; a person none of whose spellings you may see is not listed. Only where the company's plan includes AI.

Input Schema

NameRequiredDescriptionDefault
qNoWords a spelling holds, case aside.
limitNoHow many to return, at most 200. Default 100.
stateNo'confirmed', 'proposed', 'rejected' or leave out for all you may see.
offsetNoHow many to skip — for the next page.
sourceNoOnly persons read from this source: 'page:471', 'issue:KYC-12', 'comment:88', 'wikicomment:7', or 'none' for those written with no source. 'sources' in the answer lists them with counts.
projectYesThe project key, e.g. MATH.
onlyUncheckedNotrue for only persons with a spelling or fact that is not checked — written from memory or no longer in its source.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / onlyUnchecked
      Added value: +{
+  "default": false,
+  "description": "true for only persons with a spelling or fact that is not checked — written from memory or no longer in its source.",
+  "type": "boolean"
+}
    • addedInput schema / properties / source
      Added value: +{
+  "default": null,
+  "description": "Only persons read from this source: 'page:471', 'issue:KYC-12', 'comment:88', 'wikicomment:7', or 'none' for those written with no source. 'sources' in the answer lists them with counts.",
+  "type": [
+    "string",
+    "null"
+  ]
+}
  2. Added

TDQS

A3.8/5.0
Behavior5/5

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

Annotations already declare read-only, non-destructive and closed-world, yet the description adds substantial behavioral context beyond them: visibility is filtered by source permissions ('Only spellings whose source you may open; a person none of whose spellings you may see is not listed'), proposed/rejected entries are restricted to writers, and the tool is gated on the company's AI plan.

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

Conciseness3/5

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

The description is one dense paragraph mixing input filters, response fields, access rules and downstream actions. It is front-loaded with the core purpose, but the run-on parenthetical clauses make it harder to scan than a structured list would be.

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?

No output schema exists, so the description must explain return content — and it does extensively (spellings, facts, note, state, reading, similar, merged, distinct). It also covers permissions and plan gating. Minor omissions like pagination/limit bounds are handled by 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%, so the schema already explains q, limit, state, offset, source, project and onlyUnchecked. The description adds some interpretation of state visibility and q filtering, but most of its length is spent on response fields (similar, merged, distinct, reading) rather than input meaning.

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: a project's register of persons with their spellings, sources, facts and notes. It clearly belongs to the person-management family and names related tools (find_person, set_person, merge_persons, distinct_persons), though it does not explicitly say 'list/browse' versus 'look up one person' at the top.

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?

Provides workflow context for '_state_' (confirmed/proposed/rejected) and for 'similar' hints, directing the agent to merge_persons/distinct_persons when appropriate. However, it never explicitly says when to call this listing tool instead of find_person or decide_persons, so the selection guidance is implied rather than stated.

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

All Kaiku toolsInspect
Try in Browser
Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources