|
2 | 2 |
|
3 | 3 | <EpicVideo url="https://www.epicai.pro/workshops/day-3-advanced-tools-sampling-and-elicitation/outro-you-ve-finished-advanced-mcp~ly753" /> |
4 | 4 |
|
5 | | -Thank you for joining me for this workshop. I hope you have a much better understanding of the more advanced capabilities of MCP servers! |
| 5 | +You made it all the way through! This workshop took you beyond the fundamentals and into the capabilities that make MCP servers powerful, adaptable, and genuinely helpful in real-world AI-assisted workflows. |
| 6 | + |
| 7 | +## What you've learned |
| 8 | + |
| 9 | +### 1. Advanced Tools |
| 10 | + |
| 11 | +- **Annotations:** You learned to communicate intent and risk with `readOnlyHint`, `destructiveHint`, `idempotentHint`, and `openWorldHint`, improving UX and trust without confusing them for security controls. |
| 12 | +- **Structured Output & Output Schemas:** You defined schemas to guarantee machine-parseable results (and saw how invalid shapes fail fast). This unlocks safer automation and downstream chaining. |
| 13 | +- **Pragmatic Guidelines:** You adopted practical heuristics (e.g. idempotency focuses on core outcome, not incidental timestamps) so annotations remain meaningful instead of pedantic. |
| 14 | + |
| 15 | +### 2. Elicitation |
| 16 | + |
| 17 | +- **Human-in-the-Loop Input Requests:** You implemented server-initiated, structured follow-up questions mid-tool execution using `elicitation/create`. |
| 18 | +- **Outcome Handling:** You handled all result paths (`accept`, `decline`, `cancel`) cleanly. |
| 19 | +- **Responsible Use:** You learned to reserve elicitation for genuinely missing contextual data. Not as a crutch for weak initial prompts. |
| 20 | + |
| 21 | +### 3. Sampling |
| 22 | + |
| 23 | +- **Borrowing the User's Model:** Instead of bundling your own API integrations, you requested completions through the client. Respecting user controls, permissions, and model preferences. |
| 24 | +- **Prompt Crafting:** You structured `systemPrompt` + message history for clarity, determinism, and safety (plus using examples and formatting expectations). |
| 25 | +- **Server-Side Logging:** You surfaced debug + informational events back to clients to aid transparency and troubleshooting. |
| 26 | +- **Use Cases:** Automated tag suggestions, summarization, and other “assistive” behaviors that keep users in the loop. |
| 27 | + |
| 28 | +### 4. Long Running Tasks |
| 29 | + |
| 30 | +- **Progress Notifications:** You emitted `notifications/progress` tied to a `progressToken`, giving users visibility into multi-step operations. |
| 31 | +- **Cancellation Flow:** You honored `notifications/cancelled`, wiring cleanup with `AbortController` (and ensuring resource release / early exit paths). |
| 32 | +- **Resilient Async Patterns:** You separated work orchestration from lifecycle signals for maintainability and correctness. |
| 33 | + |
| 34 | +### 5. Changes (Dynamic Capabilities) |
| 35 | + |
| 36 | +- **list_changed Notifications:** You notified clients when tools, prompts, or resources appeared, disappeared, or changed. Keeping UIs reactive without manual refresh. |
| 37 | +- **Resource Templates vs. Instances:** You distinguished template availability (enable/disable) from the evolving set of expansions (e.g. DB rows, files) and triggered updates accordingly. |
| 38 | +- **Subscriptions:** You pushed granular `resources/updated` messages only to interested clients, enabling efficient, real-time views. |
| 39 | +- **Adaptive Servers:** You embraced dynamic capability surfaces. Mirroring real application states (auth, data presence, feature flags, external systems). |
| 40 | + |
| 41 | +--- |
| 42 | + |
| 43 | +### Putting It All Together |
| 44 | + |
| 45 | +Across these exercises you built a server that can: |
| 46 | + |
| 47 | +- Advertise rich, self-describing tools with trustworthy semantics. |
| 48 | +- Produce and validate structured results ready for chaining or UI rendering. |
| 49 | +- Ask users clarifying questions at exactly the right moment. |
| 50 | +- Leverage the user's own model access for generation instead of hard-coding providers. |
| 51 | +- Stream transparency via logs, progress, and cancellation. |
| 52 | +- Stay in sync with clients as its surface area evolves in real time. |
| 53 | + |
| 54 | +### Suggested Next Steps |
| 55 | + |
| 56 | +1. **Refine Prompts:** Introduce test fixtures for sampling prompts. Assert on shape + tone of generated outputs. |
| 57 | +2. **Add Safety Layers:** Layer classification or content filtering around generative outputs where needed. |
| 58 | +3. **Observability:** Pipe server logs to structured tracing/metrics for production use (keeping privacy in mind). |
| 59 | +4. **Capability Versioning:** Start tagging major tool/prompt contract shifts to help clients adapt gracefully. |
| 60 | +5. **Extend Resources:** Expose more dynamic domains (user workspaces, recent activity feeds, external APIs) with subscriptions where latency matters. |
| 61 | + |
| 62 | +### Conclusion |
| 63 | + |
| 64 | +You now have the patterns to build adaptive, responsible, user-centric MCP servers. Keep iterating: optimize prompts, tighten schemas, and observe how real users (and their assistants) behave. Small refinements compound quickly. |
| 65 | + |
| 66 | +Great work pushing through the advanced material. Looking forward to what you build next! |
0 commit comments