Skip to main content
Glama
cliwant

mcp-sam-gov

by cliwant

usas_get_recipient_profile

Retrieve complete recipient profile including alternate names, DUNS, UEI, parent organization, business types, location, and financial totals by providing a recipient ID from a prior search.

Instructions

Full recipient detail by recipient_id (from usas_search_recipients). Returns alternate_names (M&A history), DUNS, UEI, parent linkage, business_types, location, total_amount, total_transactions.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
recipientIdYesFrom usas_search_recipients — e.g. 'ed02855e-...-P'

Implementation Reference

  • Input schema for usas_get_recipient_profile — validates recipientId string from usas_search_recipients.
    const UsasGetRecipientInput = z.object({
      recipientId: z.string().describe("From usas_search_recipients — e.g. 'ed02855e-...-P'"),
    });
  • src/server.ts:433-438 (registration)
    Tool registration in the TOOLS array — maps the name 'usas_get_recipient_profile' to its description and inputSchema.
    {
      name: "usas_get_recipient_profile",
      description:
        "Full recipient detail by recipient_id (from usas_search_recipients). Returns alternate_names (M&A history), DUNS, UEI, parent linkage, business_types, location, total_amount, total_transactions.",
      inputSchema: UsasGetRecipientInput,
    },
  • src/server.ts:749-752 (registration)
    Case handler in runTool() switch — calls usas.getRecipientProfile() with the parsed recipientId.
    case "usas_get_recipient_profile":
      return await usas.getRecipientProfile(
        UsasGetRecipientInput.parse(args).recipientId,
      );
  • Actual handler function: getRecipientProfile(recipientId) — calls USAspending GET /recipient/{id}/ and returns full recipient details including alternate_names, DUNS, UEI, parent linkage, business_types, location, total_amount, total_transactions.
    export async function getRecipientProfile(recipientId: string) {
      type Resp = {
        name?: string;
        alternate_names?: string[];
        duns?: string;
        uei?: string;
        recipient_id?: string;
        recipient_level?: string;
        parent_id?: string;
        parent_name?: string;
        business_types?: string[];
        location?: {
          address_line1?: string;
          city_name?: string;
          state_code?: string;
          country_name?: string;
          zip5?: string;
        };
        total_transaction_amount?: number;
        total_transactions?: number;
      };
      const json = await getUsas<Resp>(
        `recipient/${encodeURIComponent(recipientId)}/`,
      );
      return {
        name: json.name ?? "",
        alternateNames: json.alternate_names ?? [],
        duns: json.duns,
        uei: json.uei,
        recipientId: json.recipient_id,
        level: json.recipient_level,
        parentId: json.parent_id,
        parentName: json.parent_name,
        businessTypes: json.business_types ?? [],
        location: json.location ?? {},
        totalAmount: json.total_transaction_amount ?? 0,
        totalTransactions: json.total_transactions ?? 0,
      };
    }
  • Import of the usas module which contains the getRecipientProfile handler function.
    import * as usas from "./usaspending.js";
Behavior2/5

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

No annotations provided; the description only lists return fields without disclosing error handling, mutability, or rate limits.

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?

Two sentences, front-loaded with purpose, and each word is informative without redundancy.

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?

Covers return contents and parameter source well; lacks details about error behavior or data currency, but is sufficient for a single-parameter lookup tool.

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?

The description adds context to the recipientId parameter by stating its provenance from usas_search_recipients and providing an example format, exceeding the schema description.

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 states the tool returns full recipient details by recipient_id, listing specific fields like alternate_names, DUNS, UEI, etc., which distinguishes it from the sibling search tool.

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?

It implies usage after usas_search_recipients, but does not explicitly mention when not to use it or alternatives like usas_search_awards_by_recipient.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/cliwant/mcp-sam-gov'

If you have feedback or need assistance with the MCP directory API, please join our Discord server