Skip to main content
Glama

Search seminars

seminars_search
Read-onlyIdempotent

Finds seminars in the IT-Schulungen.com catalogue.

Use this first when a topic is known but the seminar identifier is not. The search is semantic and covers the whole seminar text, so describe the goal in the customer's own words -- "wie sichere ich unsere Container-Umgebung ab" finds Docker and Kubernetes security seminars that share no word with the question. A keyword list works worse than a sentence. Results come back by relevance.

Two operators exist: a phrase in double quotes, and a term prefixed with a minus sign to exclude it. Either one turns the search back into a keyword match, so use them only to correct a search that went wide.

Each record carries topics, the subjects the seminar is tagged with -- use them to say why a seminar fits and to tell close candidates apart.

Each record also carries prices, one per delivery form: the amount and what it is per, nothing more. What is included and what costs extra -- an exam voucher, catering on site -- comes only from seminar_get, so call it before stating what a seminar costs in total; until then say "from". All amounts are net, plus VAT. When the delivery form is not known, lead with the open seminar, priced per participant; name the in-house price per day only when a team or company is asking or there is no open seminar, and coaching or a subscription only when asked. A price without an amount is price on request, and so is a seminar without prices.

Returns a compact record per seminar, each with url: the page on IT-Schulungen.com. Enquiries and bookings do not run through this server, so that link is where a customer has to go -- name it whenever a seminar is recommended, exactly as returned: its query string is part of the link. Call seminar_get with a guid from this list for the agenda and prerequisites, and seminar_dates for scheduled dates.

Input Schema

NameRequiredDescriptionDefault
pageNoPage number, starting at 1
limitNoRecords per page, 1-50, default 20
queryYesWhat the seminar should be about, at least 2 characters
topicNoExact topic name or identifier from `seminar_topics`
languageNoTwo-letter language code (ISO 639-1), e.g. "de" or "en"
difficultyNoDifficulty identifier from `seminar_difficulties`

Output Schema

NameRequiredDescriptionDefault
noteNo
pageYes
itemsYes
totalNo
has_moreYes
returnedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Well beyond the annotations: it discloses that matching is semantic over the whole text, that results come by relevance, that the query string of the returned url must be preserved, that all prices are net plus VAT, and that a missing amount means price on request. The annotations already cover the read-only/idempotent safety profile, and no behavior contradicts them.

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

Conciseness3/5

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

Front-loaded with the core rule, but the pricing passage is long relative to a search tool and reads as shared guidance rather than search-specific instruction; it dilutes the search mechanics an agent needs at call time.

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?

Despite an existing output schema, it explains the fields that change agent behavior (topics for justification, prices with their per-unit meaning, url that must be surfaced verbatim) and points to seminar_get for what is included in the price. Nothing needed to invoke or interpret a 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%, so baseline is 3; the description earns above that by teaching how to phrase `query` (a goal in the customer's own words beats a keyword list) and by explaining the effect of quoted phrases and minus-prefixed exclusions, which the schema does not. `topic`, `language`, `difficulty`, `page` and `limit` are left to the schema.

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 concrete verb and resource ("Finds seminars in the IT-Schulungen.com catalogue") and explicitly positions itself as the entry point when a topic is known but the identifier is not, which cleanly separates it from seminar_get and seminar_dates.

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

Usage Guidelines5/5

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

Explicit "use this first" routing rule, plus named downstream alternatives: call seminar_get with a guid for agenda and prerequisites, seminar_dates for scheduled dates. It also states when to use the quote/minus operators (only to correct a search that went wide), which is when-to-use guidance at the operator level.

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