Agent with tools from MCP servers

I treat the agent as acting for the user, never as a super-user. The API validates the user's SSO token, then a token broker exchanges it for short-lived, scoped tokens per MCP server. Those go into each MultiServerMCPClient connection as headers, so the client is built per request or per user and never shared across users. The MCP servers enforce their own authorisation, so the agent can't see a ticket the user can't see. On a 401 I try one token refresh in a wrap_tool_call hook; if it still fails, I return an error ToolMessage saying which access is missing, so the model can tell the user instead of looping. Every call is audited with the real user identity.

Sourced from Docs by LangChain (MCP)

The chat request arrives with the engineer's SSO token. The Agent API validates it, resolves their groups and picks or creates a thread_id so the checkpointer keeps conversation state. A token broker swaps the user's identity for short-lived, narrowly scoped tokens for the ticketing, docs and database MCP servers. MultiServerMCPClient is built with one connection per server, and get_tools() loads the tools. We filter them against an allowlist and prefix them per server. create_agent gets a model from init_chat_model, those tools, a system prompt, a checkpointer and middleware. The loop runs on LangGraph. Retry and error middleware handle failures, and HumanInTheLoopMiddleware pauses on writes. The answer comes back through response_format with sources, and every tool call and decision goes to the audit log.

Sourced from Docs by LangChain (MCP)

A system prompt is guidance, not enforcement. A service account with broad rights creates a confused-deputy problem: a prompt injection, a model mistake or a crafted request could make the agent read or change data the user could never reach directly. With token exchange, each MCP server sees a short-lived token scoped to that user and that server. The server's own authorisation decides what is allowed, which matches the hard requirement that no tool runs with broader credentials than the requester has. It also gives honest audit trails, because downstream systems log the real user rather than 'ops-agent'. Short lifetimes and narrow scopes limit the damage if a token leaks. The trade-off is extra latency and a dependency on the broker, which we handle with caching until shortly before expiry.

Sourced from Docs by LangChain (MCP)

I use defence in depth so that no single layer has to be perfect. First, the allowlist removes write tools the agent never needs. Second, HumanInTheLoopMiddleware lists every remaining write tool, such as create_ticket and update_ticket, in interrupt_on, so the run pauses before execution until an approver decides. Third, the user-scoped token means even an approved write can only do what the requester could do themselves. Fourth, the database connection uses a read-only role, so writes are impossible there at the credential level. Fifth, a test asserts that every tool tagged as a write in our registry appears in interrupt_on. Deployment fails if a new write tool is missing. Finally, the audit log records the approver and decision, so any gap shows up quickly.

Sourced from Docs by LangChain (MCP)

Tool outputs are untrusted data, and ticket text or docs are classic indirect prompt injection paths. We cannot rely on the model always ignoring such text, so the design limits impact rather than assuming prevention. Closing tickets is a write. It hits a HumanInTheLoopMiddleware interrupt, and an approver sees exactly which tickets and arguments are involved. Any action runs under the requester's scoped token, so it cannot reach beyond their rights. The model call limit stops long loops that injected text might trigger. The system prompt states that content returned by tools is data, not instructions. We can add a custom after_model check that flags bulk write proposals. The audit log records the chain of reads that led to the proposal, which helps us investigate and improve defences.

Sourced from Docs by LangChain (MCP)

Failures are classified. Transient ones, like timeouts or 5xx from a read tool, go through tool retry middleware with backoff, and I only retry idempotent tools. Validation errors, such as a bad query argument, are caught in a wrap_tool_call hook and returned as an error ToolMessage with the server's message, so the model can fix its arguments on the next turn. Auth errors get one refresh and then a clear message. A model call limit caps the loop so a broken server can't burn tokens forever. Because state lives in the checkpointer, the user can retry on the same thread, and the trace in LangSmith shows exactly which server and call failed.

Sourced from Docs by LangChain (MCP)

Because the tool list is controlled by whoever ships the server, not by me. A new release could add a delete or bulk-update tool, and the agent would pick it up automatically. More tools also mean a longer prompt and worse tool selection. So after get_tools I apply an allowlist, prefix names by server to avoid collisions, and route writes through HumanInTheLoopMiddleware. If the toolset is still large, the LLM tool selector middleware narrows it per turn. The database server gets a read-only role regardless of what the agent asks for. Defence sits in the servers and the credentials, with the prompt only as guidance.

Sourced from Docs by LangChain (MCP)

The credentials belong to the request, so we build the client per request, or per user and thread, with headers holding that user's brokered tokens. We never share one client instance across users, because a tool bound to one user's headers could then run for another. Tool discovery is the expensive part, so we can cache what is not secret: the list of tool names, descriptions and input schemas per server and version, already filtered against the allowlist. On each request we bind those definitions to a fresh, user-scoped connection. Tokens are cached in the broker keyed by user and audience, with a time-to-live shorter than the token lifetime. The rule is simple: cache schemas freely, but never let credentials outlive the request context they were minted for.

Sourced from Docs by LangChain (MCP)

The interrupt is stored in the checkpointer, so the paused graph state survives. Credentials, however, are not part of that state, and they must not be. On resume, the Agent API re-validates the request context. It checks that the thread belongs to the original requester and that the approver is authorised. It then asks the broker for fresh tokens for the requester and rebuilds the MCP client before resuming the same thread_id with the decision. If the requester's access has been revoked in the meantime, token exchange fails. The tool call then becomes an error ToolMessage, and nothing is written. We also set a maximum age for pending approvals, after which the request is auto-rejected, because stale approvals act on context that may no longer be true.

Sourced from Docs by LangChain (MCP)

Approvers come from a defined group per tool. For example, ticket leads approve update_ticket. We can block self-approval for sensitive tools. Edit lets the approver change arguments, but the edited call is still checked against the tool's input schema and the allowlist. It still runs with the requester's scoped token, not the approver's. So approval adds a human check without granting new rights: if the requester cannot update a ticket in another team's project, the server refuses it even after approval. If a change really needs the approver's privileges, the approver should perform it as their own action. The audit log stores the original arguments, the edited arguments, the approver identity and the decision, so edits are fully traceable.

Sourced from Docs by LangChain (MCP)

Yes, if done naively. A timeout on create_ticket does not tell you whether the ticket was created, so a blind retry can create duplicates. I limit retry middleware to read tools and to errors that are clearly transient, such as connection failures or rate limits. For writes, either there is no automatic retry, or the call carries an idempotency key, for example derived from the thread_id and tool call id, if the ticketing server supports deduplication. If a write fails ambiguously, the wrap_tool_call hook returns an error ToolMessage saying the outcome is unknown. The model can then check with a read tool, such as searching for the ticket, before trying again. Because a fresh write is a new tool call, it would go through human approval again.

Sourced from Docs by LangChain (MCP)

The checkpointer saves graph state, including the message history, at each step, keyed by thread_id. That gives short-term, thread-scoped memory. Follow-up questions on the same thread see earlier context, and HITL interrupts can resume exactly where they paused. The Agent API creates a thread_id for a new conversation, or reuses the one the client sends after checking ownership. In development an in-memory saver is fine. In production we need a durable, shared store, such as a Postgres-backed checkpointer, because Agent API instances are stateless and scaled horizontally. A resume might land on a different instance, and pending approvals must survive deploys and restarts. We also set retention for old threads, since checkpoints contain conversation content and tool outputs that may be sensitive.

Sourced from Docs by LangChain (MCP)

I'd avoid a generic run_sql tool for an ops agent. Free-form SQL opens up expensive queries, data exfiltration and, with the wrong role, writes. I prefer narrow, parameterised tools such as get_order_status or list_failed_jobs, with defined inputs and outputs. If analysts truly need ad-hoc queries, I'd allow them only under strict limits: a read-only database role mapped from the user's identity, row-level security where available, statement timeouts, row limits, and blocking of non-SELECT statements on the server side. The server must enforce these rules, not the prompt. Result size limits also protect the context window. The trade-off is flexibility versus safety and predictability. For an agent that acts on behalf of many users, narrow tools are easier to audit and authorise.

Sourced from Docs by LangChain (MCP)

Each entry records the timestamp, requesting user, thread_id, tool name with server prefix, an argument summary, the outcome (success, error class or rejected), latency, and for writes the approver identity, decision and any edited arguments. The argument summary is deliberately not a raw dump. We redact secrets and tokens completely and apply PII masking, for example to emails and phone numbers, using the same rules as PIIMiddleware. Large payloads become hashes or references. Tool outputs are generally not logged. The log is append-only, access-controlled and kept under a defined retention policy. That balance lets us answer 'who did what, when, and who approved it' without creating a second copy of the sensitive data the per-user auth model protects.

Sourced from Docs by LangChain (MCP)

I would not fail the whole request just because one server is down. Each server's tool loading is wrapped separately. If docs is unreachable, we load ticketing and database tools, mark docs as unavailable, and add a line to the system prompt or response saying documentation search is currently down. The structured answer then states its sources were limited. Cached tool schemas can't help here, because calls would still fail at execution, so leaving the tools out is clearer for the model. We use health checks and circuit breakers per server so we don't wait on timeouts every request, and we alert on degraded mode. If a required server, such as ticketing for a ticket action, is down, we fail fast with a clear message.

Sourced from Docs by LangChain (MCP)

The API instances stay stateless so any instance can serve any request or resume. Conversation and interrupt state live in the shared, durable checkpointer, keyed by thread_id. Long-term preferences, if used, live in a LangGraph store. Thread ownership metadata sits in a database. Tokens live in the broker's cache, never in process memory beyond a request. MCP clients are built per request. Tool schemas can be cached per instance or in a shared cache. Because runs wait mostly on model and tool I/O, we use async handlers and scale on concurrent runs and latency rather than CPU. Downstream limits often bind first: provider rate limits, broker throughput, MCP server capacity, and checkpointer write rate. So we put per-user and global concurrency limits at the API.

Sourced from Docs by LangChain (MCP)

This is a classic dual-write gap. The external side effect happened, but our records don't show it. On resume from the last checkpoint, the graph might attempt the tool call again and create a duplicate. Mitigations: pass an idempotency key, such as one derived from thread_id and tool call id, so the ticketing server deduplicates a replay. Write a 'pending' audit record before the call and complete it afterwards, so any record left pending after a crash points to an ambiguous write that needs checking. A reconciler can then match pending records against the ticketing system's own audit trail. You can't get atomic commits across our checkpointer and an external system, so idempotency plus reconciliation is the practical approach.

Sourced from Docs by LangChain (MCP)

If two tools share a name, the model cannot tell them apart, and depending on the loading code one may silently shadow the other. That could send a docs query to the database server. After get_tools() we rename every tool with a server prefix, such as ticketing_search, docs_search and db_search. We also make each description state which system it touches. The allowlist is written in terms of these prefixed names, so policy, HITL interrupt_on keys and audit entries all point to exactly one server's tool. We fail startup if two tools still collide after prefixing. Clear names also help the model choose correctly, and the system prompt can then say plainly when to use docs_search versus ticketing_search.

Sourced from Docs by LangChain (MCP)

A thread_id is just an identifier, so it must never act as authorisation. We store thread metadata with the owning user ID, created at thread creation. Every request that loads, continues or resumes a thread checks that the authenticated user is the owner, or, for approvals, an authorised approver for that pending interrupt. Thread IDs are random and unguessable, but that is a backup, not the control. Approvers get a view of the pending tool call and its context only, not the full thread history. This matters because checkpointed state holds tool outputs fetched with the owner's credentials. Showing it to someone else would bypass the per-user authorisation we built with the token broker.

Sourced from Docs by LangChain (MCP)

I define a schema, for example a Pydantic model with answer, sources (a list of system, identifier and link), actions_taken, pending_approvals and a confidence or caveats field, and pass it as response_format to create_agent. The agent then returns a validated, typed object instead of free text, so the chat UI can show sources as links and the audit pipeline can read actions reliably. Sources should be IDs that came back from tool results, such as ticket keys or doc URLs, not text the model made up. We can check them against the tool calls recorded in the run. If validation fails, we return a safe fallback message rather than a half-formed answer.

Sourced from Docs by LangChain (MCP)

It stops runaway loops. Examples are a model calling a failing tool repeatedly, getting into an oscillating plan, or following injected instructions over many steps. Each model call costs money and latency, and each tool call loads the downstream systems. The limit caps model calls per run, and optionally per thread, then ends the run cleanly with a message rather than spinning on. I'd set it from observed traces: look at how many steps legitimate requests take, then set the cap comfortably above the high end of normal so real work is not cut off. When the limit is hit, we audit it and alert if it happens often, because it usually points to a bad tool description or a broken server.

Sourced from Docs by LangChain (MCP)

Model fallback middleware lists alternative models that are tried in order when the primary call fails. The agent keeps working, possibly with somewhat different quality. I'd choose fallbacks that support tool calling and the structured output we need, and test the whole flow with each one, because tool selection and schema compliance can vary between models. Fallback only covers model failures. Tool failures are handled separately by retry and wrap_tool_call. We record which model served each run in traces and the audit log, so quality issues can be linked to fallback use. If all models fail, the API returns a clear error. Any pending HITL interrupts stay safe in the checkpointer for later resumption.

Sourced from Docs by LangChain (MCP)

SummarizationMiddleware handles this. It triggers on a threshold, such as a token count, and replaces older messages with a summary while keeping a recent window of messages intact. That keeps model calls within limits and controls cost. The risks are losing details and summarising sensitive tool output into persistent state, so I'd tune the trigger and keep settings from real incident threads. The summary should keep important facts such as ticket IDs and decisions. Anything that must not be lost, such as approvals, lives in the audit log rather than in context. For very long investigative tasks, a deep agent with a filesystem for notes is an option, but for chat-style ops work summarisation usually suffices.

Sourced from Docs by LangChain (MCP)

By default each tool invocation opens a fresh MCP client session, runs the call and closes it. That is simple and isolates calls, which suits stateless HTTP tools and per-request, per-user clients. The cost is connection and session setup on every call. Some servers keep state across calls, such as a browser or a database transaction, or are expensive to start, like stdio processes. For those, you open an explicit session with the client and load tools from it, so calls share one session for its lifetime. In this design I'd stay stateless for remote servers, because it avoids sessions leaking across users. I'd use explicit sessions only for local stdio tools within a single request's scope.

Sourced from Docs by LangChain (MCP)

I'd build a parameterised model and then fill it in from a pilot. The inputs are: active users, requests per user per day, peak-to-average ratio, model calls per request, tool calls per request, average tokens per model call, and approval rate on writes. Multiplying these gives peak model calls per second, which sets provider rate limits and cost. Peak tool calls per server set MCP server and broker load. Concurrent open runs times state size set checkpointer storage and write rate. Agent API instances are mostly I/O-bound, waiting on models and tools, so concurrency per instance matters more than CPU. I'd measure the real distributions in a pilot, check token broker and checkpointer headroom, and set the model call limit with the cost ceiling in mind.

Sourced from Docs by LangChain (MCP)

Streamable HTTP suits shared, remote servers such as ticketing, docs and database services. They run as independent services, scale separately, and accept per-request auth headers carrying the user's brokered token, which fits our identity model. Stdio launches the server as a local subprocess and talks over standard input and output. It works well for local utilities such as a formatter or log parser that need no shared backend and no user credentials. Its downsides are process startup cost, being tied to the agent host, and having no natural per-user auth boundary. In production I'd keep anything that touches user-scoped data on streamable HTTP. I'd limit stdio to tools that are harmless, local and read-only.

Sourced from Docs by LangChain (MCP)

I test in layers. Unit tests cover the token broker scoping, allowlist filtering, prefixing, and the wrap_tool_call error mapping, using fake MCP servers. A policy test asserts that every write tool is in interrupt_on and that no tool runs without a user token. Integration tests run the full create_agent loop against stub servers. They cover approve, edit and reject paths, resume after restart, expired tokens on resume, and a server that is down. Security tests include prompt-injection fixtures inside tickets and docs, and cross-user thread access attempts. Behaviour evals use a set of realistic requests scored on tool choice, answer accuracy and source correctness, and are rerun whenever models, prompts or tool descriptions change. Finally, a shadow or read-only pilot builds confidence before writes are enabled.

Sourced from Docs by LangChain (MCP)

create_agent already provides the model-tool loop on LangGraph, with a checkpointer, structured output and middleware. Our needs are retries, error mapping, call limits, HITL on writes and PII handling, and all of these fit middleware hooks. Building a custom graph would mean rebuilding that loop and its interrupt handling for little gain. I'd move to a custom LangGraph graph only if we needed fixed, deterministic steps, such as a mandatory triage step, or parallel branches the loop can't express. create_deep_agent adds a filesystem, subagents, summarisation and prompt caching for long, multi-step tasks such as large investigations. Ops chat requests are mostly short, so that extra machinery isn't justified yet, though it could suit a future incident-analysis mode.

Sourced from Docs by LangChain (MCP)

I'd trace every run end to end, including model calls, tool calls, middleware decisions and latency per step, tagged with thread_id and a pseudonymous user ID. Key metrics: requests and errors by type, tool error rates per MCP server, retry counts, model-call-limit hits, fallback model usage, token usage and cost per request, and broker exchange latency and failures. For approvals, I'd track interrupts raised, approve/edit/reject ratios and time to decision. A high edit or reject rate shows the agent is proposing poor writes. I'd also track PII redaction counts and degraded-mode events when a server is down. Alerts go on auth failures, spikes in reject rate and unusual bulk-write proposals, which can signal injection.

Sourced from Docs by LangChain (MCP)

Large tool lists make every model call bigger, raise cost and latency, and make the model worse at choosing the right tool, especially when descriptions overlap. First I'd prune with the allowlist and per-group tool sets, so a user only gets tools relevant to their role. Next I'd improve names and descriptions. If the list is still large, LLM tool selector middleware can use a model to pick a relevant subset of tools for each request before the main call. That adds a model call, so it's worth it only beyond a certain tool count. Another option is splitting by domain into subagents. I'd measure tool-choice accuracy in evals to decide.

Sourced from Docs by LangChain (MCP)

The system prompt explains what each server is for: ticketing for incident and change tickets, docs for runbooks and policies, the database for operational state. It also covers when to prefer each one, citing sources, asking for clarification before writes, and treating tool output as data rather than instructions. It shapes behaviour and improves tool selection. However, a model can be confused or manipulated, so the prompt cannot enforce anything. Enforcement lives in deterministic layers: brokered user-scoped tokens, the allowlist, HITL interrupts on writes, read-only database roles, thread ownership checks and call limits. If the prompt is ignored, the worst outcome should be a poor answer or a rejected approval, never an unauthorised action.

Sourced from Docs by LangChain (MCP)

I'd treat it as a change to the security boundary. First I'd confirm the server supports per-user auth, so the broker can mint scoped tokens for it, and I'd review every tool it exposes. Each tool is classified as read or write. Only the needed ones go on the allowlist with a server prefix, and every write is added to interrupt_on, with the policy test enforcing this. I'd write clear descriptions and update the system prompt on when to use it. Then I'd add error mapping for its auth and validation errors, health checks and a circuit breaker. Finally I'd run evals and injection tests against it and roll it out to a pilot group before everyone.

Sourced from Docs by LangChain (MCP)

Possibly, for small, safe things like a user's preferred team, default ticket project or output style. LangGraph stores hold JSON documents by namespace and key, with optional semantic search. I'd namespace strictly by user ID so memories never cross users, and I'd never store credentials or raw tool output, which may include data fetched under that user's permissions. The risks are stale facts, privacy obligations around retaining personal data, and memory poisoning, where injected text causes a harmful 'preference' to be saved. So writes to memory should be explicit and limited to a schema, and users should be able to view and delete them. Short-term context stays in the thread checkpointer.

Sourced from Docs by LangChain (MCP)

1. AA checkpointer, with the resume sent on the same thread_idCorrect answer
2. BA model fallback list
3. CPIIMiddleware in block mode
4. DA vector store

Why: Interrupts depend on saved graph state, so a checkpointer is needed and the resume must target the same thread.

Sourced from Docs by LangChain (MCP)

1. ATo encrypt the checkpointer database
2. BTo cache LLM responses
3. CTo swap the user's identity for short-lived, narrowly scoped per-server tokensCorrect answer
4. DTo share one service-account token across all users

Why: The broker makes tools act as the requesting user with minimal scope, so no tool runs with broader credentials.

Sourced from Docs by LangChain (MCP)

1. ASummarizationMiddleware
2. BMultiServerMCPClient from the MCP adaptersCorrect answer
3. CA LangGraph store
4. Dinit_chat_model

Why: The MCP adapters' MultiServerMCPClient connects to multiple servers and its get_tools() returns LangChain-compatible tools for create_agent.

Sourced from Docs by LangChain (MCP)

1. AModel fallback middleware
2. BHumanInTheLoopMiddleware with interrupt_on for that tool, plus a checkpointerCorrect answer
3. Cresponse_format with a schema
4. DPIIMiddleware with block strategy

Why: HumanInTheLoopMiddleware interrupts on configured tools with approve/edit/reject decisions, and a checkpointer is needed to persist state and resume the run.

Sourced from Docs by LangChain (MCP)

1. ABy passing server URLs directly to init_chat_model
2. BBy importing tools from langgraph.prebuilt
3. CBy awaiting client.get_tools()Correct answer
4. DBy calling create_agent(mcp=True)

Why: MultiServerMCPClient exposes an async get_tools() that returns the servers' MCP tools as LangChain tools.

Sourced from Docs by LangChain (MCP)

1. AApprove, summarise or cache
2. BApprove, edit or rejectCorrect answer
3. CApprove or retry only
4. DRetry, skip or escalate

Why: interrupt_on configures allowed decisions per tool from approve, edit and reject.

Sourced from Docs by LangChain (MCP)

1. ARace condition
2. BConfused deputyCorrect answer
3. CCache stampede
4. DSplit brain

Why: A privileged intermediary tricked into misusing its authority on behalf of a less-privileged party is a confused deputy.

Sourced from Docs by LangChain (MCP)

1. ARetries are not supported for MCP tools
2. BA timeout leaves the outcome unknown, so a retry can create duplicate ticketsCorrect answer
3. CRetries disable HITL middleware
4. DWrites never fail transiently

Why: Non-idempotent writes may already have succeeded, so retries need idempotency keys or should not happen at all.

Sourced from Docs by LangChain (MCP)

1. ABy storing the answer in a LangGraph store
2. BBy enabling SummarizationMiddleware
3. CBy parsing free text with regex
4. DBy passing a schema as response_format to create_agentCorrect answer

Why: response_format gives structured output validated against the provided schema.

Sourced from Docs by LangChain (MCP)

1. AIn the checkpointer, scoped by thread_idCorrect answer
2. BIn the MCP server sessions
3. CIn the system prompt
4. DIn a LangGraph store namespaced by user

Why: Short-term memory is thread-scoped state saved by the checkpointer.

Sourced from Docs by LangChain (MCP)

1. AInside the LLM's sampling parameters
2. BIn the audit log
3. COnly in the system prompt
4. DAfter get_tools(), before the tools are passed to create_agentCorrect answer

Why: Filtering loaded tools before building the agent means disallowed tools never reach the model.

Sourced from Docs by LangChain (MCP)

1. AIt hides errors from the audit log
2. BThe model can read the error and correct inputs, ask the user or stopCorrect answer
3. CIt automatically grants missing permissions
4. DIt disables the model call limit

Why: Returning a readable ToolMessage keeps the loop alive and lets the model reason about the failure.

Sourced from Docs by LangChain (MCP)

1. AA system prompt saying 'never write'
2. BA read-only database role tied to the user's brokered credentialsCorrect answer
3. CA low model temperature
4. DSummarising the query results

Why: Credential-level enforcement holds even if the model is manipulated. Prompts do not.

Sourced from Docs by LangChain (MCP)

1. ACreate a copy of the thread for the user
2. BResume it because thread IDs are random
3. CReject it after an ownership check against thread metadataCorrect answer
4. DResume it but hide tool outputs

Why: A thread_id is not authorisation. Every load or resume must verify that the caller owns the thread or is the authorised approver.

Sourced from Docs by LangChain (MCP)

1. AUse the approver's tokens instead
2. BStore long-lived tokens in the checkpoint to avoid this
3. CRe-validate, mint fresh requester tokens, rebuild the client, then resume the same threadCorrect answer
4. DSkip the tool and report success

Why: Credentials are not stored in graph state. They are re-issued at resume, and revoked access correctly blocks the write.

Sourced from Docs by LangChain (MCP)

1. ALimit impact: HITL on writes, user-scoped tokens, allowlists and call limitsCorrect answer
2. BIncrease model size
3. CDisable the audit log to reduce exposure
4. DTrust tool outputs from internal systems

Why: Injection cannot be reliably prevented by the model, so deterministic controls must cap what an injected instruction can do.

Sourced from Docs by LangChain (MCP)

1. Abefore_model
2. Bafter_model
3. Cwrap_model_call
4. Dwrap_tool_callCorrect answer

Why: wrap_tool_call wraps each tool execution, so it can catch exceptions and return an error ToolMessage instead of crashing the loop.

Sourced from Docs by LangChain (MCP)

1. Astreamable_httpCorrect answer
2. BA local pipe to the model process
3. CLoading the server code as a Python import
4. Dstdio

Why: Streamable HTTP connects to remote services and can carry request headers such as a user-scoped bearer token.

Sourced from Docs by LangChain (MCP)

1. ARunaway model-tool loops that waste cost and load systemsCorrect answer
2. BTool name collisions
3. CToken expiry
4. DPII leakage

Why: Capping model calls per run or thread stops loops caused by failing tools, bad plans or injected instructions.

Sourced from Docs by LangChain (MCP)

1. Acreate_agent("provider:model").model()
2. BChatModel.load(provider, model, mcp=True)
3. Cget_tools("provider:model")
4. Dinit_chat_model("provider:model")Correct answer

Why: init_chat_model accepts a provider:model string to build the chat model.

Sourced from Docs by LangChain (MCP)

1. ARetry, fallback or skip
2. BApprove, edit or reject
3. CRedact, mask or blockCorrect answer
4. DEncrypt, sign or hash only

Why: PIIMiddleware can redact, mask or block configured PII types.

Sourced from Docs by LangChain (MCP)

1. ASummarise when history reaches about 4000 tokens and keep the last 20 messages intactCorrect answer
2. BBlock requests over 4000 tokens and delete 20 messages
3. CRetry 20 times after 4000 tokens
4. DLimit tool outputs to 20 tokens

Why: The trigger sets when summarisation happens, and keep sets how much recent context stays unsummarised.

Sourced from Docs by LangChain (MCP)

1. AA session kept open for the process lifetime
2. BOne global session shared by all users
3. CA fresh session per tool invocation (stateless)Correct answer
4. DOne session per model provider

Why: The client is stateless by default. Explicit sessions are opened only when persistent state is needed.

Sourced from Docs by LangChain (MCP)

1. ATo bypass the allowlist
2. BMCP requires prefixes
3. CTo avoid name clashes so policy, interrupts and audits map to exactly one toolCorrect answer
4. DTo make tools run faster

Why: Unique names prevent shadowing and misrouting, and let configuration target the right server's tool.

Sourced from Docs by LangChain (MCP)

1. ATries alternative models in order when the primary model call failsCorrect answer
2. BSwitches MCP transport to stdio
3. CFalls back to a shared service account
4. DRetries failed tool calls

Why: Fallback middleware moves through a configured list of models when calls fail.

Sourced from Docs by LangChain (MCP)

1. Awrap_tool_call
2. Bwrap_model_callCorrect answer
3. Cget_tools
4. Dresponse_format

Why: wrap_model_call wraps model invocation, while wrap_tool_call wraps tool execution.

Sourced from Docs by LangChain (MCP)

1. AIt is slower than calling the model
2. BIt cannot store messages
3. CState is lost on restart and not shared across instances, breaking resumes and pending approvalsCorrect answer
4. DIt disables structured output

Why: Horizontally scaled, stateless API instances need a durable, shared checkpointer.

Sourced from Docs by LangChain (MCP)

1. AUser, thread_id, tool, redacted argument summary, outcome, approver and decisionCorrect answer
2. BOnly the final chat answer
3. CThe model's sampling temperature
4. DRaw access tokens and full tool output

Why: The audit log must show who did what and who approved it, without storing secrets or excess sensitive data.

Sourced from Docs by LangChain (MCP)

1. AThe requester's scoped token, after the edited arguments are re-validatedCorrect answer
2. BNo credentials, since it is approved
3. CThe approver's credentials
4. DA shared admin service account

Why: Approval adds a human check but must not escalate privileges, so the call still runs as the requester.

Sourced from Docs by LangChain (MCP)

1. AThe token broker cache
2. BThe checkpointer
3. CA LangGraph store with JSON documents by namespace and keyCorrect answer
4. DHumanInTheLoopMiddleware

Why: Long-term memory uses LangGraph stores organised by namespace and key, with optional semantic search.

Sourced from Docs by LangChain (MCP)

1. AUsing a model to pick a relevant subset of many tools before the main callCorrect answer
2. BApproving writes
3. CSummarising old messages
4. DEncrypting tool arguments

Why: With large tool sets, selecting a subset reduces prompt size and improves tool choice.

Sourced from Docs by LangChain (MCP)

1. AHuman approvals for every model call
2. BFilesystem, summarisation, subagents and prompt caching for long tasksCorrect answer
3. CMCP servers and token brokering
4. DA vector database and embeddings only

Why: Deep Agents bundles filesystem, summarisation, subagents and prompt caching for long-running work.

Sourced from Docs by LangChain (MCP)

1. ASwitching to stdio transport
2. BRaising the model call limit
3. CIncreasing retry count
4. DIdempotency keys plus a pending audit record and reconciliationCorrect answer

Why: You cannot commit atomically across systems, so deduplication and reconciliation handle ambiguous writes.

Sourced from Docs by LangChain (MCP)