Eonevolve Learning
Unity and DevelopmentUnity and codeIntermediate~7 min

Do More with Less MCP Context

Snapshot

~85 sec

Deliberate context budgets keep MCP work focused. Discover capabilities progressively, filter and summarize on the server, page bounded results with an opaque cursor, and request detail only for evidence that affects the decision. Less context can reduce waste, but it is not an automatic speed, cost, or quality guarantee.

You will learn

  • Replace whole-project and full-console dumps with filters, summaries, and bounded pages.
  • Use progressive discovery and detail-on-demand to load only relevant schemas and evidence.
  • Treat cursors as opaque server-issued continuation tokens rather than client data structures.

Target outcome

You can design an MCP context budget that returns enough evidence for the next decision without hiding coverage or dumping unrelated project state.

Visual walkthrough

Visual walkthrough

~7 min

  1. Six context-budget controls

    • Filter

      Select by severity, scene, object, time window, or another decision-relevant field.

    • Summary

      Aggregate counts and groups before returning individual records.

    • Page

      Return a bounded number of results plus continuation state.

    • Opaque cursor

      A server-issued token the client stores and returns without parsing or constructing it.

    • Progressive discovery

      Load tool or resource detail when the task needs it rather than front-loading every schema.

    • Evidence

      Return identifiers, applied filters, coverage, and truncation state with the conclusion.

  2. Context dump versus deliberate budget

    ApproachRequest shapeCoverage signalNext decisionFailure risk
    Return everythingA generic tool sends all console entries, the full invented hierarchy, and every available tool schema.No scene, severity, time, field, or result limit constrains the payload.A large response still may not state whether it was truncated or stale.The model must search unrelated material before it can choose what to inspect.Relevant evidence can be buried while secrets or unrelated project details are exposed.
    Return decision evidenceRequest error groups for one invented scene, then inspect only the selected group or object.Severity, scene, summary fields, page size, and detail level are explicit.Counts, filters, truncation, and nextCursor show what the response includes.The summary identifies one group whose stable IDs justify a detail request.The bounded surface reduces unrelated exposure, but the evidence still needs interpretation.

  3. Grow context only when the decision requires it

    Start with intent and discovery, request a bounded summary, then add one page or one detail record only when the previous evidence leaves a material question.

    1. Name the decision

      Example: which error family blocks the invented PracticeRoom scene?

    2. Discover relevant capability

      Load the console-summary tool contract, not every connected server schema.

    3. Request bounded summary

      Filter severity and scene; group by error type; return counts and coverage.

      summarize_console(severity: "error", scene: "PracticeRoom")

    4. Select material evidence

      Choose the MissingReference group because it blocks scene validation.

    5. Fetch detail on demand

      Read one bounded page of stable entry IDs or inspect one referenced object.

    6. Return evidence, not a dump

      State filters, IDs, counts, truncation, and what remains unknown.

    Start with intent and discovery, request a bounded summary, then add one page or one detail record only when the previous evidence leaves a material question.

    Reading order

    1. Name the decision

      Example: which error family blocks the invented PracticeRoom scene?

    2. Discover relevant capability

      Load the console-summary tool contract, not every connected server schema.

    3. Request bounded summary

      Filter severity and scene; group by error type; return counts and coverage.

      summarize_console(severity: "error", scene: "PracticeRoom")
    4. Select material evidence

      Choose the MissingReference group because it blocks scene validation.

    5. Fetch detail on demand

      Read one bounded page of stable entry IDs or inspect one referenced object.

    6. Return evidence, not a dump

      State filters, IDs, counts, truncation, and what remains unknown.

    Connection explanations

    1. Name the decision → Discover relevant capability (scopes)

      The decision tells the client which server capability is relevant.

    2. Discover relevant capability → Request bounded summary (enables)

      Progressive discovery loads the chosen contract before a bounded request is formed.

    3. Request bounded summary → Select material evidence (reveals)

      Aggregation makes the material error family visible before individual records are loaded.

    4. Select material evidence → Fetch detail on demand (justifies)

      A detail request is earned by evidence, not made automatically for every group.

    5. Fetch detail on demand → Return evidence, not a dump (supports)

      The final response carries stable references and coverage so another reviewer can inspect the same evidence.

  5. Read a page as evidence plus continuation state

    Invented structured result. The server summarizes matching records, returns a bounded page, and supplies an opaque continuation token without exposing its internal pagination scheme.

    Languagejson
    {
  "summary": {
    "matchingErrors": 27,
    "returned": 10,
    "groupedByType": 3
  },
  "items": [
    { "id": "log-1042", "type": "MissingReference", "count": 12 }
  ],
  "nextCursor": "opaque:server-issued-value",
  "evidence": {
    "filters": { "severity": "error", "scene": "PracticeRoom" },
    "truncated": true
  }
}

    Code annotations

    1. Lines 2-6

      Summary before detail

      Counts show total matches, returned records, and grouping coverage before the item list is interpreted.

      Effect: The caller can decide whether another page or a focused detail request is worth the context.

    2. Lines 7-9

      Return stable references

      The representative item includes an identifier and aggregate count rather than a full repeated stack trace.

      Effect: A later request can target the same evidence without repeating the whole payload.

    3. Line 10

      Do not interpret the cursor

      The client stores and returns the server-issued cursor exactly as received.

      Effect: The server remains free to change its internal pagination implementation.

    4. Lines 11-14

      Make coverage explicit

      Applied filters and truncated state prevent the page from being mistaken for the complete dataset.

      Effect: The final diagnosis can state what was inspected and what remains outside the page.

  7. Budget an invented scene diagnosis

    A server can return 4,000 console entries and a 900-object hierarchy. The task is to explain errors tied to one invented PracticeRoom scene. What should the first two context requests be?

    Expected reasoning

    First request a bounded summary filtered to error severity and PracticeRoom, grouped by error type with counts, coverage, and truncation state. Then request detail only for the material group, using stable IDs and a small page size or inspecting the exact referenced object. Keep the next cursor opaque and return the selected evidence plus what remains unknown.

Go deeper