Skip to main content
Glama
Sign In
example-mcp

example-mcp

by scalably-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

example_echo

Read-only

Send text to receive the same text in return, verifying the MCP server accepts and responds to requests.

Instructions

Return the text you pass in. Replace with real tools.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "text": "<text>"
    },
    "name": "example_echo"
  }
}

Input Schema

NameRequiredDescriptionDefault
textYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

C2.5/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true, and the description only restates the basic read-and-return behavior without adding contextual detail such as formatting, limits, or error cases. The placeholder text adds noise rather than behavioral transparency.

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

Conciseness2/5

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

The first sentence is concise and front-loaded. The second sentence, 'Replace with real tools.', is placeholder metadata that does not belong in a production description and should be removed, lowering the structure quality.

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?

For a one-parameter read-only echo tool, the core behavior is described, but the explicit 'Replace with real tools' instruction signals that this is not a real or final tool, undermining the reliability of the definition. No additional context about usage or behavior is provided.

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 0%, but the description clarifies that the only parameter, 'text', is the content to be returned. This minimally compensates for the missing schema documentation, though it provides no additional detail about constraints or expected formatting.

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 states a specific verb ('Return') and a clear resource ('the text you pass in'), which matches the tool's echo behavior and its title. However, the appended instruction 'Replace with real tools' muddles the purpose and suggests this is a placeholder, preventing a top score.

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

Usage Guidelines1/5

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

There is no guidance on when to use this tool versus alternatives, and no sibling tools exist. The phrase 'Replace with real tools' actively misleads an agent by implying this tool should not be used at all.

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

Deploy Server

Other Tools