Agent framework

Using this with LangChain

MCP tool adapter, or a thin wrapper over the REST API.

Setup

A URL and a header, and the configuration differs only in where this client keeps it. The step-by-step, the config block to paste and the mistake people actually hit with LangChain are in the technical documentation: setting up LangChain.

That page is kept current against the API rather than restated here, and it covers seventeen clients — including the bridge for anything that only speaks stdio.

Budget from reformulations, not from users

Framework agents reformulate aggressively when a first result looks unsatisfying, so one user question routinely becomes three to five calls. This is the single biggest cause of surprise cost on this integration, and it is invisible in testing because you naturally test one query at a time and watch it succeed. Estimate from expected reformulations per question, pass max_credits on each call, and set a per-run credit budget so a loop that fails to converge cannot consume a month of credits in an evening.

Order and describe your tools deliberately

Given both an article search tool and a story grouping tool with similar descriptions, an agent will usually take the first plausible one. If that is article search, it will fill its own context with syndicated duplicates and then reason over them. Put story grouping first and describe it as the default for event questions, reserving article search explicitly for coverage analysis. This costs one line and is the difference between a working integration and one that is quietly wasting most of its context window.

Retries interact badly with rate limits

Treat rate-limit responses as a distinct case from network errors, and then distinguish the two kinds. The per-minute credits refill continuously, so the retry-after is accurate and exponential backoff there simply idles on an allowance you already paid for. Running out of the month's credits returns the same status and will not clear for days; retrying it is pure waste. The JSON body's code is insufficient_credits for the second case and credit_rate_limited for the first. This bites harder here than elsewhere because the agent loop can be several layers away from wherever you configured the client.

Where LangChain is the wrong place for this

A framework is not worth the abstraction when there is exactly one tool and one call. If your application asks a fixed question on a schedule and formats the answer, a direct HTTP request is less code, easier to debug and cheaper to run, and the framework adds a retry policy, a tool-selection step and a reformulation loop you did not need. The framework earns its place when the agent genuinely has to choose between several tools, or when a single question requires several retrievals whose shape is not known in advance. It is also the wrong layer for enforcing cost limits: a per-run request budget belongs outside the agent loop, because the loop is precisely the thing that will otherwise spend the budget deciding whether it is finished.

Notes and the usual pitfall

Framework agents reformulate queries aggressively under uncertainty, so the request multiplier per user question is often three to five rather than one. Budget from that, not from user count.
Prefer the story-grouping tool in the tool list and describe it as the default; otherwise the agent will reach for article search and fill its own context.

Watch for: The default retry behaviour treats every rate-limit response the same way. Three different conditions return 429 here, and only two are worth waiting for: spent per-minute credits or messages refill continuously and want the short retry-after, while running out of the month's credits will not clear until the period resets. Tell them apart with the code in the JSON body: insufficient_credits is the one not to retry.