A collection of example MCP servers demonstrating various use cases including bill searching, company registration lookups, funding discovery, innovation proposals, and smart lighting control.
This is a collection of 8 example MCP servers, each implementing read-only lookups or smart-home control. Tool naming is mostly verb-first and clear (find_*, get_*, set_*, turn_off). Descriptions are present but vary in depth, most are 50 - 150 chars, adequately explaining the tool's purpose. However, parameter descriptions are inconsistent: some params like 'articleNumbers', 'fundingType', and 'targetAudience' have good descriptions; others like 'page' and 'sort' are minimal. Input schemas are visible and properly typed (string, number, array), but output schemas are NOT documented, critical omission for LLM understanding. No error handling guidance visible. Tool #1 - #6 are read-only and well-scoped; tools #7 - #8 (Philips Hue control) are WRITE operations but lack idempotency hints, confirmation patterns, or destructive-operation warnings. This is a teaching/example repo, not production-grade, but the foundation is solid.
Find articles in the Austrian Criminal Code (STGB) by their article numbers
Search for articles in the Austrian Criminal Code (STGB) by text query, returns up to 5 matching articles
Search for companies in the Austrian corporate register by name or part of name
Search for climate action funding opportunities from klimaaktiv by filtering on type, target audience, and state
Search for innovation proposals from the Linz Innovation Square (Innovationshauptplatz) by filtering on status and sort order
Get detailed company information from the Austrian corporate register by corporate register number
Output schemas are completely undocumented. LLMs cannot plan downstream tool calls or extract structured data without knowing what fields are returned. Critical for agent reasoning.
Destructive operations (set_light, turn_off) lack idempotentHint, destructiveHint annotations or confirmation patterns. Agents cannot distinguish safe retries from irreversible side effects.
No error handling guidance. Tools return success/failure but do not tell LLM what to do next (retry, ask user, recover). Exception: find_articles_by_query documents it returns 'up to 5' results, which is good pagination guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 44 | - | v1 |
Set the brightness and color of a Philips Hue light bulb
Turn off a Philips Hue light bulb
Parameter 'page' (in find_funding, find_proposal) lacks minimum/maximum bounds and starting index clarification. 'First page is number 1' is helpful, but no upper bound documented. LLMs may pass unbounded page numbers.
Enum parameters (fundingType, targetAudience, state, status, sort) are well-documented with possible values inline in descriptions, which is good. However, they are NOT declared as JSON Schema enums, LLMs must parse text to discover valid options.
Parameter 'color' in set_light accepts freeform input (web color names OR hex). No validation documented; LLMs may hallucinate invalid colors. Needs clear constraint: 'One of: red, blue, green, ... OR hex #RRGGBB.'