Skip to main content
Glama
IsidoreSoftware

Ogarni.AI MCP Server

List Weekly Summary Periods

ogarniai_get_weekly_summary_periods
Read-onlyIdempotent

List weekly finance summary periods with pagination. Each period includes start/end dates, total amount, and summary text.

Instructions

List available weekly summary periods with pagination.

Args:

  • page (number, optional): Page number (default: 1)

  • pageSize (number, optional): Items per page (default: 10)

Returns: JSON array of period summaries with periodStart, periodEnd, totalAmount, summary text

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number
pageSizeNoItems per page

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive behavior. The description adds useful behavioral context by stating that the result is paginated and describing the returned fields (periodStart, periodEnd, totalAmount, summary text), which is especially valuable since no output schema exists.

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?

The purpose is front-loaded in a single sentence, and the Args/Returns sections are compact and readable. There is minor redundancy with the input schema, but the description remains focused and appropriately sized.

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?

For a simple paginated list operation with no output schema, the description covers the essential invocation context: endpoints, parameters, pagination, and return shape. It does not define what 'available' means or how periods relate to current/previous summaries, but this is not critical for calling the tool correctly.

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 coverage is 100%, with both page and pageSize fully described, including defaults and bounds. The description repeats this information without adding additional meaning or constraints beyond the schema.

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?

The description states a clear action ('List') and a specific resource ('available weekly summary periods'), and mentions pagination. It is distinguishable from sibling tools like get_weekly_summary or get_summary_by_period by the focus on listing periods rather than retrieving a specific summary.

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?

The context of use is implied: call this when you want the list of weekly summary periods. However, there is no explicit guidance on when not to use it or which sibling tool to prefer for related operations, such as retrieving a specific period's summary.

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