Skip to main content
Glama

Zusammenfassung des Betriebs

content_summary
Read-only

Kurzfassung: Betrieb, Leistungen mit öffentlichen Preisen, Gebiet, Öffnungszeiten, Kontakt, dazu die Seitenliste mit Abschnitts-Kennungen. Zuerst die Änderungsliste.

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": "content_summary"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior4/5

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

readOnlyHint=true already declares this is a safe read, so the lower bar applies; the description nonetheless adds real behavioral value by listing the exact payload contents and the ordering rule that the change list comes first. It omits caveats such as whether prices are filtered by visibility or how large the summary can get, which keeps it at a 4.

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?

Two compact sentences with heavy information density and no filler; the output inventory is front-loaded. The trailing ordering note ("Zuerst die Änderungsliste") would read better placed before the content list, but nothing is wasted.

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?

With no parameters, no output schema, and a read-only annotation, the description's job is mainly to explain the returned payload, which it does thoroughly by enumerating sections and the section-ID page list. The only real gap is sibling differentiation against the richer content_* tools, which keeps it from a 5.

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?

The tool takes no parameters and the schema is an empty object at 100% coverage, so the baseline is 4. The description correctly implies the call is argument-free by presenting all output as fixed sections.

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?

"Kurzfassung: Betrieb, Leistungen mit öffentlichen Preisen, Gebiet, Öffnungszeiten, Kontakt ... Seitenliste mit Abschnitts-Kennungen" names a specific resource (the business record) and enumerates exactly what the returned summary contains. It implicitly contrasts with content_full/content_section by being a condensed overview, but never names those siblings, keeping it short of a 5.

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?

There is no when-to-use or when-not-to-use guidance: nothing tells the agent to prefer this over content_full, content_section, or answer_question. "Zuerst die Änderungsliste" describes output ordering rather than invocation guidance, so the agent must infer the tool's role from its name alone.

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.

Resources