Skip to main content
Glama

spending_recipient_summary

Read-onlyIdempotent

Summarize a company's federal awards: total dollars and top awards for a recipient name in a category (contracts by default). Useful for due diligence and to see who the government pays.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoTop awards to list (default 5, max 25).
categoryNoAward category: 'contracts' (default), 'grants', 'loans', or 'other'.
recipientYesRecipient company/org name.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / limit / maximum
      Added value: +25
    • addedInput schema / properties / limit / minimum
      Added value: +1
    • changedInput schema / properties / limit / type
      Previous value: -"number"New value: +"integer"
  2. First observed

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds the federal scope and the aggregation behavior (totals + top N, contracts as default category), which is useful, but says nothing about result format, ordering, or how totals are computed.

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?

Two compact sentences with no filler; the deliverable (totals and top awards) comes first and the scope details follow. Slightly dense but every clause carries information.

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 does the work of naming the return content (total dollars, top awards) and the default category. An agent has enough to invoke it correctly; only ordering/formatting of results remains unspecified.

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 three parameters are already documented, and the description merely restates the default category value that the schema already specifies. Baseline 3 applies since the schema carries the parameter burden.

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?

States a specific verb (summarize) plus a precise resource (a company's federal awards), and enumerates the output content: total dollars and top awards, scoped by recipient name and category. An agent can distinguish this from the sibling spending_search_awards (raw search) and spending_award_details (single award) without opening a schema.

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?

Gives a use case ("due diligence", "see who the government pays") but never states when to prefer this over its close siblings spending_search_awards or spending_award_details, nor any exclusions or prerequisites. Usage is implied rather than routed.

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.