Skip to main content
Glama

find_clients

Read-only

Search clients by name, company, or email to review invoiced amounts, payments received, and outstanding balances.

Instructions

Search clients and see what each has been invoiced, has paid and still owes.

Input Schema

NameRequiredDescriptionDefault
limitNo
queryNoPart of a name, company or email. Empty lists everyone.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

B3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful context that results carry financial aggregates, but says nothing about the default 20-record cap, result ordering, or whether the totals are lifetime or date-bounded.

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?

One compact sentence with the resource up front and the returned data stated immediately. No filler, though it is so terse that it omits selection guidance the agent needs.

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?

An output schema exists, so return values needn't be spelled out, and the read-only nature is covered by annotations. What remains missing for a search tool in a 20-sibling set is the routing guidance against get_client/list_invoices and any hint about the result cap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 50%: query is well documented ('Part of a name, company or email. Empty lists everyone.') but limit has no description anywhere. The description contributes nothing about either parameter and so fails to compensate for the coverage gap.

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 ('Search clients') and adds the distinguishing payload: per-client invoiced, paid and outstanding totals. It does not explicitly distinguish itself from sibling get_client or list_invoices, but the aggregation angle is clear enough to select on.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance and no mention of alternatives. Nothing tells the agent whether to use this versus get_client for a single client or list_invoices for document-level data; the search semantics are only implied by the verb.

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