Inistate MCP Server

Official

by Inistate

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

List Entries

list_entries

Read-onlyIdempotent

Query Inistate module entries with filters, sorting, pagination, field selection, and free-text search to return only the records you need.

Instructions

Query entries with filters, sorting, pagination. Filter keys are field display names; values are equality (simple) or operator objects (contains/startsWith/endsWith/min/max/above/below/between/after/before/empty/exists/yes/no/is/not/excludes). Use {or:[…]} for OR; multiple keys are AND-ed. Use 'me' for User-field self-match. See FilterOperators in inistate://schema/runtime for the full set.

Access: non-admin users cannot query the unfiltered default 'Everything' view on modules that have listings — pass listing with one of their accessible listings (an access-denied response names them).

Token control: use fields to restrict the returned data to just the columns you need. For modules with many fields this can shrink the response by an order of magnitude. Every item carries entryId, documentId and state whatever fields holds; the other system fields (date, createdBy, createdDate, updatedBy, updatedDate, assignees, due) come with the full row, but when fields is given only if it names them.

Check each item's state before totalling, counting or ranking entries: a Cancelled or Draft entry usually must not count. get_module_schema's stateDetails says what each state means.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`state`	No
`fields`	No	Field display names (or raw field names) to include in each entry's `data`. Strongly preferred over returning everything when the module has many or large fields — prunes both DB I/O and response tokens. Omit only when you actually need the full row. entryId, documentId and state are always returned; name any other system field (date, createdBy, createdDate, updatedBy, updatedDate, assignees, due) here to get it.
`module`	Yes	Module name from list_modules
`search`	No	Free-text search across document ID, state, and text-like fields; supports * and ? wildcards
`sortBy`	No
`filters`	No
`listing`	No	Listing (saved view) name to query, case-insensitive; 'archive' targets archived entries. Defaults to the unfiltered 'Everything' view, which is admin-only on modules with listings — non-admins must name an accessible listing (an access-denied response lists them).
`pageSize`	No	Default 50, max 500
`currentPage`	No
`workspaceId`	No	Workspace ID. Omit if set via env or set_workspace; required in stateless/remote mode.
`sortDirection`	No		asc

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.3.1Oct 17, 2026

changedInput schema / properties / fields / description

Previous value: -"Field display names (or raw field names) to include in each entry's `data`. Strongly preferred over returning everything when the module has many or large fields — prunes both DB I/O and response tokens. Omit only when you actually need the full row. System fields are always returned."New value: +"Field display names (or raw field names) to include in each entry's `data`. Strongly preferred over returning everything when the module has many or large fields — prunes both DB I/O and response tokens. Omit only when you actually need the full row. entryId, documentId and state are always returned; name any other system field (date, createdBy, createdDate, updatedBy, updatedDate, assignees, due) here to get it."

addedInput schema / properties / listing

Added value: +{
+  "description": "Listing (saved view) name to query, case-insensitive; 'archive' targets archived entries. Defaults to the unfiltered 'Everything' view, which is admin-only on modules with listings — non-admins must name an accessible listing (an access-denied response lists them).",
+  "type": "string"
+}

First observedv1.1.1Jul 28, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, yet the description adds substantial non-structured behavior: non-admin users cannot query the default 'Everything' view and must pass an accessible `listing` (access-denied names them), plus token-control behavior via `fields` and the exact system fields always vs conditionally returned.

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-loads the one-line purpose before three labeled context blocks (filtering, access, token control, state check), so structure is strong and each paragraph earns its place. It is on the long side, but the density is justified by the 11-parameter, nested-filter surface.

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 carries the return-shape burden and does so by explaining `data` pruning and always-present entryId/documentId/state fields. It remains silent on pagination metadata and several simple parameters (sortBy, currentPage), so a small completeness gap persists.

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 55%, and the description compensates heavily for the hard parts: filter key = field display name, operator-object grammar (contains/startsWith/min/max/between/after/before/empty/exists/is/not/excludes), {or:[…]} and implicit AND, and 'me'. However, sortBy, state, and currentPage still receive no meaning anywhere, leaving gaps.

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?

Opens with a specific verb+resource plus scope: 'Query entries with filters, sorting, pagination.' An agent can distinguish this list-level retrieval from get_entry (single) and aggregate_entries, but the description never names those siblings explicitly, so differentiation is inferred from scope rather than stated.

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?

Provides rich operational context: filter operator grammar, OR/AND composition, 'me' self-match, and the rule to check `state` before totalling/ranking. It lacks explicit when-to-use-this-vs-alternatives routing (e.g., point counting tasks at aggregate_entries), so it is clear context without exclusion guidance.

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

List Entries

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools