Skip to main content
Glama

ensure_all_relationships_in_views

Idempotent

Creates or reuses a coverage view to ensure every model relationship is rendered in at least one view, fixing unused relation warnings from Archi Validator.

Instructions

Ensure every model relationship is rendered in at least one view.

Useful when Archi Validator reports `Unused Relation` or
`'Serving relation' is not used in a View`. The tool creates or
reuses a coverage view, adds the missing endpoint nodes, and adds
the missing connections. It also relocates redundant
Grouping-to-contained-child Aggregation/Composition connections out
of readable views into the coverage view (containment communicates
the meaning visually instead).

Coverage views are marked with the `mcp:relationship_coverage_view`
property, so future invocations recognize them regardless of the
display name.

Args:
    coverage_view_name: Name of the coverage view. If a view with
        this name exists, it is reused; otherwise it is created.
    auto_layout: When true (default), lay out the affected views
        after adding nodes and connections.
    layout_strategy: Validated for consistency with other layout
        tools but not applied — the coverage view layout is a fixed
        source/target pair grid.
    layout_engine: Must be `internal` (the default). The coverage
        layout is a fixed pair grid, so no other engine can be
        honoured here and passing one is an error rather than a
        silently ignored hint.
    rollback_on_error: When true (default), restore the previous
        model state if coverage creation fails.

Returns:
    Success envelope with `data` containing the coverage view ID,
    added node and connection counts, relocated containment
    connection counts, skipped relationship IDs, and remaining
    unused relationship IDs.

Errors:
    `ModelNotFoundError` if no model is active.
    `ModelOperationError` for an unknown layout strategy/engine
        (with `error.details.suggestions`), or for any engine other
        than `internal`. Both are validated whether or not
        `auto_layout` is true.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
auto_layoutNo
layout_engineNointernal
layout_strategyNolayered_by_type
rollback_on_errorNo
coverage_view_nameNoRelationship Coverage

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

Annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true) provide a high-level safety profile. The description adds critical details: it creates views, modifies model structure (adds nodes/connections), relocates containment connections, and marks views with a property. It also discloses rollback behavior and fixed layout behavior. No contradiction with 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 well-structured: a one-sentence purpose, followed by context, method, and detailed parameter explanations. Every sentence adds substantive value without redundancy or fluff. It earns its length.

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 parameters, no required ones, many siblings), the description covers the algorithm, property marking, error conditions, layout behavior, and return data structure. The output schema is referenced (success envelope with specific fields), providing a complete picture for an agent.

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%, but the description contains an 'Args' section that explains each parameter's purpose and constraints (e.g., layout_engine must be 'internal', layout_strategy is validated but not applied, rollback_on_error default true). This fully compensates for the lack of schema documentation.

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 specific verb-resource pair: 'Ensure every model relationship is rendered in at least one view.' It explains the context (Archi Validator reports) and details the actions (create/reuse coverage view, add nodes/connections, relocate connections). This clearly distinguishes it from sibling tools like add_node_to_view or auto_layout_view.

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 explicitly states when to use: when Archi Validator reports 'Unused Relation' or similar. It explains the behavior of coverage views and their detection via property marking. It also lists error conditions. While it does not explicitly mention alternative tools, the context is sufficient for an agent to decide.

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

Install Server

Other Tools

Latest Blog Posts

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/byrondelgado/mcp-archimate'

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