langsmith-fetch
by ComposioHQlangsmith-fetch is a debugging skill for LangChain and LangGraph agents. It guides assistants to install the CLI, set LangSmith credentials, fetch recent traces, and analyze errors, tool calls, memory activity, latency, and token usage with trace evidence.
This skill scores 78/100, which makes it a solid listing candidate for directory users who already use LangSmith with LangChain or LangGraph. It provides clear activation cues, setup steps, and practical trace-debugging workflows, but adoption depends on an external CLI and the repository evidence is limited to one documentation-only skill file.
- Strong triggerability: the frontmatter and “When to Use” section map common debugging requests to LangSmith trace-fetching use cases such as errors, tool calls, memory operations, and token usage.
- Operationally useful: includes prerequisite setup with `pip install langsmith-fetch`, required environment variables, verification commands, and concrete CLI invocations such as fetching recent traces.
- Good agent leverage for LangChain/LangGraph debugging: the workflows tell the agent what to execute and what to report back, reducing guesswork compared with a generic debugging prompt.
- Requires the external `langsmith-fetch` CLI plus `LANGSMITH_API_KEY` and `LANGSMITH_PROJECT`; the skill itself provides no bundled scripts or support files.
- Repository evidence shows only a single `SKILL.md`, so users must trust the documented CLI commands rather than inspect implementation, examples, or tests in this skill folder.
Overview of langsmith-fetch skill
What langsmith-fetch does
langsmith-fetch is a debugging skill for LangChain and LangGraph applications that need trace-level investigation from LangSmith Studio. Instead of asking an assistant to guess why an agent failed, the skill guides it to fetch recent LangSmith traces with the langsmith-fetch CLI, inspect runs, errors, tool calls, memory activity, timing, and token usage, then summarize what likely happened.
Best fit for LangChain and LangGraph debugging
The langsmith-fetch skill is most useful when you already run agents with LangSmith tracing enabled and want faster diagnosis during development or incident review. It fits questions like “why did this agent fail?”, “what tools were called?”, “why is latency high?”, “did memory update correctly?”, or “what happened in the last few minutes?”
It is less useful if your app is not sending traces to LangSmith, if you do not have access to the relevant project, or if you need code-level profiling outside the trace data.
Main differentiator: evidence-first agent analysis
A normal prompt can describe likely causes, but langsmith-fetch pushes the assistant toward observable evidence: recent traces, run statuses, execution flow, tool invocations, errors, timings, and token usage. This makes the output more actionable for debugging agent behavior, especially when failures depend on runtime state rather than static code.
How to Use langsmith-fetch skill
langsmith-fetch install and setup
Install the CLI before relying on the skill:
pip install langsmith-fetch
Set the LangSmith credentials and project the CLI should query:
export LANGSMITH_API_KEY="your_langsmith_api_key"
export LANGSMITH_PROJECT="your_project_name"
Verify that both are available in the shell where your assistant or terminal command will run:
echo $LANGSMITH_API_KEY
echo $LANGSMITH_PROJECT
If these variables are missing or point to the wrong project, the skill may produce empty or misleading debugging results.
Inputs the skill needs from you
For best results, give the assistant a debugging target, a time window, and the symptom. A weak prompt is: “debug my agent.” A stronger prompt is:
Use langsmith-fetch to inspect the last 15 minutes of traces in my LangSmith project. Focus on failed LangGraph runs, tool call errors, memory writes, latency spikes, and token usage. Summarize the likely root cause and list the trace evidence you used.
Useful details include:
- approximate failure time or “last N minutes”
- agent, graph, chain, or endpoint name
- expected behavior versus actual behavior
- whether to prioritize errors, tools, memory, performance, or cost
- any user input or run ID related to the incident
Practical langsmith-fetch usage workflow
A common first command is:
langsmith-fetch traces --last-n-minutes 5 --limit 5 --format pretty
Use this for quick triage after a recent failure. Ask the assistant to report:
- how many traces were found
- which traces failed or looked abnormal
- tool calls and their inputs/outputs when relevant
- memory or state operations if your agent uses them
- latency and token usage patterns
- a concise root-cause hypothesis with evidence
For deeper debugging, widen the time window or increase the limit. For noisy projects, narrow the query by project context, time range, run name, or the specific failure symptom.
Repository file to read first
The upstream skill is concentrated in SKILL.md; there are no major companion scripts/, resources/, or references/ folders in the repository preview. Read SKILL.md first to understand the intended trigger phrases, prerequisites, and workflow patterns. The important adoption check is not repository complexity; it is whether your LangSmith environment and CLI access are already configured.
langsmith-fetch skill FAQ
Is langsmith-fetch only for LangGraph?
No. The skill is written for both LangChain and LangGraph agent debugging. It is especially helpful for graph-style execution because traces can reveal node flow, tool calls, state transitions, and where a run diverged from expectations.
How is this better than asking an AI to debug from logs?
The langsmith-fetch skill is better when the issue is visible in LangSmith traces. It gives the assistant a concrete workflow for fetching execution data instead of relying on pasted logs or speculation. You still need to review the result critically, but the analysis starts from observed runs rather than generic debugging advice.
Do beginners need LangSmith knowledge to use it?
Beginners can use the skill if someone has already enabled LangSmith tracing and provided the right LANGSMITH_API_KEY and LANGSMITH_PROJECT. Without that setup, the main blocker is not prompt writing; it is environment access. Basic familiarity with traces, runs, tool calls, and projects will make the output easier to interpret.
When should I not use langsmith-fetch?
Do not use it for applications that are not traced in LangSmith, for debugging frontend-only behavior, for database issues not represented in traces, or for private projects where the assistant environment should not access LangSmith credentials. Also avoid it when you already have a precise run ID and need manual LangSmith UI inspection with screenshots or team annotations.
How to Improve langsmith-fetch skill
Improve langsmith-fetch prompts with sharper scope
The biggest quality gain comes from narrowing the question. Instead of asking for a broad review, specify the decision you need:
Check recent traces for failed tool calls in the payment support agent. Determine whether failures come from tool input formatting, tool timeout, or model planning. Include trace IDs or run names if available.
This improves the assistant’s ability to separate symptoms from causes and prevents a generic summary of every trace.
Provide evidence targets, not just symptoms
Tell the skill what evidence matters. For reliability debugging, ask for errors, retries, exception messages, and last successful step. For performance debugging, ask for slow runs, long tool calls, model latency, and token usage. For memory debugging, ask for read/write operations, missing context, unexpected state updates, and whether later steps used the stored information.
Watch for common failure modes
Common problems include querying the wrong LangSmith project, using too short a time window, fetching too few traces, or treating one failed run as representative. If results look empty, confirm environment variables and widen the window. If results are noisy, reduce scope by agent name, time, or symptom. If the analysis sounds speculative, ask the assistant to separate “trace evidence” from “hypothesis.”
Iterate after the first output
After the initial langsmith-fetch usage, ask follow-up questions that convert trace analysis into engineering action:
- “Which code path should I inspect first?”
- “What prompt or tool schema change would prevent this?”
- “Compare failed and successful traces in the same window.”
- “List the minimal reproduction from the trace.”
- “What metric should I monitor to catch this earlier?”
This turns the skill from a trace viewer into a practical debugging loop for LangChain and LangGraph agents.