Skip to main content
We welcome contributions to LangChain documentation, including new features, integrations, and improvements to existing docs.

​
Quick start - local development

To run a local preview of the documentation: 
git clone https://github.com/langchain-ai/docs.git

cd docs

make install

make dev
This starts a development server with hot reload at http://localhost:3000. Edit files in src/ and see changes immediately.
Required:Optional:

​
Edit documentation

For typos or small changes, edit directly on GitHub without local setup:
  1. Click Edit this page on GitHub at the bottom of any page.
  2. Fork to your personal account.
  3. Make changes in GitHub’s web editor.
  4. Create a pull request.
Only edit files in src/— The build/ directory is automatically generated.
  1. Edit files in src/ following our writing standards.
  2. Run quality checks before submitting.
  3. Create a pull request for review.
When you create or update a PR, a preview branch/ID is automatically generated. A comment will be left on the PR with the ID.
  1. Copy the preview branch’s ID from the comment
  2. In the Mintlify dashboard, click Create preview deployment
  3. Enter the preview branch’s ID and click Create deployment
  4. Select the preview and click Visit to view
To redeploy with latest changes, click Redeploy on the dashboard.

​
Run quality checks

Before submitting changes, ensure your code passes formatting and linting checks: 
# Check broken links
make mint-broken-links

# Format code automatically
make format

# Check for linting issues
make lint

# Fix markdown issues
make lint_md_fix

# Run tests to ensure your changes don't break existing functionality
make test
For more details, see the available commands section in the README.

​
Documentation types

All documentation falls under one of four categories:

How-to guides

Task-oriented instructions for users who know what they want to accomplish.

Conceptual guides

Explanations that provide deeper understanding and insights.

Reference

Technical descriptions of APIs and implementation details.

Tutorials

Lessons that guide users through practical activities to build understanding.
Where applicable, all documentation must have both Python and JavaScript/TypeScript content. For more details, see the co-locate Python and JavaScript/TypeScript content section.

​
How-to guides

How-to guides are task-oriented instructions for users who know what they want to accomplish. Examples of how-to guides are on the LangChain and LangGraph tabs.
  • Task-focused: Focus on a specific task or problem
  • Step-by-step: Break down the task into smaller steps
  • Hands-on: Provide concrete examples and code snippets
  • Focus on the how rather than the why
  • Use concrete examples and code snippets
  • Break down the task into smaller steps
  • Link to related conceptual guides and references

​
Conceptual guides

Conceptual guide cover core concepts abstractly, providing deep understanding.
  • Understanding-focused: Explain why things work as they do
  • Broad perspective: Higher and wider view than other types
  • Design-oriented: Explain decisions and trade-offs
  • Context-rich: Use analogies and comparisons
  • Focus on the “why” rather than the “how”
  • Provides supplementary information not necessarily required for feature usage
  • Can use analogies and reference alternatives
  • Avoid blending in too much reference content
  • Link to related tutorials and how-to guides

​
Reference

Reference documentation contains detailed, low-level information describing exactly what functionality exists and how to use it.

Python reference

JavaScript/TypeScript reference

A good reference should:
  • Describe what exists (all parameters, options, return values)
  • Be comprehensive and structured for easy lookup
  • Serve as the authoritative source for technical details
See the contributing guide for Python reference docs.
  • Be consistent; follow existing patterns for provider-specific documentation
  • Include both basic usage (code snippets) and common edge cases/failure modes
  • Note when features require specific versions
  • New integrations or providers need dedicated reference pages
  • Complex configuration options require detailed explanation
  • API changes introduce new parameters or behavior
  • Community frequently asks questions about specific functionality

​
Tutorials

Tutorials are longer form step-by-step guides that builds upon itself and takes users through a specific practical activity to build understanding. Tutorials are typically found on the Learn tab.
We generally do not merge new tutorials from outside contributors without an acute need. If you feel that a certain topic is missing from docs or is not sufficiently covered, please open a new issue.
  • Practical: Focus on practical activities to build understanding.
  • Step-by-step: Break down the activity into smaller steps.
  • Hands-on: Provide sequential, working code snippets.
  • Supplementary: Provide additional context and information not necessarily required for feature usage.
  • Code snippets should be sequential and working if the user follows the steps in order.
  • Provide some context for the activity, but link to related conceptual guides and references for more detailed information.

​
Writing standards

Reference documentation has different standards - see the reference docs contributing guide for details.

​
Mintlify components

Use Mintlify components to enhance readability:
  • <Note> for helpful supplementary information
  • <Warning> for important cautions and breaking changes
  • <Tip> for best practices and advice
  • <Info> for neutral contextual information
  • <Check> for success confirmations

​
Page structure

Every documentation page must begin with YAML frontmatter: 
---
title: "Clear, specific title"
sidebarTitle: "Short title for the sidebar (optional)"
---

​
Co-locate Python and JavaScript/TypeScript content

All documentation must be written in both Python and JavaScript/TypeScript when possible. To do so, we use a custom in-line syntax to differentiate between sections that should appear in one or both languages: 
:::python
Python-specific content. In real docs, the preceding backslash (before `python`) is omitted.
:::

:::js
JavaScript/TypeScript-specific content. In real docs, the preceding backslash (before `js`) is omitted.
:::

Content for both languages (not wrapped)
This will generate two outputs (one for each language) at /oss/python/concepts/foo.mdx and /oss/javascript/concepts/foo.mdx. Each outputted page will need to be added to the /src/docs.json file to be included in the navigation.
We don’t want a lack of parity to block contributions. If a feature is only available in one language, it’s okay to have documentation only in that language until the other language catches up. In such cases, please include a note indicating that the feature is not yet available in the other language.If you need help translating content between Python and JavaScript/TypeScript, please ask in the community slack or tag a maintainer in your PR.

​
Quality standards

​
General guidelines

Multiple pages covering the same material are difficult to maintain and cause confusion. There should be only one canonical page for each concept or feature. Link to other guides instead of re-explaining.
Take a less-is-more approach. If another section with a good explanation exists, link to it rather than re-explain, unless your content presents a new angle.

​
Accessibility requirements

Ensure documentation is accessible to all users:
  • Structure content for easy scanning with headers and lists
  • Use specific, actionable link text instead of “click here”
  • Include descriptive alt text for all images and diagrams

​
Cross-referencing

Use consistent cross-references to connect docs with API reference documentation. From docs to API reference: Use the @[] syntax to link to API reference pages: 
See @[`ChatAnthropic`] for all configuration options.

The @[`bind_tools`][ChatAnthropic.bind_tools] method accepts...
The build pipeline transforms these into proper markdown links based on the current language scope (Python or JavaScript). For example, @[ChatAnthropic] becomes a link to the Python or JS API reference page depending on which version of the docs is being built, but only if an entry exists in the link_map.py file! See below for details.
From API reference stubs to OSS docs: See the README for more information on linking from API reference stubs to Python OSS docs. Specifically see the mkdocstrings cross-reference linking syntax.

​
Get help

Our goal is to have the simplest developer setup possible. Should you experience any difficulty getting setup, please ask in the community slack or open a forum post. Internal team members can reach out in the #documentation Slack channel.
Edit this page on GitHub or file an issue.
Connect these docs to Claude, VSCode, and more via MCP for real-time answers.