Skip to main content
Glama
svharivinod

TallyPrime MCP Server

by svharivinod

get_stock_summary

Retrieve inventory stock summary from TallyPrime for a given date to check stock quantities and values.

Instructions

Get the Stock Summary (inventory) from TallyPrime as of a date.

Args: as_of_date: Date YYYYMMDD (e.g. '20260516').

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
as_of_dateYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The MCP tool handler for 'get_stock_summary'. It is decorated with @mcp.tool(), takes an as_of_date string parameter, calls client.get_stock_summary(), and returns the JSON result as a formatted string.
    @mcp.tool()
    async def get_stock_summary(as_of_date: str) -> str:
        """
        Get the Stock Summary (inventory) from TallyPrime as of a date.
    
        Args:
            as_of_date: Date YYYYMMDD (e.g. '20260516').
        """
        try:
            data = await client.get_stock_summary(as_of_date)
            return f"Stock Summary as of {as_of_date}:\n\n" + json.dumps(data, indent=2)
        except TallyError as e:
            return f"Error: {e}"
  • The TallyClient method that sends the stock summary XML request to TallyPrime and parses the response into a dict.
    async def get_stock_summary(self, as_of_date: str) -> dict:
        from .xml_builder import get_stock_summary_xml
        return self._elem_to_dict(self._parse(await self.send_xml(get_stock_summary_xml(as_of_date))))
  • Builds the XML request payload for the Stock Summary report, using the provided as_of_date.
    def get_stock_summary_xml(as_of_date: str) -> str:
        return f"""<ENVELOPE>
      <HEADER>
        <TALLYREQUEST>Export Data</TALLYREQUEST>
      </HEADER>
      <BODY>
        <EXPORTDATA>
          <REQUESTDESC>
            <REPORTNAME>Stock Summary</REPORTNAME>
            <STATICVARIABLES>
              <SVEXPORTFORMAT>$$SysName:XML</SVEXPORTFORMAT>
              <SVTODATE>{as_of_date}</SVTODATE>
            </STATICVARIABLES>
          </REQUESTDESC>
        </EXPORTDATA>
      </BODY>
    </ENVELOPE>"""
  • The register_all function that calls reports.register(mcp, client), which triggers the @mcp.tool() decorator and registers get_stock_summary as an MCP tool.
    def register_all(mcp: FastMCP, client: TallyClient):
        company.register(mcp, client)
        ledgers.register(mcp, client)
        vouchers.register(mcp, client)
        reports.register(mcp, client)
  • The register function in reports.py that receives the mcp and client instances and defines the tool via @mcp.tool() decorator.
    def register(mcp, client: TallyClient):
Behavior3/5

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

No annotations are provided, so the description bears the full burden. It implies a read-only operation with 'Get', but does not mention side effects, authorization needs, or return format (though output schema exists). The description is adequate but lacks explicit behavioral details.

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?

Description is extremely concise with two clear sentences, no redundant information, and front-loaded purpose. Every sentence adds value.

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?

Given the tool has only one required parameter and an output schema, the description covers purpose and parameter format adequately. It lacks behavioral transparency but is otherwise complete for a simple date-filtered query tool.

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?

With 0% schema description coverage, the description adds essential format guidance ('Date YYYYMMDD') and an example, which is meaningful beyond the schema's string type declaration. It compensates well for the lack of schema-level parameter documentation.

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?

Description clearly states the tool retrieves Stock Summary (inventory) from TallyPrime as of a specific date, using action verb 'Get' and specifying the resource and context, which distinguishes it from siblings like 'get_balance_sheet' or 'create_sales_voucher'.

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?

Implicitly clear that this tool is for inventory summary queries, and sibling tool names (e.g., 'get_balance_sheet', 'get_profit_loss') indicate different reports, but no explicit when-to-use or when-not-to-use guidance is provided.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/svharivinod/tallyprime-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server