The MCP-Confirm server enables AI assistants to seek user confirmation and clarification through structured protocols. You can:
• Ask yes/no questions to verify user intent or clarify requests • Confirm actions before executing potentially impactful operations, including details on consequences • Clarify ambiguous requests by presenting multiple interpretation options • Verify understanding of user requirements and confirm planned next steps • Collect ratings to gather user feedback on AI responses or assistance quality • Create custom confirmation dialogs using specified JSON schemas for unique data collection needs • Search confirmation history with filtering by type, status, date range, and response time • Analyze confirmation data including success rates, response times, and trends with grouping capabilities
Provides example implementation for Node.js projects, enabling AI to confirm actions before project creation and manipulation.
Enables confirmation workflows when working with PostgreSQL databases, particularly in verification steps for database implementations.
Offers integration options for Python projects, allowing AI to clarify intent when users request Python project creation.
Supports React application development workflows, enabling AI to verify understanding before implementing features like user authentication.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP-Confirm confirm before deleting the temporary files folder"
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.
An MCP server that implements confirmation protocols between AI and users. It provides tools for LLMs to request user confirmation when they need clarification or verification.
A Model Context Protocol (MCP) server for AI-user confirmation and clarification. This server provides tools for AI assistants (LLMs) to ask users for confirmation when they need clarification or verification.
This MCP server implements the Model Context Protocol Elicitation specification to enable confirmation and clarification protocols between AI assistants and users.
AI assistants can use this in situations such as:
Confirming actions before execution
Clarifying ambiguous requests
Verifying understanding is correct
Asking yes/no questions
Collecting user satisfaction ratings
Related MCP server: askme-cli
ask_yes_no
Ask yes/no confirmation questions
Used when AI needs clarification or verification
confirm_action
Confirm actions before execution
Includes impact and details in confirmation dialog
clarify_intent
Clarify ambiguous requests
Present multiple interpretation options
verify_understanding
Verify AI's understanding is correct
Confirm next steps before proceeding
collect_rating
Collect user satisfaction ratings
Evaluate AI response quality
elicit_custom
Custom confirmation dialogs
Use custom JSON schemas
search_logs
Search confirmation history logs
Filter by type, success status, date range, response time
Paginated results for large datasets
analyze_logs
Statistical analysis of confirmation history
Success rates, response times, trends
Grouping by type, time period, etc.
# Install globally
npm install -g @mako10k/mcp-confirm
# Or use with npx
npx @mako10k/mcp-confirmThis project supports development with GitHub Codespaces:
Open this repository on GitHub
Click the "Code" button
Select the "Codespaces" tab
Click "Create codespace on main"
The development environment will be set up automatically
For details, see DEVELOPMENT.md.
You can configure the server using environment variables:
MCP_CONFIRM_LOG_PATH: Path to confirmation history log file (default: .mcp-data/confirmation_history.log)
MCP_CONFIRM_TIMEOUT_MS: Default timeout for confirmations in milliseconds (default: 180000 = 3 minutes)
Minimum: 5000 (5 seconds)
Maximum: 1800000 (30 minutes)
Invalid values will fall back to default with warning
NODE_ENV: Set to development to enable debug logging
# Use 5-minute timeout
export MCP_CONFIRM_TIMEOUT_MS=300000
# Use 1-minute timeout
export MCP_CONFIRM_TIMEOUT_MS=60000
# Use 10-second timeout (minimum enforced)
export MCP_CONFIRM_TIMEOUT_MS=10000The server uses intelligent timeout settings based on confirmation type:
Critical actions (delete, remove operations): 120 seconds
Warning actions: 90 seconds
Simple yes/no questions: 30 seconds
Rating requests: 20 seconds (reference only)
Other confirmations: 60 seconds (default)
All confirmation interactions are logged to a file for audit purposes. The log includes:
Timestamp of the request
Confirmation type
Full request and response data
Response time in milliseconds
Success/failure status
Error messages (if any)
The log directory (.mcp-data/) will be created automatically if it doesn't exist.
Add to your .vscode/mcp.json:
{
"servers": {
"mcp-confirm": {
"type": "stdio",
"command": "npx",
"args": ["@mako10k/mcp-confirm"]
}
}
}Add to your Claude Desktop config.json:
Location: %APPDATA%\Claude\config.json
Location: ~/Library/Application Support/Claude/config.json
Location: ~/.config/claude/config.json
{
"mcp": {
"servers": {
"mcp-confirm": {
"command": "npx",
"args": ["@mako10k/mcp-confirm"],
"env": {
"MCP_CONFIRM_LOG_PATH": "~/.mcp-data/confirmation_history.log",
"MCP_CONFIRM_TIMEOUT_MS": "60000",
"NODE_ENV": "production"
}
}
}
}
}// Before AI executes an action
await confirm_action({
action: "Delete files",
impact: "Cannot be restored",
details: "10 files will be deleted"
});// When request is ambiguous
await clarify_intent({
request_summary: "Want to create a project",
ambiguity: "Type of project unclear",
options: ["Node.js project", "Python project", "React app"]
});// Before complex tasks
await verify_understanding({
understanding: "Create web application with user authentication",
key_points: ["React + Node.js", "JWT authentication", "PostgreSQL database"],
next_steps: "Create project structure then implement auth system"
});Protocol: Model Context Protocol Elicitation
Language: TypeScript
Runtime: Node.js
SDK Version: @modelcontextprotocol/sdk ^1.0.0
This server implements true MCP Elicitation protocol:
Sends elicitation/create method to client
Defines user input structure with JSON Schema
User responds with accept, decline, or cancel
On accept, receives structured data following schema
This enables reliable communication between AI and users.
# Clone repository
git clone https://github.com/mako10k/mcp-confirm.git
cd mcp-confirm
# Install dependencies
npm install
# Build
npm run build
# Run locally
npm start
# Quality checks
npm run qualityMIT License - see LICENSE file for details.
Perform statistical analysis on confirmation history logs
| Name | Required | Description | Default |
|---|---|---|---|
| startDate | No | Start date for analysis (ISO 8601 format) | |
| endDate | No | End date for analysis (ISO 8601 format) | |
| groupBy | No | Group analysis by field | confirmationType |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action without behavioral details. It doesn't disclose whether this is a read-only operation, if it requires specific permissions, what the output format might be, or any rate limits, leaving significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a statistical analysis tool with no annotations and no output schema, the description is insufficient. It lacks details on what statistical methods are used, the format of results, or any constraints, making it incomplete for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-specific information beyond what the schema provides (100% coverage). It mentions 'confirmation history logs' but doesn't clarify how parameters like 'groupBy' relate to the analysis, so it meets the baseline for high schema coverage without adding extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('perform statistical analysis') and target resource ('confirmation history logs'), making the tool's purpose understandable. However, it doesn't differentiate from sibling tools like 'search_logs', which might also operate on logs but with different functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'search_logs' or other siblings. It lacks context about appropriate scenarios, prerequisites, or exclusions, leaving the agent with minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask a yes/no confirmation question to the user when the AI needs clarification or verification
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | The yes/no confirmation question to ask the user |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the tool's purpose and context but lacks details on behavioral traits such as how the user's response is handled, whether it blocks execution, or any error conditions. However, it does not contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key information ('Ask a yes/no confirmation question') and includes essential context without any wasted words. Every part of the sentence contributes to understanding the tool's use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is mostly complete. It covers purpose and usage context well, but lacks details on behavioral aspects like response handling or error cases, which could be beneficial for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'question' fully documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Ask a yes/no confirmation question') and the resource ('to the user'), with a precise purpose ('when the AI needs clarification or verification'). It distinguishes from siblings like 'clarify_intent' or 'confirm_action' by specifying the binary yes/no format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool: 'when the AI needs clarification or verification.' This provides clear context for usage, distinguishing it from alternatives like 'elicit_custom' or 'verify_understanding' by focusing on binary confirmation scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask user to clarify their intent when the request is ambiguous or could be interpreted multiple ways
| Name | Required | Description | Default |
|---|---|---|---|
| request_summary | Yes | Summary of what the AI understood from the user's request | |
| ambiguity | Yes | Description of what is unclear or ambiguous | |
| options | No | Possible interpretations or options for the user to choose from |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the tool's purpose (asking for clarification) but lacks details on behavioral traits such as how it interacts with the user (e.g., via UI prompts), whether it's idempotent, or any rate limits. The description is adequate but minimal for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key information (action and condition) with zero wasted words. It is appropriately sized for the tool's complexity and earns its place by clearly defining purpose and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is mostly complete. It covers purpose and usage well but lacks details on behavioral aspects like interaction flow or error handling. With no output schema, it doesn't need to explain return values, but could benefit from more context on how the tool operates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description does not add any parameter-specific information beyond what the schema provides (e.g., it doesn't explain how 'options' should be formatted or typical use cases for 'ambiguity'). Baseline 3 is appropriate when the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Ask user to clarify their intent') and the condition ('when the request is ambiguous or could be interpreted multiple ways'). It distinguishes this tool from siblings like 'ask_yes_no' or 'confirm_action' by focusing on intent clarification rather than binary confirmation or verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'when the request is ambiguous or could be interpreted multiple ways.' This provides clear context for usage versus alternatives like 'verify_understanding' (which might confirm rather than clarify) or 'elicit_custom' (which is more open-ended).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Collect user satisfaction rating for AI's response or help quality
| Name | Required | Description | Default |
|---|---|---|---|
| subject | Yes | What to rate (e.g., 'this response', 'my help with your task') | |
| description | No | Additional context for the rating request |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool collects ratings but doesn't explain how (e.g., scale, format), whether it's interactive or passive, what happens to the data, or any limitations (e.g., rate limits). This leaves key behavioral traits unspecified for a tool that likely involves user interaction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and appropriately sized, making it easy to parse quickly while conveying the essential action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (collecting user feedback, which may involve interaction and data handling), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like response format, error handling, or user experience implications, leaving gaps that could hinder effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting both parameters. The description doesn't add any meaning beyond the schema, such as examples of typical 'subject' values or how 'description' enhances the rating context. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('collect') and resource ('user satisfaction rating'), specifying it's for AI's response or help quality. However, it doesn't explicitly distinguish this from sibling tools like 'ask_yes_no' or 'elicit_custom', which might also involve user feedback collection, leaving some ambiguity about its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, timing (e.g., after an interaction), or differentiate from siblings like 'ask_yes_no' for binary feedback or 'elicit_custom' for open-ended input, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask user to confirm an action before proceeding with potentially impactful operations
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Description of the action to be confirmed | |
| impact | No | Potential impact or consequences of this action | |
| details | No | Additional details about what will happen |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool is for confirmation of 'potentially impactful operations,' hinting at safety or caution, but lacks details on how the confirmation is handled (e.g., user interaction flow, response format, or any side effects). For a tool with no annotations, this leaves significant gaps in understanding its behavior beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the tool's purpose and context. It is front-loaded with the core function and includes necessary qualifiers without redundancy. Every word earns its place, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a confirmation tool with 3 parameters) and the absence of annotations and output schema, the description provides a basic but incomplete picture. It covers the purpose and hints at usage context but lacks details on behavioral aspects, return values, or interaction specifics. This is adequate for a simple tool but leaves room for improvement in fully guiding an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear descriptions for all three parameters ('action', 'impact', 'details'). The description doesn't add any additional meaning beyond what the schema provides, such as examples or usage tips. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema adequately documents the parameters without extra value from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Ask user to confirm an action before proceeding with potentially impactful operations.' It specifies the verb ('ask to confirm') and the resource/context ('action'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'ask_yes_no' or 'verify_understanding', which might serve similar confirmation purposes, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('before proceeding with potentially impactful operations'), suggesting when to use this tool. However, it doesn't provide explicit guidance on when to choose this over alternatives like 'ask_yes_no' or 'verify_understanding', nor does it specify exclusions or prerequisites. The guidance is present but limited to a general implication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a custom confirmation dialog with specific schema when standard tools don't fit
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | Message to display to the user | |
| schema | Yes | JSON schema defining the structure of information to collect |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool creates a dialog but doesn't describe what happens after creation (e.g., how user responses are handled, whether it's blocking, or any permissions/rate limits). This leaves significant gaps for a tool that interacts with users.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and includes necessary context without redundancy, making it appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (user interaction with custom schema) and lack of annotations or output schema, the description is adequate but incomplete. It covers the basic purpose and usage context but misses behavioral details like response handling, which are crucial for effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('message' and 'schema'). The description adds minimal value by implying these parameters define the dialog's content and structure, but doesn't provide additional syntax, format details, or examples beyond what the schema offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and resource ('custom confirmation dialog with specific schema'), making the purpose understandable. It distinguishes from standard tools but doesn't explicitly differentiate from sibling tools like 'ask_yes_no' or 'confirm_action' which might also handle confirmations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('when standard tools don't fit'), which helps guide selection. However, it doesn't specify when NOT to use it or name explicit alternatives among the sibling tools, such as 'ask_yes_no' for simpler confirmations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search confirmation history logs with various filters and pagination
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | No | Search keyword in message content | |
| confirmationType | No | Filter by confirmation type (confirmation, rating, clarification, verification, yes_no, custom) | |
| startDate | No | Start date filter (ISO 8601 format) | |
| endDate | No | End date filter (ISO 8601 format) | |
| success | No | Filter by success status | |
| timedOut | No | Filter by timeout status | |
| minResponseTime | No | Minimum response time in milliseconds | |
| maxResponseTime | No | Maximum response time in milliseconds | |
| page | No | Page number for pagination (1-based) | |
| pageSize | No | Number of entries per page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions 'pagination', it doesn't describe the return format, what fields are included in search results, error conditions, rate limits, or authentication requirements. For a search tool with 10 parameters and no annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. Every word earns its place: 'Search' (verb), 'confirmation history logs' (resource), 'with various filters and pagination' (key capabilities). There's no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (10 parameters, no annotations, no output schema), the description is insufficiently complete. It doesn't explain what the search returns (e.g., log entries with specific fields), how results are ordered, error handling, or performance characteristics. For a search tool with rich filtering options, more context about the output and behavioral traits is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning all parameters are well-documented in the input schema itself. The description adds marginal value by mentioning 'various filters and pagination', which aligns with the schema parameters but doesn't provide additional syntax, format details, or usage examples beyond what's already in the schema descriptions. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search confirmation history logs with various filters and pagination'. It specifies the verb ('search'), resource ('confirmation history logs'), and scope ('with various filters and pagination'). However, it doesn't explicitly differentiate this search tool from sibling tools like 'analyze_logs', which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'analyze_logs' or explain the difference between searching logs and other confirmation-related tools (e.g., 'ask_yes_no', 'confirm_action'). There's no context about prerequisites, typical use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify that the AI correctly understood the user's requirements before proceeding
| Name | Required | Description | Default |
|---|---|---|---|
| understanding | Yes | AI's understanding of the user's request | |
| key_points | No | Key points that the AI wants to confirm | |
| next_steps | No | What the AI plans to do next if understanding is correct |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it indicates this is a verification step, it doesn't describe what happens after verification (e.g., does it return confirmation, trigger next steps, or require user response?), nor does it mention any constraints like rate limits or permission requirements for a tool that interacts with user understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized for a tool with clear parameters and no complex behavioral nuances needing explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns (e.g., confirmation object, user response, or next step trigger), nor does it address behavioral aspects like whether this blocks execution or how verification failures are handled, leaving critical gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds no additional meaning about parameters beyond what's in the schema, meeting the baseline expectation but not providing extra value like explaining how parameters interact or typical usage patterns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as verifying AI understanding of user requirements before proceeding, which is a specific verb-action combination. However, it doesn't differentiate from sibling tools like 'clarify_intent' or 'confirm_action' that might serve similar verification purposes, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'clarify_intent' or 'confirm_action'. It mentions 'before proceeding' which gives some temporal context, but offers no explicit when/when-not rules or comparison to sibling tools, leaving significant ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
analyze_logsask_yes_noclarify_intentcollect_ratingconfirm_actionelicit_customsearch_logsverify_understandingScored across 8 tools
Each tool has a clearly distinct purpose with no ambiguity. For example, ask_yes_no handles simple binary questions, clarify_intent addresses ambiguous requests, confirm_action verifies impactful operations, and verify_understanding checks comprehension—all serving different confirmation needs without overlap.
All tools follow a consistent verb_noun pattern with clear, descriptive names. Examples include analyze_logs, search_logs, collect_rating, and verify_understanding, maintaining uniformity throughout the set without any deviations in style or structure.
With 8 tools, the server is well-scoped for handling user confirmation and verification tasks. Each tool earns its place by covering distinct aspects like questioning, clarification, logging, and feedback, avoiding both bloat and insufficiency.
The tool set provides complete coverage for the confirmation domain, including standard confirmations (ask_yes_no, confirm_action), intent handling (clarify_intent, verify_understanding), feedback collection (collect_rating), logging (analyze_logs, search_logs), and customization (elicit_custom), with no apparent gaps.
MCP server for AI dialogue using various LLM models via AceDataCloud
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
Official MCP server for Agentwork — delegate tasks to AI agents with human-in-the-loop
Cloud-hosted MCP server for durable AI memory
