gijon-avisos-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_identityA | Devuelve la identidad guardada (email, idioma) o null si aún no se preguntó. |
| set_identityB | Guarda el email del comunicante (se pregunta UNA vez y se reutiliza; es la identidad del aviso). |
| list_categoriesB | Tipos de incidencia (ALU, VIA, SEM, SEN, VER). Sin auth. |
| get_categoryC | Detalle de un tipo (código y nombre). |
| suggest_categoriesC | Sugiere tipos por palabras (p.ej. 'farola apagada'). |
| create_avisoA | Crea un aviso. IMPORTANTE: por defecto es DRY-RUN (confirm=false) y solo devuelve los campos que se enviarían, SIN crear nada. Para crear de verdad hay que pasar confirm=true. Usa el email guardado salvo 'identity'. |
| create_aviso_from_photoA | Aviso desde una FOTO en fases. VÍA PREFERIDA: sube la foto con PUT /upload (curl) y pasa file_id; por stdio usa image_path local. Sin tipo → sugiere (need_category). Con todo → preview + preview_token SIN enviar. Envío: MISMOS campos + confirm:true + human_confirmed:true + preview_token (tras 'sí' humano). Sin las tres NO se envía. La foto viaja en el mismo envío (data URL). |
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 7 tools
Identity (get/set), category (list/get/suggest), and creation (aviso/photo) tools are largely distinct. Minor overlap exists between create_aviso and create_aviso_from_photo (both create reports, differentiated only by photo input) and between list_categories and suggest_categories (both surface types, one filtered).
All seven tools follow a consistent snake_case verb_noun pattern (get_identity, set_identity, list_categories, get_category, suggest_categories, create_aviso, create_aviso_from_photo). No mixing of conventions or vague verbs.
Seven tools is well-scoped for a municipal incident-reporting client, with each tool earning its place (identity, category lookup, and two creation paths). No redundancy or filler.
The surface covers identity, category discovery, and report creation (text and photo), but offers no way to list, get, or track previously submitted avisos, nor to update/withdraw them. This creates a dead end for verifying report status, a notable gap for a reporting domain.