io.github.dfch/biz-dfch-asdste100mcp

Official

Overview Schema Source Related Servers Discussions Admin

rules_search

Read-only

Find ASD-STE100 rules by regular expression across all rule text, including notes, examples, and technical lists, to locate governing rules without needing section or category IDs.

Instructions

Full-text search for rules using a regular expression.

Unlike rules_match, which only looks at name and summary, this searches every text a rule carries: section, category, name, summary, and the data of every content item -- i.e. explanatory text, notes, STE/non-STE examples, technical noun/verb lists, and so on. Useful for finding "what rule governs passive voice" or "where does STE100 mention abbreviations", without knowing the section/category/id upfront.

Parameters

pattern: The regular expression pattern to search for (case-insensitive). content_types: When given, only the data of content items whose type is in this list is searched (section, category, name, and summary are always searched regardless). Use this to narrow the search to, e.g., only note or ste_example content. max_results: The maximum number of matching rules to return (default 25). offset: The number of matching rules to skip before returning results, for pagination (default 0).

Returns

SearchResult results holds the (possibly empty) page of matching rules, in document order, after applying offset and max_results. total is the full match count before pagination, and truncated tells the caller whether more matches exist beyond this page -- i.e. whether a reached max_results means "that's all of them" or "call again with a higher offset".

Input Schema

TableJSON Schema

Name	Required	Description
`offset`	No	The number of matching entries to skip before returning results, for pagination.
`pattern`	Yes	A regular-expression pattern (case-insensitive) matched against the rule section, category, name, summary, and every content block (text, notes, examples, technical noun/verb lists, ...).
`max_results`	No	The maximum number of matching entries to return.
`content_types`	No	Only search the content of these types, e.g. ['note', 'ste_example']. The rule section/category/name/summary are always searched regardless of this option.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`total`	Yes
`offset`	Yes
`results`	No
`truncated`	Yes
`max_results`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv3.0.0Sep 21, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only carry basic safety hints; the description supplies the operational behavior: regex case-insensitivity, exhaustive field coverage, content_types narrowing behavior, document-order pagination, and the meaning of truncated. An agent can predict exactly what a call returns and how paging works, with no contradiction of the readOnly/destructive hints.

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

Conciseness5/5

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

The description is longer than average but structured into What/Parameters/Returns and front-loaded with the primary purpose and sibling contrast before any detail. No sentence is filler; the examples earn their place by making the search scope concrete.

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?

Given the rich input schema, the provided output schema, and safety annotations, the description covers everything an agent needs to select and invoke this tool: scope, alternatives, parameter meanings, defaults, and pagination/truncation semantics. The Returns section is a bonus since an output schema exists, reinforcing correct usage.

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

Parameters3/5

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

The input schema already documents all four parameters at 100% coverage, including defaults, regex matching, and content_types behavior, so the description's parameter section mostly restates structured data. It adds only mild usage flavor, such as 'only note or ste_example' and pagination intent, which is not enough to raise it far above the schema baseline.

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?

The first sentence names the exact action and resource ('Full-text search for rules using a regular expression') and the second differentiates it from rules_match by enumerating the fields searched. The scope is explicit: section, category, name, summary, and all content item data.

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?

It explicitly contrasts with rules_match ('Unlike rules_match, which only looks at name and summary') and gives concrete use cases ('what rule governs passive voice' or 'where does STE100 mention abbreviations'). This tells an agent when the broader search is appropriate and when the sibling is the narrower alternative.

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

Deploy Server