Skip to main content
Glama
Niclasp1501

ninjos-foundry-mcp

by Niclasp1501
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

List compendium entries

list-compendium-entries
Read-onlyIdempotent

List compendium entries by id, name, type, and folder to verify archive contents, find duplicates, or obtain IDs for later operations. Returns up to 1000 entries per call and supports offset pagination.

Instructions

List what actually sits inside a compendium: ids, names, types and folders. list-compendiums only gives counts, so this is the way to check whether an archive holds what it should, to find duplicates, or to get the ids needed for later work. Reads the index only, never the full documents, and returns at most 1000 entries per call; when more follow, the answer says so with the next offset. Read only: it changes nothing and works at any permission level.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoEntries per page: 200 unless given, 1000 at the most
offsetNoEntries to skip; continue with the offset the previous answer named
packIdYesId of the compendium, package and name joined by a dot, for instance world.chapter-one
folderNameNoKeep only entries inside the compendium folder of this name
namePatternNoKeep only entries whose name contains this text; case does not matter

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv14.2609.4

TDQS

A4.5/5.0
Behavior5/5

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

The description goes well beyond the annotations by adding non-obvious behavior: it reads only the index, never full documents, returns at most 1000 entries per call, and tells the caller when more results exist via a next offset. It also confirms read-only behavior and permission-level access. This is exactly the kind of context annotations do not provide.

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

Conciseness5/5

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

The description is compact and front-loaded: purpose, distinguishing sibling, behavior, and read-only guarantee. Every sentence carries useful information and nothing is padded or redundant. The structure makes it easy to scan quickly.

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?

Given the rich 100% schema coverage, the read-only annotations, and the absence of an output schema, the description provides the missing contextual pieces: the shape of results, pagination behavior, index-only access, and use cases. An agent has what it needs to call this tool correctly and interpret the response.

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?

The input schema already documents all five parameters with full coverage, so the baseline is 3. The description mentions pagination limits that relate to limit and offset, but it does not add detail about folderName, namePattern, or packId beyond what the schema provides. It meets the baseline but does not elevate it.

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 the exact action ('List what actually sits inside a compendium') and specifies the returned fields: ids, names, types, folders. It explicitly distinguishes this tool from the sibling list-compendiums by noting that sibling only gives counts, so an agent can immediately tell which tool to use.

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?

The description gives concrete use cases: checking whether an archive holds what it should, finding duplicates, and getting ids for later work. It also calls out the alternative list-compendiums and why this tool is the right choice when counts are insufficient. It does not mention other relevant siblings like search-compendium, but the guidance is still clear.

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