PNPC-MCP-Tally-Prime

get_cash_flow

Read-only

Fetch a cash flow statement from TallyPrime for a selected date range, returning Tally's native period breakdown for financial reporting.

Instructions

Get the Cash Flow statement from TallyPrime for a date range — Tally's own canned report, reachable directly via a plain Export Data request (confirmed live, unlike the VAT/GST return reports). Returns Tally's native monthly-period breakdown shape (DSPPERIOD/DSPACCINFO arrays) as-is.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "from": "<from>",
      "to": "<to>"
    },
    "name": "get_cash_flow"
  }
}

Input Schema

Name	Required	Description	Default
`to`	Yes	End date, DD-MM-YYYY
`from`	Yes	Start date, DD-MM-YYYY

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.11.2Sep 4, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint: true, so the safety profile is covered. The description adds beyond the structured data by disclosing the output shape ('DSPPERIOD/DSPACCINFO arrays as-is') and the fact that the report is confirmed live, which is meaningful behavior context for the agent.

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?

Two sentences cover purpose, reachability, liveliness, and output shape with no redundancy. The extra implementation detail (Export Data request) slightly lengthens the first sentence but is arguably useful context. Overall it is well-structured and front-loaded.

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 date-range read tool with no output schema, the description is sufficient: it states what it returns, the recognized report, and its availability. It could mention error handling or date invalidation, but such details are less critical given the annotation and schema coverage.

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?

Both parameters are fully described in the schema with DD-MM-YYYY format. The description merely restates 'date range' without adding extra meaning. Since schema coverage is 100%, a baseline of 3 is appropriate even though the description adds no parameter-specific details.

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 states a specific verb ('Get') and a specific resource ('Cash Flow statement from TallyPrime') with a date range. It explicitly contrasts against the VAT/GST return reports, differentiating it from sibling report tools. No ambiguity about report type or scope.

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 gives clear context: this is Tally's canned Cash Flow report, reachable via a plain Export Data request, and is confirmed live -- unlike the VAT/GST reports. This provides a when-to-use signal and excludes a class of alternatives, even though it does not name sibling tools like get_funds_flow.

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

Deploy Server