---
title: Agent tool-use patterns
description: How to sequence Dike's tools inside a multi-step agent loop.
order: 2
---

The four tools are designed to chain, not stand alone — a typical agentic legal query touches two or three of them in sequence.

```mermaid
sequenceDiagram
    participant Agent
    participant Dike

    Agent->>Dike: dike_search(query)
    Dike-->>Agent: results[] (800-char snippets)
    Note over Agent: pick the right canonical_id

    alt needs full text
        Agent->>Dike: REST GET /v1/document/{canonical_id}
        Note over Agent,Dike: not one of the four MCP tools --<br/>call it directly if your client allows arbitrary HTTP
        Dike-->>Agent: full_text
    end

    alt needs citation graph
        Agent->>Dike: dike_graph_traverse(canonical_id)
        Dike-->>Agent: nodes + edges
    end

    alt needs a verified answer
        Agent->>Dike: dike_reason(question)
        Dike-->>Agent: answer + verified citations
    end
```

## Search → Document

`dike_search` snippets are capped at 800 characters — enough to judge relevance, not enough to reason over carefully. When a result looks right, follow up with [`/v1/document/{canonical_id}`](/docs/api-reference/document) (or the MCP-side equivalent, if your client exposes it) to pull `full_text` before answering from it.

## Search → Graph Traverse

To answer "what amends this law" or "what does this ruling cite," don't try to extract that from search snippets — call `dike_graph_traverse` with the `canonical_id` you already have. It returns hydrated nodes (title/year/status), so most graph questions resolve in one call.

## Reason vs. Search + your own synthesis

`dike_reason` is the right choice when you want Dike's own hallucination-guarded synthesis, with citations pre-verified against the retrieved set. If your agent wants to do its own multi-source synthesis (e.g. combining Dike results with other tools), prefer `dike_search` + `dike_graph_traverse` and build the answer yourself — don't post-process `dike_reason`'s answer text, since its guarantees (every `[n]` is verified) only hold for the text as returned.

## Rate limits inside a loop

`dike_reason` has a much tighter per-minute limit than the other three tools (see [Rate limits & errors](/docs/getting-started/rate-limits-errors)) because it runs a full LLM generation, not just retrieval. An agent that calls `dike_reason` once per sub-question in a multi-step plan can hit that limit faster than a human would notice — prefer one `dike_reason` call per user-facing answer, with `dike_search`/`dike_graph_traverse` doing the cheaper exploratory steps in between.