Liefert den Volltext eines einzelnen Ratgebers als Klartext. — Returns the full plain text of one guide from getecoback.com so the answer can be written from the source and cited. Pass a path or URL from ratgeber_suche.
| Name | Required | Description | Default |
|---|---|---|---|
| pfad | Yes | Pfad oder vollständige URL, z. B. /guide/klimaanlage-kippfenster.html |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool returns full plain text and that it's from getecoback.com, which implies a read-only, non-destructive operation. However, it does not mention error behavior or the potential size of the text, leaving a minor gap in behavioral disclosure.
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 two short sentences, one in German and one in English. It is front-loaded with the core function and immediately explains usage and source. No wasted words; every sentence contributes to clarity.
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 one-parameter tool with no output schema or annotations, the description is complete: it states the return value (full plain text), the source (getecoback.com), and the input requirement (path/URL from ratgeber_suche). It sufficiently covers both input and output semantics.
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 coverage is 100%, so the baseline is 3. The description adds value by specifying that the path or URL should come from ratgeber_suche, providing source context beyond the schema's example. This helpful guidance raises the score to 4.
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 that the tool delivers the full plain text of a single guide, using the specific verb 'returns' and the resource 'full plain text of one guide' from getecoback.com. It distinguishes itself from sibling tools like ratgeber_suche by focusing on a single guide and explicitly referencing the search tool as the source of the path/URL.
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 instructs to pass a path or URL from ratgeber_suche, providing a clear prerequisite and context for when to use this tool. It also states the purpose: to write the answer from the source and cite it, effectively implicitly contrasting with the search tool that returns summaries or lists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct calculation or data source: subsidies, BTU sizing, seal length, heating power, heatwave forecast, running cost, guide search/read, and dew point. No two tools have overlapping purposes, so an agent can easily select the right one.
All tool names use lowercase with underscores and German terms, but the semantic pattern is slightly mixed: most follow 'topic_noun' (e.g., btu_empfehlung), while two are 'object_verb' (ratgeber_lesen, ratgeber_suche). This is a minor deviation from a fully uniform convention.
Nine tools is well within the optimal 3-15 range for a niche advice server. Each tool addresses a specific aspect of HVAC/energy guidance, and the inclusion of guide search/read does not make the set feel bloated.
The server covers the core domain well: cooling and heating sizing, running costs, window sealing, ventilation, and heatwave data. It lacks dedicated tools for dehumidifier sizing or AC comparison, but these topics are accessible through the guide search/read tools, so agents can work around the gaps.