What you will be able to do
- Explain why connecting every available MCP server and tool up front (a raw tool dump) inflates an agent's context
- Narrow what an agent sees by connecting fewer servers and selecting tools on an MCP Service
- Discover tools at runtime with list_tools() and load detailed instructions only when a task needs them
- Keep tool execution context-efficient with preset _meta parameters and small, aggregated results
Key concept
Progressive disclosure of MCP tools — Rather than putting every tool definition from every server into the agent's context at the start, you show the agent a small, relevant set first. More detail, such as a tool's schema or a skill's full instructions, loads only when the task calls for it, and results come back as small as the task allows.
1.Why a raw tool dump is expensive
MCP lets an agent find tools at runtime and does not wire them in at build time. That makes it easy to connect a lot of servers. Each server publishes its tools, and for every tool the agent gets a name, a description and an input schema. A "raw tool dump" is the naive way to use this: connect every server you can reach, list every tool, and give the whole catalogue to the model on every turn.
The Databricks guidance on Genie Code consumption describes the cost directly. Each connected server adds its tools to the context the agent carries, so the advice is to disable servers you are not using and turn off the ones a chat doesn't need. The same reasoning applies to any MCP client, including a custom agent you build in code. Tool definitions are input tokens, and you pay for them on every model call whether or not a tool is used. A long list also gives the model more near-duplicate choices to sort through before it acts.
Progressive disclosure is the alternative. Show a small, relevant set first, add detail only when the task needs it, and keep results lean. The rest of this lesson takes those three stages in order.
Checkpoint 1 of 6· Exam question
A context engineer is redesigning tool access for an agent that previously received full definitions for 300 MCP tools in every system prompt. To apply progressive disclosure, which staged-discovery pattern should the engineer implement?
Correct answer: A — Expose a lightweight discovery step (e.g., listing/searching tool names/summaries) and allow the agent to fetch a tool's full schema only when it deems that tool relevant.
- A. Correct. This pattern directly implements progressive disclosure by providing a cheap, initial index of tool names or summaries, drastically reducing initial context size. The full schema is retrieved only when the agent identifies a relevant tool, conserving context window tokens and aligning with staged discovery principles.
- B. Incorrect. Partitioning tools across servers and adding authentication addresses access control, not progressive disclosure. After authentication, the agent still receives all tools from a server at once, failing to reduce the initial context load or implement on-demand schema retrieval.
- C. Incorrect. Embedding schemas in model weights via fine-tuning eliminates runtime context tokens, but it is not a staged discovery mechanism. The model would not dynamically fetch tool definitions on demand; rather, it relies on static, pre-trained knowledge, missing the essential progressive disclosure pattern of runtime tool exploration.
- D. Incorrect. Compressing descriptions into abbreviations still sends all tools' identifiers at startup, effectively dumping them into the initial context. Expanding on invocation does not prevent the upfront token cost for every tool, whereas progressive disclosure requires a selective discovery step (like searching) before any full schemas are loaded.
Sources1
2.Stage 1: Narrow the tool surface before the agent sees it
The cheapest tokens are the ones that never reach the agent. On Databricks, the first lever is to connect fewer servers. The second works at the level of the MCP Service. An MCP Service is a Unity Catalog securable that wraps a Databricks-provided tool or a registered external MCP server, and it controls which of that server's tools agents can see.
The default works against you here. Unless you choose otherwise, an MCP Service makes available every tool the underlying server provides. For a large SaaS server, that could be dozens of tools when your agent needs three. Tool selection fixes this. When you create the service, or at any point later, you select tools individually or by pattern. A selector ending in * matches by prefix (for example get_*), and any other value must match exactly. After an update, the service exposes only the selected tools.
databricks api patch \
"/api/2.1/unity-catalog/mcp-services/main.default.my_mcp?update_mask=config.include_tool_selectors" \
--json '{
"config": {
"include_tool_selectors": ["get_*"]
}
}'This helps progressive disclosure because filtering happens on the server side, before discovery. A tool you don't select never shows up when the agent lists tools, so its description never costs a token. Tool selection also acts as a governance control, because the service refuses calls to tools outside the selection.
Checkpoint 2 of 6· Check yourself
An MCP Service's include_tool_selectors is set to ["get_*"]. The agent tries to call a tool named create_issue. What happens?
Tool selection does two things: it filters discovery, and it rejects calls to unselected tools. Knowing a tool's name doesn't get around it.
“Tools that you don't select don't appear in tools/list, and the MCP Service rejects a tools/call for an unselected tool”Source: docs.databricks.com
3.Stages 2 and 3: Discover at runtime, load detail on demand
Once the surface is narrow, the agent still has to learn what it can call. Databricks says plainly not to hardcode server names, tool names or argument shapes from memory. Each MCP Service exposes a different set of tools, so the reliable way to find out what a server offers is to ask it at runtime. With the databricks-mcp library, you point a DatabricksMCPClient at a server URL (managed, MCP Service or custom) and call list_tools(). That returns each tool's name, description and input schema.
mcp_client = DatabricksMCPClient(server_url=mcp_server_url, workspace_client=workspace_client)
tools = mcp_client.list_tools()
print(f"Available tools: {[t.name for t in tools]}")Discovery doesn't have to return everything at the same depth, either. The Databricks skill registry MCP server shows the staged pattern clearly. It doesn't load every piece of guidance into context. Instead, it exposes small tools that reveal a little more at each step. The agent lists what exists, loads one item's instructions only when the task matches it, and fetches bundled files only if it needs them. This lesson uses the registry only as an example of the shape. The goal is a cheap catalogue first and expensive detail later.
| Tool | Purpose | When it adds to context |
|---|---|---|
| list_skills | List the skills in one schema | First: a short catalogue to choose from |
| load_skill | Load a skill's instructions into the current session | Only after a task matches a skill |
| get_skill_files | Fetch specific bundled files from a skill | Only if the loaded skill needs supporting files |
Most turns use only one or two items. With staging, you pay the full cost only for what the task actually matched. Everything else costs just its short catalogue entry, or nothing if the earlier filtering removed it.
Checkpoint 3 of 6· Fill the gap
You have discovered the tool you need. Which client method runs it?
result = mcp_client. ? ("system__ai__python_exec", {"code": "print('Hello, world!')"})
print(result.content)list_tools() is for discovery. call_tool() runs one named tool with its arguments, which is the execution step after discovery.
Source: docs.databricks.comCheckpoint 4 of 6· Exam question
A team benchmarks two approaches for an agent that must occasionally use one tool from a Salesforce MCP server after already working with a Google Drive MCP server: (1) loading full definitions for both servers' tools at session start, and (2) using a search-based discovery step that only pulls the Salesforce tool's schema when needed. Approach (2) uses dramatically fewer tokens. What underlying property of progressive disclosure explains this result?
Correct answer: A — Only the schemas relevant to the current task are pulled into context, so token cost scales with actual usage, a core property of progressive disclosure that explains the result.
- A. Correct. Progressive disclosure ensures that only schemas relevant to the current task are loaded into context, meaning token cost scales with actual tool usage rather than the total catalog size. This explains why the search-based approach dramatically reduces tokens when only one Salesforce tool is needed among many from both servers.
- B. Incorrect. Indexing tool schemas into a vector database for fast retrieval is an implementation choice, not the underlying property that explains the token savings. The savings in approach (2) result from avoiding loading unused schemas into context, not from caching or eliminating reloads.
- C. Incorrect. Schema compactness is a server-specific detail and not a general property guaranteed by the MCP protocol. The token savings here are due to progressive disclosure, not because one server's schemas are smaller; the key is that unused schemas aren't loaded at all.
- D. Incorrect. OAuth handshakes handle authentication and are negligible compared to the token cost of loading large tool definitions. Approach (2) saves tokens primarily by omitting unused schemas, not by avoiding authentication overhead.
4.Context-efficient execution: lean inputs, lean outputs
Staged discovery controls what the agent learns about tools. Execution controls what passes through the context window when a tool runs, and the same discipline applies on both sides of the call.
On the input side, Databricks managed MCP servers split parameters into two kinds. Tool call arguments are what the model generates from the user's request. _meta parameters are configuration you preset in agent code, such as which SQL warehouse to use. The model doesn't need to see, reason about or generate a value that your code already fixes. Moving fixed configuration into _meta keeps it out of the model's reasoning and makes the behaviour deterministic.
On the output side, result size is the risk. Because the SQL server truncates large results, the efficient pattern is to ask for less: return fewer rows and columns, or aggregate in SQL so that a summary comes back to the model. The same principle applies at a larger scale. For a task your team repeats, a skill can bundle a script that the agent runs directly, so it doesn't plan, generate and iterate on every run.
Checkpoint 5 of 6· Match them up
Match each mechanism to its role in keeping an agent's context small
Tap a term, then the definition that fits it.
Selection narrows the surface, list_tools() handles discovery, and the two parameter kinds separate what the model has to decide from what your code fixes.
“_meta parameters: Configuration parameters that you can preset in your agent code to set behavior deterministically”Source: docs.databricks.com
Checkpoint 6 of 6· Exam question
An engineer implements a `search_tools` capability that lets the agent request just a tool's name, just its short description, or its complete input schema, depending on what the agent needs at that moment. What progressive-disclosure benefit does this granular detail-level control add beyond basic staged discovery?
Correct answer: A — It lets the agent spend the fewest tokens needed to judge relevance first and only pay the larger cost of a full schema once it has committed to using that tool.
- A. Correct. This design lets the agent request only the minimal information (name and/or short description) to judge relevance, avoiding upfront full-schema retrieval. Full input schemas are fetched only once the agent has committed to a tool, conserving tokens during the search phase.
- B. Incorrect. Granular tool search detail does not alter the authorization model; Unity Catalog permission checks are still performed per tool invocation regardless of how much description is retrieved during discovery.
- C. Incorrect. While fetching only tool names or short descriptions helps the agent narrow down candidates, it does not guarantee correct tool selection. The agent may still misinterpret names or lack full understanding without the schema, but the approach reduces ambiguity, not eliminates it.
- D. Incorrect. Progressive disclosure only controls what information the MCP server sends about tools; all tool invocations still go through the MCP server. The agent cannot bypass the server and call underlying APIs directly based on the search results.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Connecting extra MCP servers costs nothing until one of their tools is actually called.Why is that wrong?
A connected server's tool definitions sit in the agent's context on every turn. Disconnect the servers a task doesn't need.
Covered in Why a raw tool dump is expensive
2.Registering an MCP Service automatically exposes only a minimal, safe subset of the server's tools.Why is that wrong?
By default the service exposes every tool the server provides. You must select tools, for example with include_tool_selectors, to narrow the surface.
Covered in Stage 1: Narrow the tool surface before the agent sees it
3.To save a discovery round-trip, hardcode the tool names and argument shapes you remember into the agent.Why is that wrong?
Tool sets vary by server and change over time. Discover them at runtime with tools/list or list_tools() and confirm them from the workspace.
Covered in Stages 2 and 3: Discover at runtime, load detail on demand
4.A broad SELECT * through the SQL MCP server is fine because the agent receives the full result and can filter it.Why is that wrong?
Large results are truncated to protect the context window. Return fewer rows and columns, or aggregate in SQL.
Covered in Context-efficient execution: lean inputs, lean outputs
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Each connected MCP server adds its tools to what Genie Code carries in context.”
↩︎ Why a raw tool dump is expensive“Turn off servers a chat doesn't need.”
↩︎ Why a raw tool dump is expensive“runs the script rather than planning, generating, and iterating on each run”
↩︎ Context-efficient execution: lean inputs, lean outputs“Each connected MCP server adds its tools to what Genie Code carries in context.”
↩︎ Exam trap 1 - 2.
“By default, an MCP Service makes available all of the tools the MCP server provides.”
↩︎ Stage 1: Narrow the tool surface before the agent sees it“By default, an MCP Service makes available all of the tools the MCP server provides.”
↩︎ Exam trap 2“Tools that you don't select don't appear in tools/list, and the MCP Service rejects a tools/call for an unselected tool”
↩︎ Checkpoint - 3.
“An MCP Service is a Unity Catalog securable that provides a Databricks-hosted tool or registers an external MCP server and governs how agents use it.”
↩︎ Stage 1: Narrow the tool surface before the agent sees it“Every MCP Service exposes a different set of tools, so discover them at runtime instead of hardcoding names.”
↩︎ Stages 2 and 3: Discover at runtime, load detail on demand - 4.
“call list_tools() to get each tool's name, description, and input schema at runtime”
↩︎ Stages 2 and 3: Discover at runtime, load detail on demand“Do not hardcode server names, tool names, or argument shapes from memory; confirm them from the workspace.”
↩︎ Exam trap 3 - 5.
“When a task matches a skill's description, the agent loads it on demand”
↩︎ Stages 2 and 3: Discover at runtime, load detail on demand - 6.
“Tool call arguments: Parameters that an LLM typically generates dynamically based on user input”
↩︎ Context-efficient execution: lean inputs, lean outputs“_meta parameters: Configuration parameters that you can preset in your agent code to set behavior deterministically”
↩︎ Checkpoint - 7.
“Return fewer rows and columns, or aggregate in SQL, to keep results within the limit.”
↩︎ Context-efficient execution: lean inputs, lean outputs“Return fewer rows and columns, or aggregate in SQL, to keep results within the limit.”
↩︎ Exam trap 4“The server truncates large result sets in tool responses to avoid exhausting the model's context window.”
↩︎ Prediction
Also cited
- https://docs.databricks.com/aws/en/genie-code/mcpOfficial docs
“MCP replaces manual copy-pasting with a structured, reusable approach, making the right context available only when it is needed.”
↩︎ Key concept