Skip to main content
Glama

Lawcus MCP by usefulapi

lawcus_report_invoice_history

Read-only

Lawcus report (needs the Admin role): summary of issued invoices for a period.

Input Schema

NameRequiredDescriptionDefault
endNoPeriod end, UTC: yyyy-mm-dd (through 23:59:59) or yyyy-mm-dd hh:mm:ss.
startNoPeriod start, UTC: yyyy-mm-dd (from 00:00:00) or yyyy-mm-dd hh:mm:ss.
user_idNoNumeric user id.
group_byNoGrouping, e.g. client (accounts receivable, invoice history, matter balance) or teammate (time entries).
client_idNoNumeric client contact id.
practice_idNoNumeric practice area id.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds a genuinely non-obvious behavioral fact: the Admin role is required. It says nothing about result limits, pagination, or what the summary aggregates, which remain gaps beyond the annotation coverage.

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?

A single tight sentence with the resource statement front-loaded and the role requirement attached. No filler, though the brevity edges toward under-specification rather than pure economy.

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?

With no output schema, the description should say more about what the summary contains and how group_by changes the shape, which it does not. Given zero required parameters and a fully documented schema, though, it is close to sufficient for an agent to call it 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 description coverage is 100%, so all six parameters (start, end, user_id, group_by, client_id, practice_id) are already documented, including date format and grouping examples. The description adds only the vague phrase 'for a period', which is fully covered by the schema, so baseline 3 applies.

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?

States a specific verb+resource: a report summarizing issued invoices over a period. The resource (issued invoices) is distinguishable from the sibling reports (accounts receivable, client trust, matter balance, payments collected, revenue, time entries) without naming them explicitly.

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 description implies when to use it (period-based invoice summary) and gives an important prerequisite (Admin role), but never contrasts it against the neighboring report tools or states any exclusions, so the agent must infer selection criteria.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.