Skip to main content
Glama

add_relations

Idempotent

Batch-add up to 50 ontology relations in one call, reducing round-trips. Processes each row idempotently and returns detailed per-row errors and suggestions.

Instructions

Batch-add multiple relations in one call — same per-row shape as add_relation. Use after analyze_repo_structure or another review flow when the agent has K semantic edges accepted by the user — replaces K×add_relation round-trips. Inferred module edges are not accepted merely because imports exist; review exact evidence and include the required nonblank why for every new depends_on. Each row is processed independently and idempotently: existing edges return {ok: true, alreadyExists: true}; missing source/target slugs / unknown type / non-object row shape / unknown row fields surface as {ok: false, error} with a relations[n] row label and structured rowName; unknown type rows include a closest-value hint with structured valueName / receivedValue / suggestion / allowedValues; single unknown-field rows include receivedField plus one-row unknownFields; multi unknown-field rows report every unknown field with nearest hints, allowedFields, receivedFields, and Received fields: .... relations[] order in the response matches the input. Cap = 50 per call. NO atomic rollback — for all-or-nothing semantics use single add_relation calls. Tip: avoid expected_mtime in batch when multiple rows share the same from slug — the first row mutates that file so the second would see a stale mtime. Invalid-only batches return no row-level changed / alreadyExists write metadata and no top-level postWriteMaintenance. When at least one row changes the vault, the response includes one compact postWriteMaintenance (maintenance_plan) with count-safe byPhase / bySeverity / byKind queue buckets, action score, executable proposedAction, and current-page nextExecutableAction / nextReviewAction pointers for the final graph.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
relationsYesArray of relation specs (max 50). Each row uses the same shape as `add_relation` input.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
relationsYes
postWriteMaintenanceNoCompact maintenance_plan summary for post-write follow-up. Bucket maps describe the remaining queue after the write.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.13.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare idempotentHint=true, readOnlyHint=false, destructiveHint=false, and the description adds substantial context beyond these: idempotency detail (alreadyExists responses), non-atomicity with no rollback, the 50-call cap, response ordering, the expected_mtime staleness pitfall, and detailed error-shape semantics. No contradiction with annotations — idempotentHint matches the 'processed ... idempotently' claim.

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

Conciseness3/5

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

Front-loaded with purpose and usage, and every sentence carries real information. However, it is very long and dense — the error-handling enumeration (unknown type, single/multi unknown-field rows, receivedValue/suggestion/allowedValues) is verbose and partly duplicates what an output schema should convey. It is information-dense but less scannable than it could be with a more structured layout.

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 complex batch tool with idempotency, non-atomicity, varied error shapes, and a maintenance-plan output, the description is remarkably complete: use context, exclusions, limits, error semantics, ordering guarantee, and postWriteMaintenance structure are all covered. An output schema exists, yet the description still clarifies return behavior beyond it. Nothing an agent needs to call it correctly is missing.

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 coverage is 100%, so the baseline is 3. The description adds genuine value beyond the schema: the 'required nonblank why for every new depends_on' emphasis (schema has this too, so partly redundant), the per-row shape reference to add_relation, and the expected_mtime tip about same-from-slug staleness. The added context justifies one point above baseline.

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

Purpose5/5

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

States a specific verb+resource ('Batch-add multiple relations') and immediately distinguishes from the sibling add_relation by noting the 'same per-row shape' but batch semantics. An agent can clearly tell this from add_relation without opening either schema.

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

Usage Guidelines5/5

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

Explicitly says when to use it ('after analyze_repo_structure or another review flow when the agent has K semantic edges accepted by the user') and when NOT to use it ('NO atomic rollback — for all-or-nothing semantics use single add_relation calls'). Names the exact alternatives (add_relation, analyze_repo_structure) with selection conditions. Nothing is left to inference.

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