Nearby Notices
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| NN_MODEL | No | The model to use for generating plain-English versions. With a local OpenAI-compatible server (llama-server, Ollama) leave this unset and the served model's name is read from the server at startup, so the name recorded with each plain-English version is the model actually used. | |
| NN_DAILY_CALL_CAP | No | A lower daily model-call cap, used for public-endpoint settings. | |
| NN_SEARCHES_PER_MINUTE | No | A per-client searches-per-minute limit, used for public-endpoint settings. Keeps no addresses. |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| find_notices_nearA | Find public notices near a UK postcode or town. |
| read_noticeA | Read one notice by id (from find_notices_near): the notice as published, word for word, and a plain-English version: what is changing, the places affected, the authority, from when and until when, the kind of notice, the notice's own sentence on how to object (quoted, never composed), and a short summary in which every sentence was checked against the notice; sentences that failed the check were removed and are counted. If the version is not ready it is made now, which can take a minute. Always cite the url. |
| coverageA | What this server covers and refuses, and the data licence and privacy terms. Call this before answering questions about what kinds of notice can be found here. |
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 3 tools
The three tools serve clearly distinct roles: coverage is a meta-information tool, find_notices_near searches by place, and read_notice retrieves a specific notice by id. There is no overlap in purpose or expected inputs, and the descriptions explicitly tell the agent when to use each.
The action-oriented tools use a consistent snake_case verb_noun pattern (find_notices_near, read_notice). The meta tool 'coverage' deviates by being a bare noun rather than a verb phrase, which is a minor inconsistency but still readable and clear.
Three tools are exactly right for a focused notice discovery and reading server: one explains scope and terms, one searches nearby, and one reads a full notice. No tool feels redundant or missing from the core workflow.
The surface covers scope, nearby search, and detail retrieval, but find_notices_near is capped at 12 newest results with no pagination and no filtering by notice kind, date, or authority. These are notable gaps for an agent that needs to browse beyond the most recent dozen notices.