Retrieve all numerical series and numbering rules configured for document types. Use this read-only operation to audit or verify accounting number sequences.
List numerical series (numbering rules) for all document types. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| skip | No | ||
| take | No | ||
| order | No | GraphQL order clause | |
| where | No | GraphQL where filter |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the explicit 'Read-only' statement carries important behavioral weight and assures the agent that the operation has no side effects. The description also indicates that it lists across all document types. It could add pagination or response-format details, but the core behavioral traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two terse sentences with no filler. The core verb and object are front-loaded, the parenthetical adds useful clarification, and 'Read-only' is a compact safety signal. Every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with four optional parameters and no output schema, the description provides adequate context: it names the resource, clarifies the numbering-rule meaning, and states the operation is read-only. The remaining details, such as pagination defaults and filtering syntax, are left to the schema, which is acceptable for this low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about skip, take, order, or where; two of the four parameters are only documented by the schema's sparse 'GraphQL order clause' and 'GraphQL where filter' descriptions. Because schema coverage is only 50%, the description needed to compensate, but it does not explain pagination semantics or how filtering by document type relates to the 'all document types' claim.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('numerical series (numbering rules)') and states the scope ('for all document types'). The parenthetical clarifies what a numerical series is, and the description is distinct from the many document- and finance-oriented sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool instead of alternatives such as m3_graphql or other listing tools. The description does not state whether this is the preferred read-only lookup or what conditions would make a different tool more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.