Evidrift
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": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| evidrift_recordA | Resolve an actually installed dependency and create a content-addressed Evidrift receipt. When affectedCodeLine points at an overloaded call, TypeScript selects the real call-site signature. The tool records evidence only; it never declares the receipt verified or the code correct. |
| evidrift_record_json_pointerA | Read one repository-local JSON file, resolve an RFC 6901 pointer, and create a content-addressed Evidrift receipt. No URL, command, package code, or LLM is invoked. |
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
Each tool targets a clearly distinct evidence source: one resolves an installed dependency call-site, the other reads a repository-local JSON file via RFC 6901 pointer. The descriptions are explicit about the different inputs, so there is no real ambiguity.
Both names follow the evidrift_record_ prefix with snake_case, but one is a bare verb ('evidrift_record') while the other includes a direct object ('evidrift_record_json_pointer'). The pattern is mostly consistent but slightly unbalanced, making the first name less descriptive.
With only two tools, the surface feels thin, though the narrow specialization of recording evidence from just these two sources could justify it. It is borderline but not extreme, so a middling score is appropriate.
The domain appears to be specific types of evidence recording, and the two tools cover the two stated cases well. The descriptions explicitly rule out other methods (URL, command, package code, LLM), suggesting the scope is intentional. Minor gaps in other potential evidence types are acceptable for this narrow purpose.