Berlin-Search-Service
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| XBY_APIKEY | Yes | 你的实际apikey (Your actual API key) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_servicesC | Search for Berlin administrative services by name or description. Returns a list of matching services with basic information. |
| get_service_detailsB | Get detailed information about a specific Berlin service by its ID. Returns comprehensive information including requirements, forms, fees, appointments, and more. |
| list_servicesB | List all available Berlin administrative services. Returns a paginated list of services with their names and IDs. |
| get_services_statsA | Get statistics about the Berlin services dataset (total count, last update, etc.) |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool has a clearly distinct purpose: get_service_details retrieves comprehensive data for a specific service, get_services_stats provides dataset-level statistics, list_services returns a paginated catalog, and search_services enables keyword-based filtering. There is no overlap in functionality, making tool selection straightforward for an agent.
All tool names follow a consistent verb_noun pattern with snake_case (e.g., get_service_details, list_services). The verbs (get, list, search) are appropriate and predictable, and there are no deviations in naming conventions across the set.
With 4 tools, the server is well-scoped for its purpose of searching and retrieving Berlin administrative services. Each tool earns its place by covering distinct aspects of the domain without being overly sparse or bloated, aligning with typical expectations for a focused service.
The tool set provides strong coverage for querying and retrieving service information, including listing, searching, getting details, and accessing statistics. A minor gap exists in the lack of update or management tools (e.g., create_service, update_service), but this is reasonable if the server is read-only, and agents can still perform core lookup workflows effectively.