Skip to main content
Glama
NimbleBrainInc

MCP Echo Service

echo_message

Echo back messages with optional uppercase formatting to test MCP protocol functionality and verify communication channels.

Instructions

Echo back a message with optional formatting.

Args: message: The message to echo back uppercase: Whether to convert the message to uppercase ctx: MCP context

Returns: Complete echo response with metadata

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
messageYes
uppercaseNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
timestampYesISO 8601 timestamp of the echo operation
echoed_messageYesThe echoed message (possibly transformed)
message_lengthYesLength of the original message
original_messageYesThe original message sent
uppercase_appliedYesWhether uppercase transformation was applied

Implementation Reference

  • The main handler function for the `echo_message` tool.
    async def echo_message(
        message: str, uppercase: bool = False, ctx: Context | None = None
    ) -> EchoMessageResponse:
        """Echo back a message with optional formatting.
    
        Args:
            message: The message to echo back
            uppercase: Whether to convert the message to uppercase
            ctx: MCP context
    
        Returns:
            Complete echo response with metadata
        """
        if ctx:
            await ctx.info(f"Echoing message (uppercase={uppercase}): {message[:50]}...")
    
        result_message = message.upper() if uppercase else message
    
        return EchoMessageResponse(
            original_message=message,
            echoed_message=result_message,
            uppercase_applied=uppercase,
            message_length=len(message),
            timestamp=datetime.now(UTC).isoformat(),
        )
  • Registration of the `echo_message` tool using the `@mcp.tool()` decorator.
    @mcp.tool()
  • Response schema definition for the `echo_message` tool.
    class EchoMessageResponse(BaseModel):
        """Response model for echo_message tool."""
    
        original_message: str = Field(..., description="The original message sent")
        echoed_message: str = Field(..., description="The echoed message (possibly transformed)")
Behavior3/5

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

Without annotations, the description carries the full burden. It discloses the transformation behavior ('convert the message to uppercase') and hints at output structure ('metadata'). However, it lacks safety disclosures (read-only vs. destructive), performance characteristics, or rate limit warnings typical for even simple utility tools.

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

Conciseness3/5

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

Uses a Python-docstring format (Args/Returns) which is unconventional for MCP tool descriptions. While structured, this format consumes space on metadata already covered by the schema's existence (output schema is present). The first sentence is appropriately front-loaded, but the 'Returns' section is redundant with the output schema.

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?

Adequate for a low-complexity tool (2 primitive parameters, no nested objects). Given that an output schema exists, the brief mention of 'metadata' in the Returns section is sufficient context without requiring detailed value documentation. The description covers the essential transformation logic needed to invoke the tool correctly.

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 0% (no property descriptions), requiring the description to compensate. It successfully adds semantic meaning for 'message' and 'uppercase' parameters. However, it confusingly lists 'ctx: MCP context' in the Args section despite this parameter not existing in the input schema, which could mislead the agent about required inputs.

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?

States a specific action ('Echo back') and resource ('message') clearly. However, it fails to distinguish from sibling tools 'echo_json' and 'echo_with_delay'—it does not clarify that this is for string messages while echo_json handles structured data, or that this is immediate while echo_with_delay introduces latency.

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?

Provides no guidance on when to select this tool versus 'echo_json' or 'echo_with_delay'. No conditions, prerequisites, or exclusions are mentioned. The agent must infer usage solely from the tool name.

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

Install Server

Other Tools

Latest Blog Posts

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/NimbleBrainInc/mcp-echo'

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