Single tool with basic definition but significant gaps in description quality and parameter documentation. The tool has an input schema with proper type, but the description is minimal (71 characters, below the 194-char baseline for production tools). No parameter-level description visible in the schema, the parameter 'input_text' relies solely on the docstring, not on JSON Schema metadata. No output schema is documented. The tool's risk is correctly marked READ_ONLY, but there is no error handling guidance or recovery instructions. This is a minimal template example, not a production-grade tool.

• Expand tool description to 100 - 250 characters. Include: what the tool does ('echoes back the provided input text'), when to use it ('when you need to verify text processing or validate input'), and what it returns ('the processed text with a "Processed: " prefix'). Example: 'Echoes the provided input text with a "Processed: " prefix. Use this when you need to verify text processing. Returns the echoed string.'
• Rename 'example_tool' to a more descriptive verb_noun pattern, e.g., 'echo_text' or 'transform_text_echo'. This makes the intent clear to LLMs without reading the full description.
• Document the output schema in the docstring. Specify: 'Returns: str, the input text prefixed with "Processed: ".'
• Add parameter constraints to the description: 'input_text (str): The text to process and return. Max 10,000 characters. Must be valid UTF-8.'
• Add error handling: document that the tool will return an error if input exceeds the size limit or contains invalid characters, and suggest the LLM should truncate or re-encode the input.
• Create a non-example tool (remove or rename the example_tool so it is not auto-discovered in production). The template should guide users to copy and rename, not to leave example_tool registered.