Repository Manager

Materialize

rm_concepts_materialize

Materializes repository concept-ID claims via the central authority, refusing mutations instead of allocating IDs locally when unavailable.

Instructions

Materialize (rm_concepts). Concept-id claim coordination against RMDD-16's central authority.

Repository-manager never allocates a concept id itself: every action here is a thin, MCP/CLI-neutral consumer of an injected authority port. When the central authority (agent_connector_sdk.governance. concept_reservation) is unavailable in this environment, every mutating action refuses with a named dependency_blocked/ConceptAuthorityUnavailable error instead of fabricating a local allocation -- it never mints or reuses an id on its own.

Input Schema

Name	Required	Description	Default
`limit`	No	For list: page size.
`state`	No	For list: filter by claim state.
`branch`	No	For reserve, optional.
`cursor`	No	For list: opaque page cursor.
`purpose`	No	For reserve.
`base_sha`	No	For reserve, optional.
`lane_ref`	Yes	Lane/worktree identity for fragment provenance.
`candidate`	No	For verify_candidate: a serialized Candidate contract payload.
`namespace`	No	For reserve (required) or list (optional filter).
`owner_ref`	No	For release/materialize (must match the claim owner).
`repo_path`	No	For verify_candidate/verify_generation: the Git repository to diff.
`repo_root`	Yes	Repository working tree root.
`candidates`	No	For verify_generation: serialized Candidate contract payloads.
`concept_id`	No	For reserve.
`design_ref`	No	For reserve, optional.
`generation`	No	For verify_generation: a serialized Generation contract payload.
`tenant_ref`	Yes	Authenticated tenant scope.
`workitem_ref`	No	For reserve, optional.
`run_trace_ref`	No	For reserve, optional.
`concept_prefix`	No	For list: filter by concept-id prefix.
`expected_fence`	No	For release/materialize: the claim's current fence.
`repository_ref`	No	For reserve.
`reservation_id`	No	For get/release/materialize.
`provenance_refs`	No	For reserve, optional.
`request_key_ref`	No	For reserve: idempotency key.
`source_tree_ish`	No	For reconcile: the tree-ish to scan for markers.	HEAD

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv3.5.1Oct 19, 2026

TDQS

C2.9/5.0

Behavior4/5

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

Beyond the annotations, the description adds meaningful behavioral context: it says repository-manager is a thin consumer of an injected authority port and that mutating actions refuse with dependency_blocked/ConceptAuthorityUnavailable rather than fabricating a local allocation. It also explicitly states it never mints or reuses a concept id on its own, which is useful non-obvious information.

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 reasonably compact for a complex tool and front-loads the domain and failure behavior. The main weakness is that the first sentence is mostly a repeat of the tool name/title, but the remaining sentences earn their place by explaining the authority dependency.

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 complexity and the existing annotations and output schema, the description is only partially complete. It covers the external-authority dependency and refusal behavior, but it omits the action-specific semantics of materialize and any sibling-tool routing guidance.

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 100%, so the schema already documents all 26 parameters, including the many per-action notes such as 'For list' and 'For reserve.' The description adds no parameter-level details beyond the schema, so the baseline score of 3 applies.

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

Purpose2/5

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

The description opens with 'Materialize (rm_concepts)', which mostly restates the tool name/title, and then gives only a vague domain phrase: 'Concept-id claim coordination against RMDD-16's central authority.' It never says what the materialize operation actually does or how it differs from sibling tools such as rm_concepts_reserve or rm_concepts_release.

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 when-to-use guidance is provided. The description explains dependency failure behavior, but does not state when to choose this tool over alternatives like rm_concepts_reserve, rm_concepts_release, or rm_concepts_get.

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

Deploy Server