uol-mcp

Business snapshot

get_business_snapshot

Read-onlyIdempotent

Retrieve a consolidated business snapshot covering current vs previous month revenue, expenses, profit, VAT periods, receivables, pending documents, and bank balances.

Instructions

"How is the company doing?" in one call: this month vs last month (revenue, expenses, profit, whether booked yet), the VAT period due next and the running one, unpaid and overdue receivables, uploaded documents waiting for the accountant, and bank balances. Sections that fail (e.g. missing permission) are null and listed in errors; sections read only partly are listed in incomplete. Use the dedicated tools for detail.

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description
`bank`	Yes	UOL stores monthly opening-balance snapshots (1st of the month), not live balances; always quote the as_of date.
`as_of`	Yes
`errors`	Yes
`company`	Yes
`incomplete`	Yes	Sections where UOL had more rows than one call reads; their figures may be too low
`this_month`	Yes
`receivables`	Yes
`vat_due_next`	Yes	The period whose return and payment are due next — what will be paid
`booked_through`	Yes	Date of the latest revenue or expense posting: the ledger is booked up to here; later months are not booked yet
`previous_month`	Yes
`vat_current_period`	Yes	The running period, still open
`documents_to_process`	Yes	Uploaded documents in state unprocessed

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.6.1Nov 7, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the general read-only hints provided in annotations, the description provides vital behavioral context. It explicitly states how the tool handles partial data or failure, detailing that missing permissions result in null/error listings and how partial reads are flagged ('listed in incomplete').

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?

The description is highly dense yet exceptionally well-structured. It begins with a compelling high-level hook, uses a comprehensive list to enumerate scope, and ends with actionable behavior instructions, maximizing information density per sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This tool is a complex aggregate, pulling data from many different categories (VAT, bank balances, receivables, documents). Because it has zero inputs, the description must account for its entire scope and behavior upon success or partial failure, which it does thoroughly.

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?

Since the input schema is empty (0 parameters), the description cannot add semantic meaning to inputs. Given the 100% schema description coverage and zero parameters, the baseline high score is appropriate.

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 clearly defines the tool as providing a consolidated, high-level summary of financial health ('How is the company doing?'). It explicitly lists the aggregated data points (revenue, VAT, receivables, etc.), distinguishing its function as an overview tool from the granular sibling tools provided.

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?

The definition provides clear guidance on its appropriate use by advising the agent to 'Use the dedicated tools for detail.' This sets an explicit boundary for when the agent should pivot to specialized functions rather than relying on this broad tool.

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

Deploy Server