Julep capability denials: grant the tool or remove the call

The fix: grant it in deploy(..., tools=[...] / reasoners=[...]), or in the capability manifest for kernel flows, or remove the call. Two subtleties: a missing grant section means unconstrained, but a present-but-empty section means deny-all. And native tools use the tool name while MCP tools use server/tool form. Healthy means no CAP_TOOL_DENIED, CAP_MODEL_DENIED, CAP_SERVER_DENIED, or CAP_MEMORY_DENIED. Related gate: a tool declared effect="dangerous" (or approval-required) must sit behind human_gate(...). Strict deploy refuses any ungated path to it. That is by design, not a bug. Put the gate immediately before the effect: draft -> human_gate -> send. A gate in a sibling par branch or child sub(...) does not dominate the parent path, and putting dangerous or approval-required tools directly in app(tools=[...]) reports CAP_APP_APPROVAL_TOOL. Race family: race(...), hedge(...), and quorum(...) cancel loser branches, so every branch call must be read-only or asserted native/required idempotent (MCP hints alone are untrusted). RACE_UNASSERTED means a branch call has no idempotency assertion; add idempotency: native or required to the tool grant. RACE_UNSAFE means a branch call is write-effect; remove it from the race or change the effect. RACE_SUB means a sub-flow contains unsafe calls; fix the sub-flow or remove it from the race.

Context: Official docs (Julep capabilities and safety guide): a tool the flow was not granted is denied, not routed somewhere surprising. You get a CAP_TOOL_DENIED diagnostic with a fix line pointing at the call site, for example error: tool 'srv/denied' is not granted, with fix: add this tool to the capability manifest tools allow-list, or remove the call.