constellation-mcp

by enternovate

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.0
Disambiguation5/5
All tools are cleanly separated by domain prefixes (mhangani_, gavaza_, nyarhi_) and each tool has a distinct purpose. Even similar operations like find vs search or report vs report are clearly differentiated by prefix and detailed descriptions, leaving no ambiguity.
Naming Consistency5/5
Every tool name follows a consistent lowercase snake_case pattern with a domain prefix and a verb or verb+noun structure (e.g., mhangani_audit, gavaza_breach_add, nyarhi_add_node). No mixed conventions or inconsistent verb styles are present.
Tool Count2/5
With 37 tools, the server is far beyond the typical well-scoped range of 3-15. While the tools are organized into three distinct domains, combining them makes the surface overly heavy and likely to overwhelm agents. Each domain would be better served as a separate server.
Completeness3/5
The audit and compliance domains have strong lifecycle coverage (authorize, audit, report, baseline, breach, requests, evidence). However, the knowledge graph domain lacks direct update and delete operations, relying only on undo, which is a notable gap for full graph management.
Average 3.6/5 across 37 of 37 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 12 commits in the last 12 weeks
- Last stable release on August 7, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation through the verb 'show', but with no annotations, it does not explicitly disclose behavioral traits such as whether it modifies data, pagination, or any rate limits. The basic intent is clear, but additional transparency is limited.
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 sentence with no fluff, making it highly concise. However, it is somewhat under-specified, so while it is concise, it could benefit from more detail.
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?
There is an output schema, so return values are likely covered, but the description lacks context about what 'posture score' refers to, how 'trend' is computed, and how it fits with sibling tools. The audit history scope is also unclear. For a tool in a larger suite, this is insufficient.
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?
The schema has one parameter 'limit' with no description, and the tool description does not mention it. Schema coverage is 0%, so the description adds no meaning beyond the parameter name, leaving the effect of 'limit' ambiguous.
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 'show' and identifies the resource 'posture score' and context 'audit history'. It clearly indicates the tool's function, but does not explicitly differentiate from mhangani_history, which might have overlapping functionality.
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?
No guidance is provided on when to use this tool versus alternatives like mhangani_report or mhangani_history. The description lacks any context about use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains parameter formats but omits critical details such as whether existing nodes are overwritten, whether the operation is atomic, what happens on duplicate IDs, or any authentication/authorization requirements. The 'store' parameter is mentioned but its semantics are left vague.
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 compact: a one-line purpose followed by a parameter-explaining sentence. The use of backticks and the explicit --prop syntax is efficient. It does not waste words, though a bulleted list might improve scanability. The overall size is appropriate for the information conveyed.
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?
Although an output schema exists (so return values need not be described), the tool is a mutating operation with no annotation coverage. The description fails to address behavior on duplicate node IDs, whether it updates or fails, the meaning of 'store file', or how props map to the JSON object expected by the schema. These gaps leave an agent under-informed for correct invocation.
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?
The description does explain all four parameters, including example node types and the syntax for props (--prop k=v pairs), which is valuable. However, it introduces a naming mismatch: it refers to 'node_type' while the schema defines the property as 'type'. This inconsistency could lead an agent to invoke the tool with the wrong parameter name, undermining the clarity of an otherwise useful explanation.
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?
The description begins with a clear, specific verb-resource pair: "Add a typed node to the knowledge graph." This unambiguously distinguishes it from sibling tools like nyarhi_add_edge and nyarhi_search, and the rest of the sentence clarifies the graph context.
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?
No guidance is given on when to use this tool versus alternatives. The description does not mention that adding an edge requires a separate tool, nor does it state prerequisites or conditions (e.g., node existence, uniqueness). The only implicit signal is the tool name itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It only states the core function and does not mention output format, error handling, side effects, or the effect of the 'store' parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word adds value, making it highly concise and easy to parse.
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?
For a tool with three parameters, an unexplained optional 'store', and no annotations, the one-sentence description is insufficient. The output schema exists but does not address the ambiguity around 'store' or usage context.
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?
Schema coverage is 0%, so the description must compensate. It maps 'start' and 'end' to 'two node ids', but leaves the optional 'store' parameter completely unexplained. This is only partial compensation.
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?
The description clearly states the tool finds the shortest path between two node ids, using a specific verb and resource. It distinguishes itself from sibling tools like nyarhi_find and nyarhi_neighbors by specifying the path-finding scope.
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 provides no guidance on when to use this tool over siblings such as nyarhi_neighbors or nyarhi_search. There are no alternatives, exclusions, or context cues to help an agent select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. The verb 'Print' implies a non-mutating operation, which is helpful, but the description does not explain the role of the 'store' parameter or any side effects. It also doesn't clarify whether statistics are global or scoped, though the parameter name suggests scoping.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that states the tool's purpose without extraneous text. It earns every word.
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?
While the output schema reduces the need to document return values, the description leaves a critical parameter unexplored and offers no usage guidance. For a tool with one optional parameter, the description should at least indicate what 'store' refers to, making this incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines one optional 'store' parameter with no description, and the tool description never mentions it. With schema description coverage at 0%, the parameter is completely unexplained, forcing the agent to guess its meaning.
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?
The description uses a specific verb 'Print' and identifies the resource as 'knowledge graph statistics' with explicit content (node/edge counts, types). This clearly differentiates it from sibling tools like nyarhi_add_node and nyarhi_find.
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 provides no explicit guidance on when to use this tool or when not to use alternatives. It does not mention any preconditions or comparisons with other report tools, leaving the agent to infer usage from the name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses that the file is 'hashed' and stored as a 'local copy', which is useful behavioral context. However, it does not mention whether the operation is reversible, requires permissions, or what happens to the checklist item, leaving some ambiguity for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It conveys the core action and an important behavioral detail ('hashed, local copy') efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (3 params, no nested objects), and an output schema exists, so return values are not needed. However, with no annotations and 0% schema coverage, the description should provide more details about the note parameter and usage context. It is adequate for basic invocation but leaves gaps in parameter semantics and guidelines.
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 indirectly explains 'file' (the evidence file) and 'item_id' (checklist item) through the phrase 'attach an evidence file to a checklist item', but it does not explain the 'note' parameter, which remains undocumented. The hashing/local copy detail adds meaning for the file parameter.
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 clearly states the verb 'attach' and resource 'evidence file to a checklist item', which distinguishes it from sibling tools like gavaza_evidence_list and gavaza_evidence_remove. It also adds context with 'hashed, local copy', but does not explicitly differentiate from alternatives.
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?
No explicit guidance on when to use this tool vs alternatives. The description implies usage through the action word 'attach', but there is no mention of prerequisites, exclusions, or comparison with siblings such as gavaza_evidence_list or gavaza_evidence_remove.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral details. It does mention that the copied file is also removed, which is a side effect, but it does not state whether the removal is permanent or reversible, whether any permissions are required, or whether the operation affects related data such as requests or reports. For a destructive tool, this lack of transparency is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and the affected resource without any unnecessary words. It is appropriately sized for a simple tool, delivering clear information in minimal space.
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?
For a destructive operation with no annotations, the description is too sparse. It does not explain return values, error conditions, or the permanence of the deletion. Although an output schema exists, the description should still provide context about consequences and any cascading effects. The description only covers the basic action and one side effect, leaving important contextual gaps.
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?
The input schema has zero description coverage for the single parameter evidence_id, and the description does not mention the parameter at all. It does not explain what evidence_id refers to, how to obtain it, or any constraints. The parameter name is somewhat self-explanatory, but the description adds no additional meaning beyond the bare schema definition, so it fails to compensate for the low coverage.
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?
The description uses the specific verb 'Remove' and clearly identifies the resource as 'an evidence entry and its copied file.' This distinguishes it from sibling tools like gavaza_evidence_add and gavaza_evidence_list, which handle creation and listing respectively.
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?
The description implies the tool is used to delete evidence entries, but it does not provide explicit when-to-use or when-not-to-use guidance. It also doesn't mention any prerequisites, such as the entry needing to exist, or indicate that alternatives like listing or adding might be more appropriate in other scenarios. The usage is implied by the action but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden of behavioral disclosure. It states that it adds an edge but does not reveal whether duplicate edges are allowed, whether the store is required/defaulted, how edge properties are handled, or what side effects occur on the underlying store. This is insufficient for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences. The first sentence states the primary purpose and the second compactly enumerates parameter roles. No redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has five parameters, no annotations, and an output schema. The description covers all parameters (with one naming error) and the core purpose, but lacks usage context, prerequisites, and behavioral details. Given the low complexity, it is minimally viable but with clear gaps.
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?
The description explains source/target as node IDs, props as key/value properties, store as an optional store file, and introduces edge_type as the relationship type. However, the schema property is actually named 'type', not 'edge_type', creating a naming mismatch that could lead an agent to use an invalid parameter. All parameters are at least mentioned, but the mismatch and vague store description only partially compensate for the 0% schema description coverage.
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?
The opening sentence 'Add a typed edge between two nodes' states a specific action (add), resource (typed edge), and context (between two nodes). It clearly distinguishes from sibling tools like nyarhi_add_node by targeting edges rather than nodes.
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?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites (e.g., source and target nodes must already exist). The only implied usage is the action itself. There are no explicit exclusions or recommended scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. The verb 'print' suggests a read-only operation, which is transparent, but the description does not explicitly state that it has no side effects, or provide any context about the graph's state or access requirements. It is not misleading but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It communicates the essential action and output format efficiently, fitting the tool's simple scope.
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?
Despite the low complexity (one optional parameter) and presence of an output schema, the description fails to explain the 'store' parameter or elaborate on what constitutes the 'active typed schema.' An agent cannot fully understand how to invoke the tool correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter ('store') with 0% description coverage, and the description does not mention or explain it. The agent is left without any guidance on what 'store' means or how to use it, which is a significant gap for a tool with a single parameter.
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?
The description uses a specific verb ('print') and clearly identifies the resource ('active typed schema of the graph') and output format (JSON). It distinguishes from siblings like nyarhi_find or gavaza_report, which serve different purposes.
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?
The description implies its usage (when you need to see the schema), but does not provide explicit when-to-use or when-not-to-use guidance, nor mention any alternatives. It is clear enough for a simple show tool but lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. It only states 'List all breaches' and does not mention return format, pagination, potential side effects, or access requirements. A read-only action is implied but not explicitly stated, and no other behavioral context is provided.
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, concise sentence with no unnecessary words. It clearly states the operation and resource. It is appropriately sized for a simple list tool, though it is slightly under-specified, so it does not earn a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description is minimally sufficient. However, it does not explain what 'register' refers to or provide any additional context about the tool's role in the broader workflow. It is adequate but leaves room for more detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, which sets a baseline of 4. The description adds a small amount of semantic context by specifying 'all breaches' and 'register', but since there are no parameters to document, the description does not need to compensate for missing parameter info.
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?
The description clearly states the tool's action ('List'), the resource ('breaches'), and the scope ('all' and 'in the register'). It distinguishes itself from sibling tools like gavaza_breach_add (which adds breaches) and other list tools by specifying the exact resource.
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 provides no explicit guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or comparisons to sibling tools like gavaza_requests_list or gavaza_evidence_list. The usage context is only implied by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions an output directory implying file creation, but does not disclose side effects, overwriting behavior, required permissions, or what happens during generation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences—and front-loads the purpose. Parameter details are compact and structured, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for a simple two-parameter tool, but it lacks context for selecting this over alternatives like gavaza_report or any behavioral caveats. An output schema exists, so return values are covered, but the overall guidance is minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fully compensates by explaining both parameters: 'docs' selects documents with a default of 'all', and 'out' specifies the output directory with a default. This adds clear meaning beyond the raw schema.
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 clearly states the tool generates POPIA compliance documents, which identifies the specific verb and resource. It does not explicitly differentiate from siblings like gavaza_report, but the purpose is unambiguous.
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?
No guidance is provided on when to use this tool versus the many sibling gavaza_* tools. It only covers parameter defaults, not usage context or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the output includes both nodes and edges, which is useful behavioral context. However, with no annotations provided, it does not explicitly state that this is a read-only operation, nor does it mention edge cases, pagination, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and scope. It contains no unnecessary words and is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and an output schema is present, so return-value documentation is not strictly required. Still, the description omits the optional `store` parameter semantics and any caveats about node non-existence or result limits, leaving a small but real gap in completeness.
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?
The description clarifies that `node_id` identifies the node whose neighbors are returned, adding meaning to that parameter. However, the `store` parameter is not mentioned at all, and schema description coverage is 0%, so the description only partially compensates for missing parameter semantics.
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?
The description uses the specific verb 'List' with the resource 'direct neighbors (nodes and edges)' scoped to `node_id`. This clearly distinguishes the tool from siblings like `nyarhi_path` or `nyarhi_search` by specifying the exact graph adjacency query.
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 alternatives. It only states what it does, without mentioning exclusions, prerequisites, or a preferred context such as 'use when you need a node's immediate connections'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. 'Print' suggests a read-only operation, and 'newest last' discloses ordering, but it does not explicitly state that it is non-mutating, mention permissions, or address potential large result sets.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence conveys the core action and output ordering with zero wasted words. It is an excellent example of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives a clear purpose for a simple read tool, and an output schema exists to document return values. However, it lacks parameter semantics, usage differentiation from siblings, and explicit safety context, leaving meaningful gaps for a tool with optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain the 'limit' or 'store' parameters. The names are somewhat self-explanatory, but no detail is provided on their format, behavior, or relationship to the tool's operation.
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?
The description uses the specific verb 'Print' with resource 'mutation timeline' and adds scope details ('every recorded change, newest last'). This clearly differentiates it from sibling tools by specifying the unique mutation-focused timeline.
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?
The description implies usage for viewing mutation history but provides no explicit guidance on when to use this tool over siblings like mhangani_history or mhangani_audit. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'reverse the mutation' without explaining side effects, irreversibility, permissions, or what happens to dependent data. This is a significant gap for a mutation-reversal tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy. It is front-loaded with the action verb 'reverse' and includes the essential parameter inline in code formatting. Every word earns its place.
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?
The tool has no annotations, and the description provides only the bare function. It does not explain how to obtain a sequence number, what qualifies as a mutation, or how undo interacts with the timeline/store. Even with an output schema, the description lacks critical context for safe and correct invocation.
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?
The description adds meaning to `seq` by calling it a 'timeline sequence number,' which goes beyond the schema's generic 'Seq' field. However, it does not explain the optional `store` parameter at all, and overall schema coverage is 0%. The partial explanation of the key parameter offsets the gap partially.
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?
The description uses a specific verb 'reverse' and identifies the resource as 'the mutation with timeline sequence number `seq`.' This clearly distinguishes it from sibling tools like nyarhi_add_node or nyarhi_timeline, making the purpose unambiguous.
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?
The description implies use for undoing a previous mutation, but it does not explicitly state when to use it, when not to use it, or reference alternatives. There's no guidance on exclusions or prerequisites, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only implies a read-only operation via 'List' and mentions the status filter, but does not address side effects, permissions, pagination, ordering, or default behavior when no filter is given. This is minimal for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb 'List', immediately conveying the core action. It is concise, contains no filler, and every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool, the description is adequate but minimal. It does not mention what happens when no status is provided (likely returns all requests), nor does it reference output schema content or any interaction with sibling request tools (e.g., gavaza_requests_status). Given the tool's low complexity and presence of an output schema, this is a minimum viable description but leaves some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only the parameter name 'status' with a string/null type and no description, so the schema description coverage is 0%. The description adds meaning by stating that the status optionally filters results, which is essential semantic information beyond the bare schema. It does not enumerate possible status values, but for a single optional parameter this is adequate.
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?
The description uses a specific verb ('List') with a clear resource ('data subject requests'), and the optional 'status' filter further specifies the scope. This distinguishes it from sibling tools like gavaza_breach_list or gavaza_evidence_list, which target different resource types.
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?
No guidance is provided about when to use this tool versus alternatives. The description does not mention exclusions, prerequisites, or why one would choose this over sibling list tools (e.g., gavaza_breach_list). The only usage hint is the verb 'List', which implies a read operation but lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates a mutating operation but does not disclose permanence, permission requirements, or effects on existing sessions. This is a significant gap for a destructive action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One clear sentence with no unnecessary words, easily digestible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one param and an output schema, so the description is mostly adequate, but the lack of any behavioral or prerequisite context for a removal operation leaves gaps.
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?
The single param url is only described as 'target host' in the description, adding some meaning beyond the bare schema name, but it does not clarify expected format or whether it's a hostname vs full URL. Given 0% schema coverage, more detail would be expected.
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?
The description specifies the action (remove) and the resource (authorization for a target host), clearly distinguishing it from sibling tools like mhangani_authorize (add) and mhangani_authorizations_list (list).
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?
The description implies the tool is for revoking a previously granted authorization, but it does not explicitly state when to use it over alternatives or mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'compare' but does not state whether the operation is read-only, whether it has side effects, requires the baseline to exist, or needs any permissions. This leaves uncertainty for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of eight words, front-loaded with the core action and object. It contains no filler or redundancy, making it highly concise while remaining informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters) and the presence of an output schema, the one-line description is minimally adequate. However, it omits any context about prerequisites (e.g., baseline must be set), when to use it, or behavioral notes, which would make it more complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so the description cannot add parameter details. The implicit inputs ('latest audit' and 'stored baseline') are clarified in the description, which adds a small layer of meaning beyond the trivial schema. Baseline of 4 applies for zero-parameter tools.
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?
The description uses a specific verb ('Compare') and names two clear resources ('latest audit' and 'stored baseline'), making the tool's function distinct from siblings like mhangani_baseline_set or mhangani_baseline_show. It is not a tautology and immediately identifies the operation.
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 provides no guidance on when to use this tool versus alternatives such as mhangani_report or mhangani_trend. It simply states the action without context, exclusions, or clear invocation conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. 'Print' indicates a read-like operation, but it does not explicitly state that there are no side effects, nor does it describe what the catalogue contains. It is adequate but lacks depth, relying on the output schema for return details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no fluff. It is front-loaded with the action and resource, earning a perfect score for conciseness.
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?
Given the tool's simplicity (zero parameters) and the presence of an output schema, the description is sufficient for basic understanding. However, it could have provided a bit more context about the nature of the 'check catalogue' or when to use it, so it is not a perfect 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (empty properties). Per guidelines, a baseline of 4 applies. The description adds no parameter details because none are needed.
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 clearly states the action ('Print') and the resource ('OWASP-aligned check catalogue'), making the tool's purpose understandable. It does not explicitly differentiate from sibling tools like mhangani_report, but the resource is specific enough to avoid major confusion.
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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, use cases, or exclusions. For a zero-parameter tool, a brief 'use this to view the checklist before an assessment' would have been helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the transparency burden. It adds useful context by stating the operation is 'read-only and sync-only' and that 'nothing leaves the machine,' which informs the agent about safety and privacy. However, 'read-only' is ambiguous given that an import would write to the graph, and it does not disclose whether existing graph data is overwritten or if the operation is idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with clear front-loading of the primary purpose and a compact second sentence adding behavioral context. Every word contributes; there is no redundancy or filler.
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?
Given the absence of annotations and parameter descriptions, the description is too thin for a 2-parameter import tool with no output schema details. It does not explain what 'home' and 'store' refer to, whether the graph is modified, or how this interacts with other nyarhi graph operations. The privacy note is helpful but leaves significant knowledge gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two parameters (home, store) with 0% description coverage, and the description does not explain their meaning or how they relate to 'local Xavani home data.' The names alone are insufficient for an agent to infer what values to provide, making parameter usage speculative.
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?
The description uses a specific verb ('import') and identifies both the source ('local Xavani home data') and destination ('into the graph'), clearly distinguishing this tool from sibling tools like nyarhi_add_node or nyarhi_search. It also specifies the data types (memories and sessions), which further clarifies its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool when you need to import local Xavani home data into the graph. It implies a specific use case and differentiates from other nyarhi tools by focusing on bulk import of home data, but it does not explicitly mention alternatives or exclusion criteria, so it lacks the 'when not to use' guidance found in top-tier examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It says 'Record explicit authorization' but does not disclose possible side effects, whether the action is reversible, or any permission requirements. It also does not explain what the output represents or whether the tool is idempotent. The description is too minimal for a write operation with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with each sentence adding distinct value: the first states the core function, the second provides essential usage timing. It is concise and front-loaded, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two parameters and an output schema. The description covers primary purpose and when to use, but lacks explanation of the 'note' parameter and any behavioral details such as whether previous authorizations are replaced. Given the output schema exists, return values need not be described, but other gaps lower the completeness.
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?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It indirectly hints that 'url' refers to the target host, but it does not explicitly map parameters or explain the purpose of the 'note' parameter. Given the low coverage, this is insufficient.
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?
The description clearly states the tool records explicit authorization for a target host, which is a specific verb+resource combination. It distinguishes itself from sibling tools like mhangani_audit and mhangani_report by focusing solely on the authorization step. The phrase 'Run this before auditing a host for the first time' adds context that it is a prerequisite action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Run this before auditing a host for the first time.' This clearly indicates the tool should be used as a precursor to auditing. However, it does not mention when not to use it or provide alternatives, so it falls short of a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. While 'Delete all' clearly indicates a destructive action, it fails to mention that the deletion is irreversible, whether it affects only audits/history or also other data like baselines and trends, or if any confirmation is required. This is a significant gap for a destructive tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action 'Delete all' and immediately specifies the target and location. It contains no unnecessary words or repetition, making it highly scannable.
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?
For a zero-parameter tool with an output schema, the description is largely complete: it states the operation and the data affected. However, it leaves ambiguity about whether 'audits and history' includes all data types (e.g., baselines), and it does not mention irreversibility, which would enhance completeness for a destructive command.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and the description clarifies the scope of the operation ('all stored audits and history in ~/.mhangani'), which is sufficient since there is nothing else to document. The baseline for 0 parameters is 4, and the description adds no conflicting or missing parameter information.
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?
The description uses the specific verb 'Delete' with a clear resource ('all stored audits and history') and location ('~/.mhangani'), making the tool's purpose unmistakable. It differentiates from sibling tools like mhangani_history and mhangani_report, which likely read or report rather than delete.
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?
There is no guidance on when to use this tool versus alternatives, no prerequisites, and no warning about when it should be avoided. The only implied usage comes from the imperative 'Delete,' but no explicit context or exclusions are provided, leaving agents to infer when this destructive action is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only covers filter mechanics and does not mention whether the tool is read-only, what side effects it might have, or what happens when no filters are supplied. This is a significant gap for a graph query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loaded with the main purpose. The parameter explanations are compact and each sentence earns its place. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all parameters but leaves ambiguity around the store parameter ('an optional store file' does not explain what a store is or what happens if omitted). It also doesn't clarify whether filters combine or what is returned by default. Given the tool's simplicity and the presence of an output schema, this is a clear but notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description fully compensates for the 0% schema coverage by explaining all three parameters: node_type (type), where with a k=v format and example (status=critical), and store as an optional file. This adds critical meaning beyond the bare parameter names. Minor naming mismatch (node_type vs type) is noted but does not undermine the clarity.
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 clearly states the tool finds nodes in the knowledge graph, which is a specific verb+resource. However, it does not explicitly distinguish this from sibling tools like nyarhi_search or nyarhi_neighbors, which also return nodes but in different ways.
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?
The description explains how to use the filters (node_type, where, store) but does not provide explicit guidance on when to use this tool rather than alternatives. The usage is implied through parameter semantics, not directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It does reveal that matching occurs against node ids, types, and property values and that results are ranked by relevance. However, it does not mention side effects, read-only status, or how the `store` parameter influences behavior, leaving notable transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose ('Full-text search over the graph's nodes') and immediately followed by relevant matching details. Every word earns its place; there is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/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 values need not be described. However, the description omits any account of the `store` parameter, which is likely important for proper invocation. It also does not address how this tool compares to siblings like nyarhi_find or nyarhi_neighbors, leaving a meaningful completeness gap for an otherwise simple tool.
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?
The input schema has zero property descriptions (0% coverage), so the description must compensate. It only explains `term` ('matched against node ids, types, and property values'), while `limit` and `store` are left undocumented in both schema and description. The `store` parameter is particularly opaque, and the description fails to clarify it despite the low schema coverage.
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?
The description opens with a specific verb and resource: 'Full-text search over the graph's nodes.' It further clarifies scope by listing matched elements (node ids, types, property values) and notes that results are relevance-ranked. This clearly distinguishes it from sibling tools like nyarhi_find or nyarhi_neighbors.
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?
The description implies its intended use case—text-based search across graph nodes—but does not explicitly contrast with sibling tools or state when to prefer this tool over alternatives like nyarhi_find. No exclusions or 'use instead' guidance is provided, so usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses an important behavior—that the JSON output from the CLI is passed through untouched—which indicates pass-through behavior for that format. However, it doesn't state whether the operation is read-only, whether authentication is needed, or any side effects, leaving significant behavioral details undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the purpose in the first sentence and adds a concise behavioral detail in the second. Every word earns its place.
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?
The tool is simple with one parameter and an output schema exists, so return-value details are unnecessary. The description covers the main behavior and format options. It could benefit from a note on when to use this vs sibling report tools, but the specific resource name helps complete the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides a string type with a default for 'format' and no property description (0% schema description coverage). The tool description compensates by explicitly listing the allowed values (JSON default, Markdown, HTML), which adds meaning beyond the schema and tells the agent what to pass.
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 clearly states the tool renders the POPIA assessment report in JSON, Markdown, or HTML, using the specific verb 'Render' and naming the exact resource. It does not explicitly compare to sibling report tools like mhangani_report, but the specific report name provides reasonable differentiation.
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?
The description implies the tool is for rendering the POPIA assessment report but gives no explicit guidance on when to use it over alternatives or when not to use it. It also doesn't mention any prerequisites for the report data, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior itself. It reveals that the tool lists sections and that slug filters to one section, which implies a read-only operation. However, it does not mention side effects, permissions, or output format, relying on the output schema for return details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The first sentence enumerates the sections for clarity, and the second explains the optional filtering. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with an output schema, the description covers the core function and filtering behavior. However, the absence of explicit slug value enumeration and usage guidance relative to siblings leaves the invocation potentially ambiguous, especially given no annotations.
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?
The schema provides no description for the 'slug' parameter, and the description explains that slug optionally prints only one section, which adds some meaning beyond the schema's string/null type. Yet it does not specify the accepted slug values or format, only listing section names in the main description.
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?
The description uses the specific verb 'List' and identifies the resource as 'additional POPIA sections', enumerating the exact categories. This clearly distinguishes it from sibling tools like gavaza_conditions or gavaza_gdpr_map, which serve different functions.
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?
The description implies usage for retrieving these specific POPIA sections but does not explicitly state when to use this tool versus alternatives like gavaza_conditions or mhangani_checklist. There is no exclusion or alternative mention, leaving the agent to infer from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a mutating action (setting/snapshotting a baseline) but does not state whether this overwrites the existing baseline, whether it is reversible, or if any special permissions are required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that conveys the core action without unnecessary words. It is immediately front-loaded with the verb 'snapshot' and clearly states the object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with zero parameters and has an output schema, so return values do not need explanation. However, the description omits important behavioral context such as whether the operation replaces the current baseline or requires any preconditions, making it minimally complete but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully defines the input surface; the baseline for 0 params is 4. The description does not need to add parameter-level meaning because there are no parameters.
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?
The description uses a specific verb, 'snapshot,' and a clear resource, 'the latest audit as the posture baseline.' It clearly distinguishes this setter tool from siblings like mhangani_baseline_show and mhangani_baseline_diff by indicating the baseline-establishing action.
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?
The description implies usage: you would call this to set the posture baseline from the most recent audit. However, it does not explicitly state when to use this tool versus alternatives like baseline_show or baseline_diff, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It discloses the source path (~/.mhangani) and ordering (newest first), but does not explicitly state that the operation is read-only, nor describe the output format or any side effects. The information is useful but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action, and includes only essential details (source and ordering). There is no redundancy or excessive length.
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?
For a simple listing tool with one optional parameter and an output schema, the description provides sufficient context regarding its purpose and data source. However, it omits any explanation of the 'limit' parameter, and given the sibling tool mhangani_audit, a note about when to use history versus running a new audit would enhance completeness.
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?
The schema has one parameter 'limit' with 0% description coverage, and the tool description does not mention the parameter at all. While 'limit' typically implies a maximum count, the lack of any explanation means the description adds no meaning beyond the schema's type and default.
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?
The description clearly states the tool's function: 'List previous audits stored in ~/.mhangani (newest first).' It specifies the verb (list), resource (previous audits), and source directory, distinguishing it from audit execution or reporting tools among siblings.
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?
The description implies usage for browsing past audits, but it does not explicitly state when to use this tool over alternatives like mhangani_report or mhangani_audit. No exclusions or alternative recommendations are provided, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the full burden. It only states the action 'list' and a filter, but does not clarify safety, return shape, or any limitations. Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 8 words, front-loaded with the verb and resource. No wasted words.
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?
Simple tool with one optional param and an output schema. The description covers the core function and filter, which is adequate for basic invocation; no mention of ordering or defaults but these are minor for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has one param 'item' with zero description. The description explains that it's an item id and that it's an optional filter, adding meaning beyond the bare schema.
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 'List recorded evidence' – a clear verb and resource. The phrase 'optionally filtered by item id' adds scope and distinguishes from evidence add/remove tools.
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?
No explicit when-to-use guidance or alternatives mentioned. The purpose is recognizable as the list/view tool within the gavaza_evidence family, so usage is implied but not contrasted with siblings like gavaza_evidence_add or gavaza_evidence_remove.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It adds the 30-day response deadline and enumerates valid `right` values, which is useful; however, it does not describe side effects, permissions, idempotency, or what is returned. The presence of an output schema covers return values, but broader behavioral disclosure is incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly scoped sentences deliver the core action, deadline, and the key parameter constraint. No filler or repetition; the enum values are cleanly separated in a code block.
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?
Given a moderate 4-parameter create operation with an output schema, the description covers the main purpose, deadline, and right-value constraint. It lacks explicit guidance on post-creation steps, but those are covered by sibling tools; overall it is sufficiently complete for selection and invocation.
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 defines the allowed values for `right`, which is critical, but leaves `name`, `email`, and `description` without any added meaning beyond their titles. This is adequate but leaves gaps for a fully self-contained parameter explanation.
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?
The description uses a specific verb-resource pair ('Log a data subject request') and adds a concrete deadline. Sibling tools like gavaza_requests_list and gavaza_requests_status clearly occupy different niches, so the creation intent is unambiguous.
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 implied by the verb 'Log' and the tool's 'new' suffix, but there is no explicit statement of when to use this tool vs. the list/status siblings. No alternatives or exclusions are mentioned, so the agent must infer context from names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses a write side effect ('Log a breach') and an output ('print the 72-hour checklist'), but it does not mention prerequisites, reversibility, error behavior, or permission needs, leaving partial compensation for the missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the core action, and uses a compact bullet-like list for parameter clarifications. Every sentence contributes and there is no fluff.
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?
The description covers purpose, parameter semantics, and the main behavior (logging and printing a checklist). Since an output schema exists, return-value details are not needed. However, it lacks context about what the 72-hour checklist is and any preconditions, which is a minor gap for an add tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description supplements schema by explaining that `description` is 'what happened', `date` uses ISO format and defaults to today, `categories` refers to 'personal information involved', and `risk` is an 'assessment'. This adds real meaning beyond raw types and defaults, though value formats for `risk` and `status` remain unspecified.
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?
The description opens with 'Log a breach in the register and print the 72-hour checklist', which is a specific verb+resource plus an additional outcome. It clearly distinguishes this add operation from the sibling 'gavaza_breach_list' and other list/report tools.
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 implied: the agent can infer that this tool is for logging breaches, but the description provides no explicit when-to-use or when-not-to-use guidance, nor does it name any alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'List' implies a read-only operation, but the description does not explicitly state any side effects, prerequisites, or return behavior beyond the output schema. It is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the action and object. Every word earns its place, and there is no redundant information.
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?
Given the tool's simplicity (0 parameters) and the presence of an output schema, the description is complete enough to convey the essential purpose. However, a brief note on when to use it would enhance completeness, but that gap is already covered under usage guidelines.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and the description correctly reflects that by not mentioning any. Since schema coverage is 100% (empty), the baseline of 4 applies; the description adds no parameter confusion.
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?
The description clearly states a specific verb ('List') and a precise resource ('the eight POPIA conditions and their compliance checklists'). This unambiguously identifies the tool's purpose and distinguishes it from siblings, as no other tool name contains 'conditions'.
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 implied: the description suggests using this tool when one needs POPIA conditions and their checklists. However, there is no explicit 'when to use vs alternatives' or exclusions, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. The verb 'print' conveys that the tool outputs a mapping table and does not modify data, but it does not explicitly state that it is read-only or describe side effects. For a simple display tool, this is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the action and resource. It contains zero unnecessary words and effectively communicates the tool's core function.
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?
Given the tool's simplicity (zero parameters, presence of an output schema), the description is sufficient to convey the tool's purpose and expected output. It could have added a note about being read-only, but that is implied by 'print'. Overall, the context is complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter meaning to explain. The schema is trivially complete with 100% coverage, and the description does not need to compensate for any undocumented fields. The baseline 4 for zero parameters is appropriate.
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?
The description uses a specific verb 'Print' and names the exact resource 'POPIA to GDPR mapping table'. This clearly distinguishes it from sibling tools like gavaza_assess or mhangani_report, which perform different actions. The purpose is unambiguous.
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?
The description implies the tool should be used when the user needs to see the POPIA to GDPR mapping table. However, it does not provide explicit guidance on when to use this tool over alternatives, nor does it mention any prerequisites or exclusions. The usage context is implied rather than explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses the allowed values for new_status, which is useful, but does not state side effects (e.g., overwriting, irreversibility), required permissions, or any result details. It is minimally adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action and immediately clarifying the only non-obvious parameter. Every word earns its place, no fillers 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?
For a simple two-parameter update tool, the description covers the core operation and parameter constraints. An output schema exists, so return values need no explanation. It lacks notes on permissions or side effects, but the simplicity and clarity of the tool reduce the need for more.
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 adds meaning for new_status by listing valid values (open, in_progress, completed, rejected), but request_id is left with only its name, which may be insufficient for users to know what identifier is expected (e.g., UUID vs integer). Partial compensation only.
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?
The description uses a specific verb ('Update') and resource ('data subject request'), clearly distinguishing this from sibling tools like gavaza_requests_new (create) and gavaza_requests_list (read). It precisely states the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: updating the status of an existing request. It implicitly contrasts with creation and listing siblings. It also constrains valid use by enumerating allowed statuses, providing practical guidance. No explicit exclusions or alternatives are named, but the intent is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the action 'List' and scope 'all recorded,' which implies a non-mutating operation, but it does not disclose any additional behavior such as whether the list is sorted, whether it includes revoked entries, or any access requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler, getting straight to the point.
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?
For a zero-parameter list tool with an output schema, the description adequately conveys the core operation. However, it leaves some contextual gaps (e.g., return format details, expected use cases) that are partly covered by the output schema, but a bit more elaboration on the scope would be useful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the schema provides full coverage trivially. The description doesn't need to explain any parameters, and the baseline for zero-parameter tools is acceptable.
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?
The description uses the specific verb 'List' with a clear resource 'all recorded authorizations,' making its function unmistakable. It naturally differentiates from sibling tools like mhangani_authorize (create) and mhangani_authorizations_remove (delete) by being the read/list operation.
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?
No explicit when-to-use guidance or alternative comparisons are provided. The use case is implied by the tool's name and straightforward list operation, but it does not tell the agent when to choose this over other list tools or mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of disclosing behavior. It adds a useful detail: 'The JSON output of the CLI is passed through untouched,' which indicates raw passthrough for JSON. However, it does not explain side effects, permissions, or what 'exec' format does, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the main action. Every phrase earns its place, with no filler or repetition. It is concise and well-structured.
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?
For a simple tool with one optional parameter and an output schema, the description covers the core behavior and default format. It lacks explicit usage guidance relative to siblings and does not explain 'exec', but the presence of an output schema reduces the need to describe return values. Overall, it is adequately complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only a 'format' property with no description (0% coverage). The description compensates by listing the possible values ('JSON (default), Markdown, HTML, or exec') and explicitly calling out the default. This adds significant meaning beyond the schema, though it does not elaborate on 'exec'.
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?
The description uses a specific verb and resource: 'Render the last audit', and enumerates the supported output formats (JSON, Markdown, HTML, exec). This clearly distinguishes the tool from sibling tools like mhangani_history or mhangani_trend, which focus on different aspects.
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?
The description implies the tool is for rendering the last audit, which provides clear context for use. However, it does not explicitly mention when to use this tool instead of alternatives, nor does it name any exclusions or competing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. 'Print' implies a read-only, non-destructive operation, which is transparent enough for a show command. However, it does not explicitly state that no modifications occur or describe any prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no superfluous words. It earns its place by stating exactly what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool with an output schema present, the description is sufficient. It clearly states the tool's action without needing to explain return values or parameters, as the output schema covers the response shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter details. The baseline of 4 applies because there is nothing to compensate for.
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?
The description 'Print the stored posture baseline' uses a specific verb (Print) and resource (posture baseline), clearly distinguishing it from sibling tools like mhangani_baseline_set and mhangani_baseline_diff.
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?
The description implies usage (when you want to view the baseline), but it does not explicitly state when to use this over alternatives or mention any exclusions. The implied usage is clear for such a simple read tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool writes a results JSON (via the `out` parameter) and that it reads an answers file, but it does not mention side effects, prerequisites, error behavior, or file-modification possibilities. It also doesn't clarify whether it mutates the input file. This partial disclosure earns a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and efficiently structured. It leads with the core purpose, then explains each parameter in separate backtick-delimited sections. Every sentence carries necessary information, with no fluff 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?
Given the tool's low complexity (two flat parameters, no nested objects) and the presence of an output schema, the description covers the essentials: what it does, the input format, and the output location. It omits contextual links to other tools (e.g., whether the questionnaire must be generated first), but this is not critical for this tool's operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 fully. It defines `answers` as a path to a JSON file mapping item ids to 'yes'|'no'|'partial' and explains that `out` overrides the output location. This adds substantial semantic meaning beyond the bare schema types, making both parameters understandable.
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?
The description opens with a clear, specific verb-resource pairing: 'Run the POPIA compliance questionnaire'. It clearly states the tool takes a JSON answers file, which distinguishes it from sibling tools like gavaza_generate (which likely generates the questionnaire) and gavaza_report (which reports on it).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: when you have a JSON answers file and want to execute the assessment. It does not explicitly name alternatives or exclusions, but the input format and purpose are clear enough that an agent can infer when to use it. A explicit comparison to gavaza_generate or gavaza_report would have warranted a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It reveals key behaviors: authorization is enforced ('CLI refuses'), allow_private defaults to false as a safety guard (implying private addresses are blocked by default), and respect_robots refuses disallowed paths. It does not describe the output format or side effects (e.g., history saving), but the provided behaviors go beyond a generic 'runs an audit.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The two-sentence structure is front-loaded with the action and then lists parameter behaviors in a clear, information-dense manner. Every sentence earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 params, authorization prerequisite), the description is complete. It covers the prerequisite, parameter semantics, and safety defaults. An output schema exists, so not describing return values is fine. It provides enough for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no property descriptions), yet the description explains every parameter: url, timeout (overrides per-check timeout), rate_delay (spaces HTTP requests), allow_private (permits private/internal addresses), and respect_robots (refuses robots.txt-disallowed paths). This fully compensates for the schema's lack of descriptions.
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?
The description starts with a clear, specific verb+resource: 'Run a web security audit against `url`.' This distinguishes it from sibling tools like mhangani_report (reports) and mhangani_authorize (authorization management), and the backticked `url` reinforces the primary input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states a prerequisite: the target must be authorized first via mhangani_authorize, and the CLI refuses without it. It also clarifies optional flags (allow_private, timeout, etc.) and their effects, giving clear context for usage. However, it does not explicitly mention alternatives or when not to use this tool, which would push it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![constellation-mcp MCP server](https://glama.ai/mcp/servers/enternovate/constellation-mcp/badges/card.svg)](https://glama.ai/mcp/servers/enternovate/constellation-mcp)

Score Badge

Copy to your README.md:

[![constellation-mcp MCP server](https://glama.ai/mcp/servers/enternovate/constellation-mcp/badges/score.svg)](https://glama.ai/mcp/servers/enternovate/constellation-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/enternovate/constellation-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server