Skip to main content
Glama
Sign In
JEFF7712

nix-agent

by JEFF7712
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

eval_config

Evaluate an attribute's final merged value in your actual NixOS or Home Manager configuration with nix eval; batch attributes and get per-attribute results.

Instructions

Evaluate the final merged value of an attribute in the user's actual NixOS/Home Manager configuration via nix eval (e.g. attr='services.openssh.enable'). flake_uri and mode auto-resolve when omitted. Pass a list of attrs to batch several evals into one call, returning per-attr results and failed_count / succeeded_count. Mixed results have status='partial', all failed have status='failed'. Values above the size guard degrade to attr names / length / a head slice (truncated: true). Text fallback and truncation include a hint to request narrower leaf attributes.

Input Schema

NameRequiredDescriptionDefault
attrYes
modeNonixos
flake_uriNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.7.2
    • addedInput schema / properties / attr / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  }
+]
    • removedInput schema / properties / attr / type
      Removed value: -"string"
  2. Addedv0.5.0

TDQS

A3.9/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and discloses substantial behavior: flake_uri/mode auto-resolution, batching multiple attrs into one call, per-attr results with failed_count/succeeded_count, status='partial'/'failed' semantics, and truncation via a size guard (truncated: true with a hint). It still omits cost/latency of `nix eval`, and read-only status is only implied.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action and an example, then a compact sequence of behavioral facts (batching, status, truncation). Dense but every sentence adds an actionable detail; no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-shape explanation is optional, yet the description still covers batch result fields, partial/failed status, and truncation — good coverage for a batch-capable eval tool. The remaining gap is the unexplained `mode` parameter and the absence of any guidance about evaluation cost.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It does explain that `attr` accepts a single string or a list (batch), and that `flake_uri` and `mode` auto-resolve when omitted, which is meaningful beyond the schema. However, it never says what `mode` values mean (nixos vs. home-manager or similar), leaving one of three parameters semantically opaque.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb + resource: evaluate the final merged value of an attribute in the user's actual NixOS/Home Manager config via `nix eval`, with a concrete example (attr='services.openssh.enable'). This clearly distinguishes it from siblings like `locate_option` (find an option) or `check`/`build`/`switch` (act on the system).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: 'the user's actual ... configuration' suggests reading real merged state, but there is no explicit when-to-use vs. when-to-use-an-alternative guidance (e.g. use this instead of locate_option to see the resolved value). No exclusions or prerequisites are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools