 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
[[tool]]
name = "add_task"
description = "Adds a new task to your todo list."
input_parameters = [
{ name = "task_description", type = "string", description = "The task to add to your todo list." }
]
[[prompt]]
name = "plan_daily_tasks"
description = "Plans the day by breaking down a user goal into actionable tasks."
input_parameters = [
{ name = "user_goal", type = "string", description = "The user's goal for the day." }
]
template = """
Based on the user's goal: '{user_goal}', generate 2-3 specific, actionable tasks that would help the user achieve it.
For each task, call the `add_task` tool with a helpful task description.
"""
[[tool]]
name = "schedule_event"
description = "Schedules an event in your calendar."
input_parameters = [
{ name = "task_description", type = "string", description = "The task or event to be scheduled." },
{ name = "time", type = "string", description = "The time when the event should be scheduled (e.g., '2pm today')." }
]
[[prompt]]
name = "schedule_todo_task"
description = "Schedules a task from the todo list into your calendar."
input_parameters = [
{ name = "task_description", type = "string", description = "The task to schedule." }
]
template = """
The user wants to schedule the task: '{task_description}'.
Suggest a good time for today and call the `schedule_event` tool to add it to the calendar.
"""
plan_daily_tasks from the Todo Server, which returns a prompt directing the LLM to break down the goal into actionable tasks using add_task.
As tasks are created and the LLM is notified, the LLM reasons further and decides to schedule the tasks by invoking schedule_todo_task, triggering the Calendar Server. That server responds with new prompt guidance to use schedule_event, at which point the LLM finalizes the day’s plan with specific times.
Each tool interaction is routed and mediated by the MCP client, which manages the reasoning loop, coordinates tool execution and tracks interaction state across the session. This forms a fully agentic workflow: the user sets the goal, the LLM reasons and decides, the MCP servers expose tools and dynamic prompts and the MCP client orchestrates the process, enabling intelligent, composable automation across domains.
👁 From a very basic and high-level prompt, you now have an agent that makes several decisions on its own to reach an end goal.
dev-scaffolding MCP server that acts as a high-level orchestrator that focuses on helping devs go from ideas to working code by coordinating several specialized, upstream MCP servers. When a user requests a new app feature (e.g., “Add a login feature”), the orchestrator server uses upstream servers — spec-writer to generate an API spec, code-gen to scaffold code from that spec and test-writer to produce corresponding test cases.
These collective MCP servers could also be used for environment-specific functionality. In other words, they expose the same interface (e.g., query_database) but are configured for different environments. This would allow you to have a dev-app-server that includes upstream MCP servers like a dev-db-server using a SQlite database, a dev-auth-server that returns mocked auth responses and a dev-deploy-server that wraps a local command-line interface (CLI) tool. Then the prod-app-server would point to correlated upstream servers tied to cloud-based deployments.
Platforms like mcp.run have already heavily leveraged this composability. Mcp.run allows you to install an extensible, dynamically updateable server that leverages an upstream registry of MCP servers it calls servlets. These servlets do not need to be installed locally but can run remotely on the mcp.run infrastructure.
This is quite powerful for a number of reasons, but for the purposes of this article, it highlights an important shift that is taking place in the MCP ecosystem: remote MCP servers. That’s the topic of my third and final article in this series.
Want to learn more? See how Kong is solving real-world MCP server challenges today.
