Skip to main content
Glama

nexus_compare_live_state_with_declared_state

Read-onlyIdempotent

Compares live Nexus Repository state against a supplied declared configuration to detect drift and identify mismatches.

Instructions

Detect drift between live Nexus state and a provided declared state.

Input Schema

NameRequiredDescriptionDefault
declared_stateYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.9/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is supplied structurally. The description adds the useful distinction between live state and declared state, but does not explain what drift detection returns or any limits of the comparison; the output schema covers return values.

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?

The description is a single front-loaded sentence with no wasted wording. It is concise, though the brevity contributes to the missing usage and parameter details.

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

Completeness2/5

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

This is a read-only comparison tool with an open-world, nested input object and an output schema. The description does not explain the declared_state structure or how the agent should use the drift result, so it is not complete enough for the tool's complexity.

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

Parameters2/5

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

There is one required parameter, declared_state, with 0% schema description coverage and a nested arbitrary object. The description calls it 'a provided declared state' but does not explain its expected structure, format, or how it is compared to live state, so the semantic gap remains substantial.

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

Purpose4/5

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

The description uses a specific verb ('Detect') and resource ('drift between live Nexus state and a provided declared state'), which clearly identifies a comparison operation. It does not explicitly differentiate from sibling tools, but none of the named siblings appear to perform state comparison.

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

Usage Guidelines2/5

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

The description gives no guidance on when to use this tool versus the sibling tools, nor does it state prerequisites or exclusions. The comparison purpose is implied, but an agent must infer the appropriate context.

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