xonta-gate
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PUBLIC_URL | Yes | Public base URL of the server, used for did:web identifiers (e.g. http://localhost:4040) | |
| ADMIN_TOKEN | Yes | Admin token used to authorize administrative endpoints and registration | |
| AGENT_MODEL | No | Model name used by the agent (e.g. GigaChat-2) | |
| LLM_PROVIDER | No | LLM provider used by the agent/orchestrator runs (e.g. gigachat) | |
| OWNER_HMAC_SECRET | No | Secret used to compute the HMAC fingerprint of owner identifiers (the owner identifier itself is not stored) | |
| ALLOW_PRIVATE_TARGETS | No | Set to 1 to allow outgoing requests to http and local addresses — development only | 0 |
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| read_noteC | Reads a note by id. |
| delete_noteC | Deletes a note. |
| fetch_pageC | Fetches a web page. |
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
read_note and delete_note are cleanly separated by action on the same resource, and fetch_page is clearly a different target (web content). The only mild ambiguity is whether fetch_page is meant to retrieve note sources or arbitrary URLs, which could be confused with read_note in a note-centric workflow.
All three tools use a consistent snake_case verb_noun pattern: read_note, delete_note, fetch_page. The read/fetch verb split is a minor stylistic choice but does not break the predictable pattern.
Three tools is on the thin side for what appears to be a note-management server, and one of them (fetch_page) sits outside that domain. It is not an extreme mismatch, but the surface feels under-scoped.
The note surface has read and delete but no create, update, or list operation, leaving obvious dead ends for any write workflow. fetch_page adds a capability but does not fill the gaps in the core note lifecycle.