How do I use MCP Node Tasks 05 - Sampling?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Node Tasks 05 - Sampling Plan my next work session using sampling" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

MCP Node Tasks 05 - Sampling

by krollchristensen

Overview Schema Related Servers Score Discussions

JavaScript

Local

MCP node tasks 05 - sampling

Dette projekt er femte del af vores praktiske introduktion til Model Context Protocol, forkortet MCP.

I de tidligere dele har vi arbejdet med:

Del 1: Arkitektur og begreber
Del 2: MCP-server med resource, tool og prompt
Del 3: Custom MCP-client
Del 4: Samlet workflow med tools, resources og prompts
Del 5: Sampling

I denne del ser vi på sampling.

Sampling betyder, at en MCP-server kan bede clientens LLM om hjælp midt i et workflow.

Vigtig pointe

I de første dele gik flowet primært denne vej:

Client -> server

Med sampling kan serveren også spørge tilbage:

Server -> clientens LLM -> server

Det betyder, at serveren kan bruge modelhjælp uden selv at have en LLM API-nøgle.

Related MCP server: mcpbin

Formål

Efter denne del skal du kunne forklare:

Hvad sampling er
Hvorfor sampling kræver client-support
Hvordan sampling adskiller sig fra almindelige tool calls
Hvordan en server kan bede clienten om modelhjælp
Hvordan en client-side sampling handler fungerer
Hvorfor fallback og fejlhåndtering er vigtigt
Hvorfor sampling kan give sikkerheds- og privatlivsproblemer

Projektstruktur

mcp-node-tasks-05-sampling/
├── data/
│   ├── project-guide.md
│   └── tasks.json
├── docs/
│   └── images/
│       ├── image-26.png
│       ├── image-28.png
│       └── image-29.png
├── src/
│   ├── server.js
│   ├── samplingClient.js
│   └── taskStore.js
├── package.json
└── README.md


## Hvad er sampling?

Sampling er en MCP-mekanisme, hvor serveren kan bede clienten om en LLM-completion.

Eksempel:

1. Clienten kalder et tool på serveren.
2. Serveren læser data.
3. Serveren har brug for en AI-formuleret analyse.
4. Serveren sender en sampling request til clienten.
5. Clienten bruger sin LLM eller sampling handler.
6. Serveren modtager svaret.
7. Serveren returnerer det endelige tool-resultat.

## Hvorfor bruger vi en custom client?

Claude Desktop og Cursor kan være gode til tools, men sampling afhænger af, om hosten understøtter MCP sampling.

Derfor tester vi sampling med en custom client:

```text
src/samplingClient.js

Den starter serveren og registrerer en sampling handler.

Hvad er en sampling handler?

En sampling handler er en funktion på client-siden.

Den kaldes, når serveren sender en sampling request.

I et rigtigt setup kan handleren kalde en LLM.

I dette undervisningseksempel bruger vi en simpel lokal handler uden API-nøgle.

Det gør flowet lettere at forstå.

Serverens capabilities

Serveren udstiller både tidligere capabilities og et nyt sampling-tool.

Type	Navn	Funktion
Resource	`tasks://all`	Læser alle tasks
Resource	`tasks://open`	Læser kun åbne tasks
Resource	`project://guide`	Læser projektets prioriteringsguide
Tool	`add_task`	Opretter en ny task
Tool	`complete_task`	Markerer en task som færdig
Tool	`sample_next_work_session`	Bruger sampling til at foreslå næste arbejdssession

Samlet sampling-flow

flowchart TD
    A["npm run sampling"]
    B["src/samplingClient.js<br>Custom MCP client"]
    C["Sampling handler<br>Simuleret LLM-svar"]
    D["src/server.js<br>MCP-server"]
    E["Tool<br>sample_next_work_session"]
    F["Resource data<br>project-guide + open tasks"]
    G["sampling/createMessage<br>Server spørger clienten"]
    H["Tool-resultat<br>Plan for næste session"]
    I["data/project-guide.md"]
    J["data/tasks.json"]

    A --> B
    B --> D
    B --> C
    B --> E
    E --> D
    D --> F
    F --> I
    F --> J
    D --> G
    G --> C
    C --> D
    D --> H
    H --> B

Almindeligt tool call vs sampling

Flow	Hvad sker der?
Almindeligt tool call	Clienten kalder serveren, og serveren returnerer resultat
Sampling tool call	Clienten kalder serveren, serveren spørger clientens LLM, og serveren returnerer derefter resultat

Kort sagt:

Almindeligt tool:
Client -> server -> resultat

Sampling:
Client -> server -> clientens LLM -> server -> resultat

Installation

Kør:

npm install

Kør serveren alene

Du kan køre serveren alene:

npm start

Serveren bruger stdio og kan se ud som om, den ikke gør noget.

Det er normalt.

Den venter på en MCP-client.

Test med MCP Inspector

Kør:

npm run inspect

Test især dette tool:

sample_next_work_session

Vigtig pointe:

Hvis MCP Inspector eller hosten ikke understøtter sampling, bruger serveren fallback-logik og returnerer en simpel regelbaseret plan.

Kør sampling-client

Sampling testes bedst med den custom client:

npm run sampling

samplingClient.js gør dette:

Starter MCP-serveren
Registrerer en sampling handler
Laver discovery
Kalder sample_next_work_session
Modtager sampling request fra serveren
Returnerer et simuleret LLM-svar
Viser serverens endelige resultat

Claude Desktop

Denne del er primært lavet til custom client.

Claude Desktop kan stadig bruges til almindelige tools, men sampling afhænger af, om Claude Desktop understøtter sampling i den aktuelle version.

Brug derfor Claude til de almindelige tools fra del 4:

prepare_next_work_session
prepare_status_report
add_task
complete_task

Brug custom client til sampling:

npm run sampling

Claude-konfiguration

Hvis du vil koble serveren til Claude Desktop, kan du bruge:

{
  "mcpServers": {
    "mcp-node-tasks-05": {
      "command": "node",
      "args": [
        "C:\\Users\\mikc\\WebstormProjects\\mcp-node-tasks-05-sampling\\src\\server.js"
      ]
    }
  }
}

Ret stien, så den passer til din computer.

På Windows kan du også bruge forward slashes:

C:/Users/mikc/WebstormProjects/mcp-node-tasks-05-sampling/src/server.js

Forslag til test i Claude

Hvis serveren er koblet på Claude, kan du prøve:

Vis hvilke tools denne MCP-server stiller til rådighed.

Brug tool’et sample_next_work_session med fokus på MCP-undervisning.

Hvis Claude eller hosten ikke understøtter sampling, bør serveren bruge fallback og stadig give et svar.

Sikkerhed og fallback

Sampling kan sende data fra serveren til clientens LLM.

Det kan være fint i et lokalt undervisningsprojekt, men i rigtige systemer skal man være opmærksom på:

følsomme data
prompt injection
for store prompts
rate limiting
brugeraccept
fejl i clientens sampling handler
om clienten understøtter sampling

I dette projekt bruger vi derfor fallback.

Hvis sampling fejler, returnerer serveren en simpel regelbaseret prioritering.

Miniøvelse

Åbn src/server.js.

Find tool’et:

sample_next_work_session

Svar på:

Hvilke data læser tool’et?
Hvor sendes sampling requesten?
Hvad sker der, hvis sampling fejler?
Hvorfor bør der være fallback?
Hvilke data ville være problematiske at sende til en ekstern LLM?

Ekstra øvelse

Udvid sampling handleren i src/samplingClient.js, så den svarer forskelligt afhængigt af fokus.

Eksempel:

fokus: dokumentation

bør give et andet svar end:

fokus: demo

Næste trin

Næste naturlige skridt er testing og security.

Her bliver spørgsmålene:

Hvordan tester vi MCP tools?
Hvordan tester vi fallback?
Hvordan undgår vi farlige tools?
Hvordan logger vi tool calls?
Hvordan beskytter vi følsomme data?

Available Tools

3 tools

add_taskAdd taskA

Opretter en ny task i data/tasks.json

ParametersJSON Schema

Name	Required	Description	Default
`title`	Yes	Titlen på den nye task
`priority`	Yes	Prioritet: low, medium eller high

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose all behaviors. It mentions creating a task in a JSON file, which is basic, but lacks details on side effects, file persistence, or concurrency issues.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence, front-loaded with the key action. It is efficient, though could benefit from minor structural enhancements.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description does not explain return values or error states. For a simple create tool, it is minimally complete but lacks detail on success/failure behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the input schema already describes parameters adequately. The description adds no additional meaning beyond stating that a task is created.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Creates a new task in data/tasks.json' clearly states the verb 'creates' and the resource 'task in data/tasks.json', distinguishing it from siblings like 'complete_task'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for creating tasks, but does not explicitly state when to use this tool versus alternatives or provide any exclusions. Sibling tool names offer some context but no direct guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

complete_taskComplete taskB

Markerer en task som færdig ud fra id

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Id på den task, der skal markeres færdig

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the full burden. It only states the operation without disclosing side effects, error conditions (e.g., task not found or already completed), or permissions required. This is insufficient for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence with no wasted words. It is efficient, though it could benefit from additional detail without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the low complexity (1 param, no output schema), the description covers the basic purpose but lacks behavioral details. It is minimally adequate but not comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter (id) with 100% schema coverage. The description essentially restates the schema's 'description' field (Id på den task...), adding no extra meaning beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (mark as completed), the resource (task), and it uses the unique identifier (id). It is distinct from sibling tools like add_task (adds) and sample_next_work_session (samples).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. The description does not mention prerequisites, when not to use, or any conditions. The context from sibling names is not leveraged.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sample_next_work_sessionSample next work sessionA

Bruger MCP sampling til at få clientens LLM til at foreslå næste arbejdssession

ParametersJSON Schema

Name	Required	Description	Default
`focus`	No	Valgfrit fokus, fx undervisning, demo eller dokumentation

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavior. It mentions 'MCP sampling' but does not describe side effects, permissions, or whether the operation is read-only or modifies state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence, but it could benefit from a brief structure like stating the purpose and then the parameter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one optional parameter and no output schema, the description adequately conveys the core functionality, though it lacks behavioral details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a single parameter described as 'Optional focus'. The description adds no additional meaning beyond the schema's own description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action: using MCP sampling to get the client's LLM to suggest the next work session. It distinguishes from siblings (add_task, complete_task) by focusing on suggestion rather than task management.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when a suggestion for the next work session is needed, but provides no explicit when-to-use, when-not-to-use, or alternative guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

3 tool updatesv1.0.0Jul 9, 2026
- First observedadd_task
- First observedcomplete_task
- First observedsample_next_work_session

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: creating a task, completing a task, and suggesting a next work session. No overlap or confusion possible.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern using snake_case: add_task, complete_task, sample_next_work_session. Predictable and clear.

Tool Count4/5

With only 3 tools for a task management server, the count is slightly low but appropriate given the specialized focus on sampling-driven workflow. Not excessive or trivial.

Completeness2/5

Missing essential operations like listing tasks, deleting tasks, or updating task details. An agent cannot retrieve tasks to complete them, creating a significant gap in the workflow.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

PlanExe A
io.github.PlanExeOrg
MCP server for generating rough-draft project plans from natural-language prompts.
Autonomous Agents Developer Tools Project Management
113398
strata
ai.klavis
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Agent Orchestration Autonomous Agents Developer Tools
25,748
mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
jumpcloud-genaiOAuth
com.jumpcloud
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Cloud Platforms Security Developer Tools
2

Related MCP Servers

mcp-llm
Code Execution Autonomous Agents
sammcj
A
license
B
quality
C
maintenance
An MCP server that provides LLMs access to other LLMs
Updated a year ago (2025-03-15 05:37 UTC)
4
48
78
MIT
mcpbin
Testing & QA Tools Developer Tools
bugffet
F
license
Not graded
quality
D
maintenance
A testing server for MCP client implementations that provides tools for echoing data, error handling, timing operations, data generation, LLM sampling, and user elicitations.
Updated 9 months ago (2025-12-06 03:44 UTC)
-
MCP Sampling Demo
Developer Tools Code Execution Autonomous Agents
0GiS0
F
license
Not graded
quality
D
maintenance
Demonstrates how to implement sampling in MCP servers, allowing tools to request LLM content generation from the client without requiring external API integrations or credentials.
Updated 10 months ago (2025-10-27 06:48 UTC)
1
-
sampling-mcp
Text Summarization AI & Machine Learning
srod0010
F
license
B
quality
D
maintenance
A minimal FastMCP server demonstrating the sampling mechanism, where the server requests a client-side LLM completion to summarize documents.
Updated 3 months ago (2026-06-12 21:55 UTC)
1
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/krollchristensen/mcp-node-tasks-05-sampling'

If you have feedback or need assistance with the MCP directory API, please join our Discord server