Agent tool-use patterns

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

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} (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) 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.