Skip to main content
Glama

Search TransformPipe documentation

tp_search_documentation
Read-onlyIdempotent

Searches TransformPipe's documentation and returns the matching sections as text: the Markdown it supports, how files are handled, what is stored, how sharing works, the limits and the HTTP API. Use it when the user asks how TransformPipe works, what it supports or what its limits are. With question, it returns the sections that match; without arguments, it returns every section.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "tp_search_documentation"
  }
}

Input Schema

NameRequiredDescriptionDefault
questionNoThe user's question or keywords, matched against the documentation.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds value on top: the return type is text sections, and critically it discloses the two operating modes — filtered results with `question`, full dump of every section without arguments — which an agent cannot infer from the annotations.

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?

Three sentences, front-loaded with the core action and return format before the usage trigger and the argument behavior. The topic enumeration is slightly listy, but each item maps to a plausible user question, so it does real routing work rather than padding.

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

Completeness5/5

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

For a one-optional-parameter, read-only lookup with no output schema, the description covers action, return format, both invocation modes, and a content inventory. Nothing an agent needs in order to call it and interpret the result is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single parameter is already documented, so the baseline is 3. The description earns the bump by explaining what omitting the optional `question` does ("without arguments, it returns every section"), turning an empty optional field into a deliberate all-sections retrieval mode rather than a no-op.

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?

States a specific verb and resource ("Searches TransformPipe's documentation and returns the matching sections as text") and then enumerates the covered domains: Markdown support, file handling, storage, sharing, limits, HTTP API. This is unmistakably distinct from every sibling tool, which all operate on user documents rather than product documentation.

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

Usage Guidelines4/5

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

"Use it when the user asks how TransformPipe works, what it supports or what its limits are" gives an explicit trigger condition keyed to user intent. It also implicitly routes by content type (documentation vs. the document CRUD/convert siblings). It stops short of naming an alternative tool or stating when not to use it, so it falls short of a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.