Casefile

Overview Schema Source Related Servers Discussions Admin

read_project_entries

Read-onlyIdempotent

Retrieve a project's case entries with full bodies and payloads, ordered by entry number. Filter by type, number, or attribute to review decisions, findings, artifacts, and tracker changes.

Instructions

Returns the bodies of a project's case entries, payload included, ordered by entry number.

The project's case holds decisions, findings, artifacts and notes about the project, and the tracker's own entries about its card. Filters combine with and, as in read_entries. attribute gives one attribute's history: attribute_created, attribute_changed, attribute_removed entries with that name. The case index, titles only, comes with get_project.

Input Schema

TableJSON Schema

Name	Required	Description
`key`	Yes	Project key, case-insensitive. An unknown key is refused with `project_not_found`
`nos`	No	Only entries with these numbers
`limit`	No	Page size. Without a value, the installation's default page size
`types`	No	Only entries of these types
`cursor`	No	`next_cursor` of the previous page; without it, the first page
`after_no`	No	Only entries filed after the entry with this number
`attribute`	No	Only entries about the attribute with this name: `attribute_created`, `attribute_changed`, `attribute_removed`; matching ignores case

Output Schema

TableJSON Schema

Name	Required	Description	Default
`items`	Yes
`next_cursor`	Yes	Cursor of the next page, sent back as `cursor`; `null` means this page is the last one

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.5.2Sep 25, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds meaningful context beyond those hints: ordering by entry number, payload inclusion, filter conjunction semantics, the attribute-history special case, and the fact that the case index is only available via get_project.

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 with the primary behavior. Each sentence earns its place: result content, scope/context, filter semantics, attribute behavior, and relationship to get_project. No redundant phrasing.

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?

For a 7-parameter read tool with a full input schema, an output schema, and rich annotations, the description covers ordering, payload inclusion, filter combination, attribute filtering, and where to get the case index. Nothing essential is missing for an agent to invoke it correctly.

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 schema already documents all parameters well. The description still adds value by explaining that filters combine with 'and', that attribute gives a specific attribute's history, and that the relevant entry types are attribute_created, attribute_changed, and attribute_removed.

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: it returns the bodies of a project's case entries, payload included, ordered by entry number. It also distinguishes itself from siblings by scoping to the project's case and explicitly pointing to read_entries and get_project for related behavior.

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?

It clearly frames when to use this tool: to read project case entries, including attribute history. It also explains how filters combine and routes the case index to get_project. It doesn't explicitly state exclusions versus read_entries, but the project-scope wording makes the boundary reasonably clear.

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