actionlog
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| record_agent_actionB | Records an autonomous agent decision or tool execution with cryptographic integrity hash. |
| verify_log_integrityA | Audits sequential cryptographic checksums to ensure audit log has not been altered. |
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 2 tools
The two tools have completely distinct purposes: one appends an action to the log, the other verifies the log's integrity. There is no overlap or ambiguity in their intended usage.
Both tool names follow the same verb_noun pattern (record_agent_action, verify_log_integrity), are in snake_case, and clearly communicate the action and target. The naming is fully consistent.
With only two tools, the server feels thin even for a focused audit-logging purpose. While the count is not excessive, it falls at the low end where a single extra tool for retrieval would make the set feel more complete.
The server covers the core record and verify capabilities, but there is no way to read, list, or query the logged actions. This creates a notable gap: an agent can write and validate entries but cannot retrieve them for normal use.