What you will be able to do
- Explain why every tool definition and instruction that sits in an agent's context costs tokens on every turn, not just when it is used
- Describe the stages through which a skill moves from description, to loaded instructions, to fetched supporting files, and which tool performs each stage
- Choose between a one-off load, a download, and a live schema connection based on how much tool information each puts in front of the agent
- Explain why staged loading uses fewer tokens than loading all tool and instruction content upfront
Key concept
Progressive disclosure of tool information — The agent starts out holding only a short description of each capability. It pulls in the full instructions, and after that any bundled files, only when the current task calls for them. Context the task doesn't need never enters the window, so the agent doesn't pay for it on every turn.
1.Why tools loaded upfront cost tokens on every turn
Progressive disclosure starts from a cost model, so begin there. The Genie consumption guide describes how an agentic assistant uses tokens: each turn re-sends the whole chat's context to the model, and one agentic task runs several turns to plan, act, and check its work. The guide's conclusion is that consumption grows with the length of a chat and with the amount of context it carries.
The question 'how much tool information is in the context?' matters because of that cost model. The same guide says that each connected MCP server adds its tools to the context the assistant carries. A tool the agent never calls still sits in the context, and because the context is re-sent every turn, it is paid for on every turn. Standing instructions work the same way. The guide warns that instructions load with every message and should be kept lean.
Too much tool information also hurts quality, not just cost. Databricks' AI harness article names 'tool overload' as a common harness failure: giving the model too many tools at once makes it more confused and slows its decisions before any work begins. The guide's practical fix is direct: disable MCP servers you aren't using, and turn off servers a chat doesn't need.
| Factor | What the guide says | Effect on tool information |
|---|---|---|
| Turns | Each turn re-sends the whole chat's context to the model | Every tool definition in context is paid for again on each turn |
| Connected MCP servers | Each connected MCP server adds its tools to what Genie Code carries in context | Unused servers add cost without adding value |
| Instructions | Instructions load with every message, so keep them lean | Content that is always loaded pays the per-turn cost in full |
| Chat length | The twentieth message in a chat costs more than the first | Any context added early is carried through every later turn |
Checkpoint 1 of 8· Check yourself
A team's agent has several MCP servers connected. Most chats need only one of them. Which change most directly reduces the tool information the agent carries in context?
A connected server's tools sit in context whether or not they are used. Disconnecting servers a chat doesn't need is what takes their tools out of the context that is re-sent each turn.
“Disable MCP servers you aren't using. Each connected MCP server adds its tools to what Genie Code carries in context.”Source: docs.databricks.com
Checkpoint 2 of 8· Exam question
A team builds an agent connected to 12 MCP servers, each exposing multiple tools with detailed JSON schemas. At the start of every conversation, the agent loads all tool definitions into context, and the team notices response latency and token cost growing rapidly even before the user's first message. Which change best embodies progressive disclosure to address this?
Correct answer: A — Load only tool names and short descriptions at first, and fetch a tool's full schema only when the agent selects it to call
- A. Correct. This is the core progressive disclosure pattern: a cheap, compact summary (name plus short description) stays in context for discovery, while the expensive full schema is deferred and only added to context on the turn a tool is actually chosen. This bounds token cost to the tools actually used instead of every tool the agent could theoretically call.
- B. Incorrect. Compressing the schemas' encoding does not remove them from context or defer when they load; all 12 servers' tool definitions are still present upfront, so the token savings from staged loading are not realized, even if raw character count shrinks slightly.
- C. Incorrect. Enlarging the context window accommodates more tokens but does not reduce how many are consumed; it treats the symptom (truncation) rather than the cause (loading unnecessary schema detail every turn), and cost/latency from a bloated context still remain.
- D. Incorrect. Retrieving only the single most similar tool on every call risks excluding the correct tool if similarity search misranks it, and it does not describe a staged 'summary then full detail' disclosure pattern -- it replaces broad access with a lossy single-result filter instead.
- E. Incorrect. Embedding all schemas permanently in the system prompt guarantees they are resent on every turn regardless of relevance, which is the opposite of deferring detail until it is needed and does not reduce token consumption at all.
2.The stages: description, instructions, then files
If carrying everything is expensive, the alternative is to carry a small amount at first and fetch the rest when it is needed. The Databricks sources show this staging most clearly in Agent Skills.
Stage 1: description only. A skill is a Markdown file whose front-matter metadata says when and how the skill should be used. AI coding assistants discover and load relevant skills based on the task at hand. Until a task matches, the description is the only part the agent needs.
Stage 2: instructions on demand. When a request matches a skill, the agent loads that skill's instructions. In the Unity Gateway Skills tutorial, this is an explicit tool call. The agent calls load_skill to bring the skill's instructions into context.
Stage 3: supporting files only if needed. A skill can bundle scripts, examples, and other resources. These aren't pulled in with the instructions. The agent calls get_skill_files to fetch specific bundled files, and only when the skill has supporting files.
Before any of these stages there is a discovery step. The agent can call list_skills to report what a schema holds without loading any individual skill.
| Tool | Purpose | What enters context |
|---|---|---|
| list_skills | List the skills in one schema | A listing of what is available, not any skill's instructions |
| load_skill | Load a skill's instructions into the current session | The full instructions of one chosen skill |
| get_skill_files | Fetch specific bundled files from a skill | Only the specific bundled files requested |
Checkpoint 3 of 8· Put it in order
An agent connected to the skill registry is asked to use a published skill it has not seen before. Put its tool calls in the order that keeps context smallest at each step.
- 1.Call list_skills to see what the schema holds
- 2.Call get_skill_files to fetch specific bundled files, only if the skill has them
- 3.Call load_skill to bring the chosen skill's instructions into context
Listing shows what is available without loading any skill. Loading brings in one skill's instructions. Fetching files is a separate, later step that runs only when the skill bundles supporting files.
“The agent calls the load_skill MCP tool to load the skill's instructions into context, and get_skill_files if the skill bundles supporting files.”Source: docs.databricks.com
Checkpoint 4 of 8· Exam question
In the context of agent tool design, what is the primary token-efficiency reason for using progressive disclosure instead of loading every tool's full schema into the agent's context window upfront?
Correct answer: A — It defers full schema loading until a tool is actually needed, spending tokens only on relevant tools
- A. Correct. Progressive disclosure's efficiency gain comes from staging what enters context: a lightweight summary is available for discovery, and the token-heavy full schema is only loaded on the turn a tool is actually going to be called, so tokens are not spent describing tools that never get used.
- B. Incorrect. This describes a compression strategy, not a staging strategy -- all schemas are still loaded fully at once, just with a smaller encoding. It does not defer anything and does not scale as well as staged loading when the number of tools grows.
- C. Incorrect. Removing descriptions entirely would harm tool-selection accuracy, since the model would have no grounded, current information about a tool's parameters or behavior; progressive disclosure keeps descriptions available, just staged rather than deferred to inference.
- D. Incorrect. The agent still needs at least summary-level tool information in context to decide which tool to call; moving execution elsewhere does not address how much schema detail is loaded, which is the actual token-consumption lever progressive disclosure targets.
- E. Incorrect. Random sampling could exclude the tool actually needed for the current step and does not correspond to a deliberate staged disclosure of summary-then-detail information; it trades reliability for token savings rather than achieving both.
3.Choosing how much to expose: one-off, download, or live schema
Staging decides when content enters context. You also decide what is available to disclose at all. The Unity Gateway Skills tutorial gives three ways to use a skill you have found, and each one exposes a different amount.
- Load a skill once. The skill is used for the current session only, and nothing is saved. This is the narrowest option: exactly one skill, for exactly one session.
- Download a skill. The skill is copied to your local skills folders so it loads automatically every session and works offline. Copies are point-in-time, so you re-download to get updates.
- Load a schema live. The skill registry MCP server is scoped to a whole schema. Every skill in it then appears as a live tool named skill_acme.sql_skills.<skill>, and when a task matches a skill's description, the agent loads it on demand.
The live option still discloses progressively, because instructions arrive only on demand. However, it works on a whole schema at a time. You can't scope it to a single skill. Every skill in the schema is exposed as a live tool, and the consumption guide says each connected MCP server adds its tools to the context the agent carries. So if you need one skill, the tutorial's advice is to load it once instead of connecting its whole schema.
ug skills add --location acme.sql_skills --via mcpCheckpoint 5 of 8· Fill the gap
Live MCP loading is scoped by schema. Which flag completes this command?
ug skills add ? "<catalog>.<schema>" --via mcpLive loading always covers a whole schema, so it takes --location. The documentation states that --via mcp can't be combined with --path or --names.
Source: docs.databricks.comCheckpoint 6 of 8· Match them up
Match each way of using a skill to how much it exposes and for how long
Tap a term, then the definition that fits it.
The three options differ in scope (one skill or a whole schema) and in persistence (one session, every session, or always current through a connection).
“Load a skill once: for this session only. Nothing is saved. Best for a one-off.”Source: docs.databricks.com
4.Why staged loading uses fewer tokens than loading everything upfront
Put the cost model and the stages together and the savings follow directly. Loading upfront means every tool's full definition and every procedure's full text sits in context from the first turn. Because each turn re-sends the whole context, all of that is paid for again on every turn, including in chats that never use most of it. Staged loading keeps the always-present part small (descriptions and listings). The larger parts, instructions and files, are added only after a task has shown it needs them, so they are carried only for the turns that follow.
The Genie Code skills page contrasts the two approaches. Custom instructions are applied globally. Skills are loaded automatically and only in the relevant context, which the page says maintains an efficient context window. Skills can also hold more than instructions can: scripts, examples, and other resources. Because that extra material sits behind the on-demand load, it doesn't increase the cost of chats that don't use it.
Staging can also cut the number of turns, not just the size of each one. The consumption guide notes that a skill with an executable script lets the assistant recognize the request, load the skill, and run the script without planning and iterating from scratch. That turns a multi-turn task into a single low-consumption turn.
What the sources do not cover. None of the provided Databricks documentation uses the phrase 'progressive disclosure', and none gives token counts for full tool schemas compared with descriptions alone. The argument above rests on the documented mechanisms: per-turn re-sending, connected servers adding tools to context, and on-demand skill loading. It is not based on published measurements.
Checkpoint 7 of 8· Check yourself
A team has a long data-quality procedure that is needed in about one chat in twenty. Which approach keeps token use lowest across all chats?
Instructions load with every message, so the procedure would be paid for in all twenty chats. A skill is loaded only when relevant, so the other nineteen chats carry at most its description.
“Unlike custom instructions, which are applied globally, skills are loaded automatically and only in the relevant context.”Source: docs.databricks.com
Checkpoint 8 of 8· Exam question
A Databricks Agent Skill is packaged as a SKILL.md file with YAML front matter (name and short description) plus a longer body of instructions and several bundled reference files. Under progressive disclosure, which loading pattern minimizes tokens in the agent's context while still letting the model discover and use the skill correctly?
Correct answer: A — Front-matter stays visible for discovery; the body loads only when the model invokes the skill; bundled files load only as needed
- A. Correct. This mirrors the three-tier progressive disclosure pattern for Agent Skills: the cheap front-matter metadata always stays available so the model can discover the skill exists, the heavier instruction body loads only when the skill is actually invoked, and the largest bundled resources load only if the body directs the model to read them.
- B. Incorrect. Loading the full body and every bundled file for every skill at session start defeats the purpose of staged loading -- token cost scales with the total number of skills installed rather than with the number of skills actually used, which is exactly what progressive disclosure avoids.
- C. Incorrect. Hiding the front matter means the model has no way to discover that the skill exists or what it does in the first place, since the short metadata is precisely the always-available layer that enables selection; bundled files being visible without the body also skips the middle tier entirely.
- D. Incorrect. Loading content only after the conversation ends means it never actually informs the model's behavior during the conversation, so the skill could never be used; progressive disclosure stages loading within the conversation, not after it.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.An MCP server's tools cost nothing until the agent calls one of them.Why is that wrong?
Connecting a server adds its tools to the context the agent carries, and that context is re-sent every turn. Unused servers should be turned off.
Covered in Why tools loaded upfront cost tokens on every turn
2.Loading a skill pulls all of its bundled scripts and files into context at the same time.Why is that wrong?
load_skill brings in only the skill's instructions. Bundled files are a separate step: get_skill_files fetches specific files only when the skill has them.
Covered in The stages: description, instructions, then files
3.To expose just one skill through the live MCP connection, scope the connection to that single skill.Why is that wrong?
Live loading works only on whole schemas. To use one skill without exposing its whole schema, load it once for the session.
Covered in Choosing how much to expose: one-off, download, or live schema
4.Putting a procedure in custom instructions costs about the same as packaging it as a skill, because the content is identical.Why is that wrong?
Instructions load with every message. A skill is loaded only in the relevant context, so chats that don't need it never carry its full content.
Covered in Why staged loading uses fewer tokens than loading everything upfront
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Each turn re-sends the whole chat's context to the model”
↩︎ Why tools loaded upfront cost tokens on every turn“Consumption grows with both the length of a chat and the amount of context it carries”
↩︎ Why tools loaded upfront cost tokens on every turn“Turn off servers a chat doesn't need.”
↩︎ Why tools loaded upfront cost tokens on every turn“This turns a multi-turn task into a single low-consumption turn”
↩︎ Why staged loading uses fewer tokens than loading everything upfront“Each connected MCP server adds its tools to what Genie Code carries in context.”
↩︎ Exam trap 1“Because instructions load with every message, keep them lean.”
↩︎ Exam trap 4“Each connected MCP server adds its tools to what Genie Code carries in context.”
↩︎ Prediction“Disable MCP servers you aren't using. Each connected MCP server adds its tools to what Genie Code carries in context.”
↩︎ Checkpoint - 2.https://www.databricks.com/blog/ai-harnessSecondary source
“Giving the model too many tools at once increases confusion and slows decision-making before any work begins.”
↩︎ Why tools loaded upfront cost tokens on every turn - 3.https://docs.databricks.com/aws/en/agent-skillsOfficial docs
“Each skill is a Markdown file with front-matter metadata that describes when and how the skill should be used.”
↩︎ The stages: description, instructions, then files“AI coding assistants automatically discover and load relevant skills based on the task at hand.”
↩︎ The stages: description, instructions, then files - 4.
“The agent calls the list_skills MCP tool and reports what the schema holds.”
↩︎ The stages: description, instructions, then files“When a task matches a skill's description, the agent loads it on demand”
↩︎ Choosing how much to expose: one-off, download, or live schema“To use just one skill without loading its whole schema, load it for a one-off instead.”
↩︎ Choosing how much to expose: one-off, download, or live schema“Fetch specific bundled files from a skill”
↩︎ Exam trap 2“Live loading works on a whole schema at a time. You can't scope it to a single skill.”
↩︎ Exam trap 3“The agent calls the load_skill MCP tool to load the skill's instructions into context, and get_skill_files if the skill bundles supporting files.”
↩︎ Checkpoint“Load a skill once: for this session only. Nothing is saved. Best for a one-off.”
↩︎ Checkpoint - 5.
“You cannot combine --via mcp with --path or --names.”
↩︎ Choosing how much to expose: one-off, download, or live schema - 6.https://docs.databricks.com/aws/en/genie-code/skillsOfficial docs
“This maintains an efficient context window and reduces the need to provide the same context across multiple chats.”
↩︎ Why staged loading uses fewer tokens than loading everything upfront“With skills, you can provide greater context (such as scripts, examples, and other resources) for a task than you can with instructions.”
↩︎ Why staged loading uses fewer tokens than loading everything upfront“Unlike custom instructions, which are applied globally, skills are loaded automatically and only in the relevant context.”
↩︎ Key concept“Unlike custom instructions, which are applied globally, skills are loaded automatically and only in the relevant context.”
↩︎ Checkpoint