How do I use Duck MCP Server?

1. Click on "Deploy 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., "@Duck MCP Server Ask me to choose a color from red, blue, green." 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.

Duck MCP Server

by theddnc

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

Duck MCP Server 🦆

A simple MCP (Model Context Protocol) server built with FastMCP.

Features

This server provides the following tools:

select_option: Ask user to select one option from provided choices (uses elicitation)
provide_information: Request additional information from user in natural language (uses elicitation)
request_manual_test: Request the user to perform manual testing and report results (uses elicitation)

Related MCP server: mcpbin

Installation

Prerequisites

Python 3.10 or higher
uv (recommended) or pip

Install Dependencies

Using uv (recommended):

uv sync

Using pip:

pip install -e .

Usage

Running the Server

Using the FastMCP CLI (recommended):

# Run with default configuration from fastmcp.json
fastmcp run

# Or specify the config file explicitly
fastmcp run fastmcp.json

# Run with HTTP transport for testing
fastmcp run --transport http --port 8000

Using Python directly:

python server.py

Running with uv:

uv run fastmcp run server.py

Development Mode

Run with the FastMCP Inspector UI:

fastmcp dev

Inspect Server Capabilities

View all available tools, resources, and prompts:

fastmcp inspect

Installing to MCP Clients

Claude Desktop

fastmcp install claude-desktop

Cursor

fastmcp install cursor

Claude Code (VS Code Extension)

fastmcp install claude-code

Testing

You can test the server using a FastMCP client:

import asyncio
from fastmcp import Client

async def test_server():
    async with Client("http://localhost:8000/mcp") as client:
        # Ping the server to check connectivity
        await client.ping()
        print("Server is running!")

if __name__ == "__main__":
    asyncio.run(test_server())

Testing Elicitation Tools

The select_option, provide_information, and request_manual_test tools use FastMCP's elicitation feature to interactively request information from users:

import asyncio
from fastmcp import Client

async def elicitation_handler(message: str, response_type: type, params, context):
    """Handler that responds to server's elicitation requests"""
    print(f"Server asks: {message}")
    user_input = input("Your response: ")
    return response_type(selected_option=user_input) if hasattr(response_type, '__annotations__') and 'selected_option' in response_type.__annotations__ else response_type(information=user_input)

async def test_elicitation():
    async with Client("http://localhost:8000/mcp", elicitation_handler=elicitation_handler) as client:
        # Test select_option tool
        result = await client.call_tool("select_option", {
            "question": "What's your favorite programming language?",
            "options": ["Python", "JavaScript", "Rust", "Go"]
        })
        print(result.data)
        
        # Test provide_information tool
        result = await client.call_tool("provide_information", {
            "question": "What would you like to build today?"
        })
        print(result.data)
        
        # Test request_manual_test tool
        result = await client.call_tool("request_manual_test", {
            "test_description": "Navigate to the login page and verify the form renders correctly",
            "expected_outcome": "Login form should display username/password fields and submit button"
        })
        print(result.data)

if __name__ == "__main__":
    asyncio.run(test_elicitation())

Project Structure

duck-mcp/
├── server.py          # Main server implementation
├── fastmcp.json       # FastMCP configuration
├── pyproject.toml     # Project metadata and dependencies
├── README.md          # This file
└── tests/            # Test files (optional)

Development

Adding New Tools

To add a new tool to the server, simply decorate a function with @mcp.tool:

@mcp.tool
def my_new_tool(arg1: str, arg2: int) -> str:
    """Description of what this tool does"""
    # Your implementation here
    return "result"

Running Tests

pytest

Deployment

Local Deployment

The server runs with stdio transport by default, making it compatible with local MCP clients like Claude Desktop.

HTTP Deployment

For remote access, run with HTTP transport:

fastmcp run --transport http --host 0.0.0.0 --port 8000

FastMCP Cloud

Deploy to FastMCP Cloud for managed hosting (requires account):

fastmcp cloud deploy

Configuration

The fastmcp.json file contains the server configuration:

source: Location and entrypoint of the server code
environment: Python version and dependencies
deployment: Runtime configuration (transport, logging, etc.)

You can override any configuration via CLI arguments:

fastmcp run --port 8080 --log-level DEBUG

MCP Client Configuration

To use this MCP server with MCP-compatible clients (like Claude Desktop), add the following configuration to your client's mcp.json file:

Using uv (recommended):

{
  "mcpServers": {
    "duck-mcp": {
      "command": "uv",
      "args": ["run", "fastmcp", "run", "server.py"],
      "cwd": "/path/to/duck-mcp"
    }
  }
}

Using Python directly:

{
  "mcpServers": {
    "duck-mcp": {
      "command": "python",
      "args": ["server.py"],
      "cwd": "/path/to/duck-mcp"
    }
  }
}

Replace /path/to/duck-mcp with the actual path to your duck-mcp directory. The cwd (current working directory) ensures the server runs from the correct location.

Learn More

License

MIT

Available Tools

3 tools

provide_informationC

Request additional information from user in natural language.

ParametersJSON Schema

Name	Required	Description	Default
`question`	Yes	Detailed but brief question asking for specific information

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

Without annotations, the description carries the full burden of behavioral disclosure. It only states the action of requesting information, with no details on side effects, whether it is read-only, or what happens after the user responds.

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. It is front-loaded and efficient, though it could be slightly more structured with additional context.

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

Completeness2/5

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

Given the lack of annotations and the simple one-parameter schema, the description is too minimal. It does not explain the return value (despite an output schema existing) or what happens after the user provides information, leaving the agent underinformed.

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%, and the single parameter 'question' has a clear description in the schema. The tool description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.

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

Purpose4/5

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

The description clearly states the tool requests information from the user in natural language, using a specific verb and resource. It implicitly distinguishes from siblings like 'select_option' which involves choices, but does not explicitly differentiate.

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 is provided on when to use this tool versus alternatives like 'request_manual_test' or 'select_option'. The description lacks context for appropriate usage scenarios.

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

request_manual_testC

Request the user to perform manual testing and report results.

This tool allows an agent to ask a user to perform manual testing of functionality, and then collect the results via elicitation for analysis.

ParametersJSON Schema

Name	Required	Description	Default
`expected_outcome`	No	Optional description of what the expected outcome should be
`test_description`	Yes	Detailed description of what manual testing should be performed

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It only states the tool requests and collects results via elicitation, but omits details like whether it blocks, is async, or has side effects. Minimal transparency.

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?

Two sentences, front-loaded with the core purpose. No redundancy. Could be slightly tighter but effective.

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

Completeness2/5

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

Despite simple parameters and an output schema, the description lacks crucial context about the interaction flow (e.g., synchronous vs async, how results are returned). Incomplete for an agent invoking the tool.

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 covers both parameters with descriptions. The description adds context about collecting results for analysis, but does not significantly enhance parameter meaning beyond the schema. Baseline score.

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

Purpose4/5

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

The description clearly states the tool requests manual testing and collects results via elicitation. It distinguishes from sibling tools like provide_information and select_option, but could be more specific about the 'elicitation' process.

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 implies use for manual testing but does not contrast with provide_information or select_option, leaving the agent uncertain about context.

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

select_optionB

Ask user to select one option from provided choices.

ParametersJSON Schema

Name	Required	Description	Default
`options`	Yes	List of detailed but brief options for the user to choose from
`question`	Yes	Detailed but brief question to ask the user

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It only says 'ask user to select' but doesn't mention whether it blocks, waits for response, or any side effects. Essential details are missing.

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 one sentence of 8 words, very concise. It could be slightly more informative without much added length, but it is well-structured and front-loaded.

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 simple tool with two params and an output schema, the description is adequate but does not mention what the tool returns or any other behavioral context. Slightly lacking for completeness.

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 description coverage is 100% (both params have descriptions). The description adds no additional meaning beyond the schema, so baseline score of 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 verb 'ask' and the resource 'user to select one option from provided choices'. It distinguishes from sibling tools (provide_information, request_manual_test) which serve different purposes.

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. No context provided for when to ask user to select vs other interaction patterns.

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.

3 tool updatesv0.1.0Jul 13, 2026
- First observedprovide_information
- First observedrequest_manual_test
- First observedselect_option

Deploy Server

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

TDQS

B3.4/5.0

Scored 2026-07-13 14:05 across 3 tools

Disambiguation5/5

Each tool has a distinct purpose: providing information, requesting manual tests, and selecting options. There is no overlap or ambiguity between them.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (provide_information, request_manual_test, select_option), with clear and descriptive naming.

Tool Count4/5

With 3 tools, the set is minimal but well-scoped for a server focused on user interaction requests. It is slightly thin but appropriate for its apparent purpose.

Completeness3/5

The tools cover key user elicitation tasks (info, manual test, option selection), but lack general action requests or confirmations, leaving some gaps in the interaction surface.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

looptool
dev.looptool
An MCP server that automatically collects feedback on your MCP server.
Monitoring Developer Tools
2
Os Automation Mcp C
io.github.varvararatta
MCP server for OS Automation
OS Automation Command Line
2
Support Service Management Mcp D
io.github.varvararatta
MCP server for Support & Service Management
Customer Support Project Management
2
AgentMarketplace A
io.github.raditotev
MCP Server for an Agent Task Marketplace
Autonomous Agents Agent Orchestration
221

Related MCP Servers

MCP Elicitations Demo Server
soriat
A
license
C
quality
D
maintenance
A demonstration server that showcases how to collect user input dynamically using the Model Context Protocol (MCP) elicitation system across tools, resources, and prompts.
Updated a year ago (2025-09-03 22:45 UTC)
10
147,956
-
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-elicitations
Developer Tools Search
0GiS0
F
license
Not graded
quality
D
maintenance
A demonstration MCP server that shows how to use elicitations to ask users for preferences during a video search tool execution.
Updated a year ago (2025-07-31 07:16 UTC)
1
-
Stakeholder MCP Server
Product Management AI & Machine Learning
okkimus
F
license
Not graded
quality
D
maintenance
An MCP server that provides tools to consult predefined or custom stakeholder personas for iterative product feedback and design reviews.
Updated 7 months ago (2026-02-07 19:09 UTC)
1
-