Get bounded ontology-binding context

When to use

Use extension__ontology__get_binding_context to give an agent the relevant logical definitions and governed physical mappings from one exact binding release. Use the stable ontology_binding_... artifact ID with an exact Atlan rel_... release ID. The result keeps the binding’s original ontology release pin visible for audit and includes physical source, relation, field, transformation, and governed-join declarations relevant to the query. You may pass a newer ontology_release_id for the same ontology. Reuse succeeds only when every logical resource referenced by the binding has the same exact version and content hash. An incompatible release is refused with source_unavailable instead of silently reusing stale mappings, as is a release older than the one the binding is pinned to. The REST route POST /ontology/v1/bindings/context-queries also accepts logical_resource_ids; the MCP tool does not declare it. Pass it there to check declaration coverage for exact logical resources, even when the query text would not select them. Each ID must name a logical resource in the selected release, and the list holds at most 50 IDs; anything else fails with logical_model_invalid. The report covers the resources the query selected plus the ones you name; when that scope exceeds max_resources, it marks the context as truncated. The response includes a handoff report on the selected logical resources. Its blockers list missing mapping declarations, each with the artifact ID, the property API name where relevant, and a remediation:

Code	Means	Remediation
`object_unmapped`	The object has no object binding in this binding family.	Declare an object binding.
`property_unmapped`	The property has no field or versioned transformation mapping.	Declare a field or versioned transformation mapping.
`join_missing`	The link has no governed link binding or join keys.	Declare a governed link binding and its join keys.

The report never claims that warehouse execution is safe: source_verification is declarative_unverified — physical assets were not inspected in a warehouse — and is_execution_verified is false. It marks when a bound omitted coverage detail, and it carries the authority boundary an agent must preserve: logical meaning comes from the exact Ontology release, physical realization from the exact Binding release, documents support an explanation without overriding the logical contract, and conflicting release pins block composition. The response reserves room at the end of the max_tokens budget for this report: resource detail rows stop before the report’s verification boundary, and when the report itself does not fit, its detail rows are dropped first. Physical identities are declarations. The tool does not connect to a source, verify that a table or column exists, read business data, generate SQL, or run a query.

Inputs

In search mode, the default, run this tool through mcp__call_read_tool, the runner its run_with names: send the inputs below as its arguments, and put session_id and rationale beside them, not inside. In full mode, open a session with mcp__initialise first and pass its session_id. The authenticated mcp__describe_tools result in search mode, or tools/list response in full mode, is the final check for the tool name and schema available to your account.

Input	Type	Required	Meaning
`binding_id`	string	Yes	Ontology-binding artifact handle.
`release_id`	string	Yes	Exact `rel_…` release ID.
`ontology_release_id`	string	No	Optional newer Atlan ontology release handle. Reuse succeeds only when every logical resource referenced by the binding retains its exact version and content hash.
`query`	string	Yes	Maximum length: 4,096.
`max_resources`	integer	No	Range: 1–50.
`max_tokens`	integer	No	Range: 128–32,000.
`max_depth`	integer	No	Bounded logical-link hops from lexical matches; defaults to one. Range: 0–3.
`diagnostics`	boolean	No	Include retrieval diagnostics.
`session_id`	string	Yes	The session ID returned by `mcp__initialise`. Replace the example value with your own. In search mode, send the `session_id` from `mcp__search_tools` beside `arguments` instead.
`rationale`	string	Yes	Why this call advances the user’s task. In search mode, send it beside `arguments` instead.

Example

The example shows the tool’s arguments in full mode. In search mode, send them, without session_id and rationale, as arguments to mcp__call_tool, with session_id and rationale beside them. Replace the object, release, and session IDs with values you can access.

{
  "binding_id": "ontology_binding_01example",
  "release_id": "rel_01example",
  "query": "customer orders",
  "max_resources": 15,
  "max_depth": 1,
  "max_tokens": 12000,
  "session_id": "mcp_session_<your-session-id>",
  "rationale": "I need this released context to answer the user’s question accurately."
}

Permissions and result

This tool is read-only and uses your authenticated identity and workspace permissions. Check the returned release and digest where present, and inspect truncated on bounded retrieval results before relying on completeness. See Use Ontology with agents for the full workflow and MCP Gateway errors for connection and permission failures.

Get started

Tool references

Get bounded ontology-binding context

When to use

Inputs

Example

Permissions and result