Skip to main content
Glama

Lawcus MCP by usefulapi

lawcus_report_revenue

Read-only

Lawcus report (needs the Admin role): revenue by attorney 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.
client_idNoNumeric client contact id.
matter_idNoNumeric matter id.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the Admin authorization requirement, which is genuinely useful, but says nothing about aggregation behavior or what happens when filters are omitted.

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 compact sentence with the scope and role requirement front-loaded. It is efficient, though the compression drops detail an agent would want, such as default behavior with no filters.

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

Completeness3/5

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

All five parameters are optional and the description never says what the report returns with no start/end or no user_id — all attorneys, all time, or an error. With no output schema, that gap matters more, though the 100% schema coverage and annotations carry much of the load.

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 five parameters (start, end, user_id, client_id, matter_id) are documented with formats and bounds. The description's 'for a period' and 'by attorney' loosely map to start/end and user_id but add no syntax or semantics 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?

States a specific resource and grouping: revenue by attorney over a period, plus the role gate. It is distinguishable from siblings like lawcus_report_payments_collected or lawcus_report_time_entries, though it never names an alternative 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 Admin-role prerequisite is stated, which is real guidance, but there is no when-to-use vs when-not framing and no direction toward the other report tools when this one is the wrong fit.

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.