Why Use the Tango Python and Node SDKs

You can call the Tango API with any HTTP client. But if you're building in Python or Node/TypeScript—the languages that power a significant portion of the web, data science, and most LLM agents and MCP (Model Context Protocol) servers—the official tango-python and tango-node SDKs are built to cut boilerplate, give you strong types and predictable errors, and make response shaping easy—so you spend less time wiring requests and more time on your product.

In this post we'll cover what you get from the SDKs, why they're a natural fit for LLM agents and MCPs, how to get started in both languages, and when to use which.

What the SDKs give you

Both SDKs are first-party clients for the Tango API. They share the same design goals:

• Response shaping — Request only the fields you need (often 60–80% smaller payloads). Pass a shape string or use predefined shapes like ShapeConfig.CONTRACTS_MINIMAL. For the full story on why shaping matters, see The Value of Response Shaping.
• Type safety — In Python you get runtime-generated TypedDicts and IDE autocomplete; in Node you get TypeScript types derived from your shape strings. Fewer typos and clearer contracts.
• Consistent error handling — Typed exceptions for auth failures, validation errors, rate limits, and not-found. No guessing from raw status codes.
• Production-ready — Test suites (including integration tests against the real API), docs, and a stable, versioned surface.

So instead of hand-rolling fetch/requests, building your own pagination and error mapping, and manually adding shape to every URL, you get a client that does that work for you.

LLM and automation workflows

Python and Node are the default choice for LLM agents, MCP servers, and automation pipelines. And our SDKs are designed to fit into that world well: response shaping keeps payloads small so you use fewer tokens when feeding data into a model; typed responses make it easy to expose Tango as a tool with a clear schema; and consistent errors let your agent or MCP handle rate limits and validation failures without guessing. Whether you're building an agent that looks up federal awards or an MCP server that adds Tango to an AI coding environment, the same client—Python or Node—gets you there with minimal glue.

How to get started

Python

• Repo: github.com/makegov/tango-python
• Install: uv pip install tango-python (Python 3.12+)
• Docs: https://github.com/makegov/tango-python/tree/main/docs

import os
from tango import TangoClient

client = TangoClient(api_key=os.environ["TANGO_API_KEY"])

contracts = client.list_contracts(
    shape="key,piid,recipient(display_name,uei),total_contract_value",
    keyword="software",
    limit=10
)

for contract in contracts.results:
    print(contract["piid"], contract["recipient"]["display_name"])

Highlights: TypedDicts from your shape strings, dictionary or attribute access (contract["piid"] or contract.piid), async-ready patterns, and VCR.py integration tests in CI. Omit api_key and the client uses TANGO_API_KEY from the environment.

Node/TypeScript

• Repo: github.com/makegov/tango-node
• Install: npm install @makegov/tango-node (Node 18+)
• Package: @makegov/tango-node

import { TangoClient, ShapeConfig } from "@makegov/tango-node";

const client = new TangoClient({ apiKey: process.env.TANGO_API_KEY });

const contracts = await client.listContracts({
  shape: ShapeConfig.CONTRACTS_MINIMAL,
  keyword: "cloud services",
  awarding_agency: "4700",
  limit: 10,
});

for (const c of contracts.results) {
  console.log(c.piid, c.recipient.display_name);
}

Highlights: TypeScript-first with types from your shapes, same API surface as Python (listAgencies, listContracts, getEntity, etc.), ESM and native fetch, and typed errors (TangoAuthError, TangoValidationError, TangoRateLimitError). Omit apiKey and the client uses process.env.TANGO_API_KEY.

When to use which

• Python — LLM agents, MCP servers, data pipelines, scripts, and Jupyter notebooks. The SDK's type hints and shape-driven TypedDicts fit well with agent frameworks and data tooling.
• Node/TypeScript — MCP servers, LLM tool backends, serverless functions, and front-end build steps that need to talk to Tango. Same shaping, pagination, and filters with minimal config.

Both support the same filters (keyword, agency, recipient, dates, NAICS, etc.), the same shape syntax, and the same pagination model (count, next, previous, results). If you switch stacks, the mental model is the same.

Key takeaways

1. SDKs vs raw HTTP — The official SDKs handle auth, pagination, errors, and response shaping so you don't have to.
2. Types — Python gets TypedDicts and autocomplete; Node gets TypeScript types from your shapes.
3. Same design in both — One API, two languages; switch or support both with minimal mental overhead.

If you're building on the Tango API in Python or Node, the tango-python and tango-node SDKs are the fastest way to get from zero to production with less boilerplate and fewer bugs.