Skip to main content
Glama
Mipiti
by Mipiti

Manage Reliance

manage_reliance

Create, confirm, or delete cross-model reliance edges for AI model security posture. Validate provider-control reliance before granting credit and remove edges to withdraw coverage.

Instructions

Create, confirm or delete one cross-model reliance edge. Mutating.

action="create" declares that model_id relies on a provider control (the target is ALWAYS a control, so credit ends at a proven mechanism). mode is delegated (this model does not implement the objective; pass source_objective_id) or relied_upon (this model's own control depends on the provider's; pass source_control_id). The provider must be in the same workspace. The edge enters draft, runs LLM semantic validation, and carries no credit until confirmed. Returns the edge.

action="confirm" promotes the draft edge_id to active, the credit-soundness gate: refused unless validation returned valid; a partial result or a mode mismatch is never silently credited. Returns the edge.

action="delete" permanently removes edge_id, withdrawing any credit the consumer derived from it (its coverage can move); neither model's controls change. Returns {deleted: true, edge_id}.

list_reliance shows a model's edges and their ids.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNo
actionYes
edge_idNo
model_idNo
server_versionYes
provider_model_idNo
source_control_idNo
provider_control_idNo
source_objective_idNo
accept_partial_as_relied_uponNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.84.0

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so richly: create enters a draft state, runs LLM semantic validation, and carries no credit until confirmed; confirm is refused unless validation returned valid and never silently credits a partial or mode mismatch; delete permanently removes the edge and withdraws derived credit without altering either model's controls. These are exactly the side effects and gating rules an agent needs.

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?

Well structured with a front-loaded summary followed by per-action paragraphs, so an agent can jump to the relevant action. It is somewhat verbose and repeats 'Returns the edge' three times, which slightly dilutes density.

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 an output schema exists, return values need not be spelled out, yet the description still notes the edge object and the {deleted, edge_id} shape. Combined with the per-action lifecycle and validation gating, nothing material is missing for correct invocation.

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 0% across 10 parameters, so the description must compensate and largely does: it defines mode values (delegated vs relied_upon) and which source id each requires, the edge_id used by confirm/delete, and the same-workspace constraint on the provider. It omits accept_partial_as_relied_upon and server_version, leaving a small gap, so not a full 5.

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?

Opens with a specific verb set and resource ('Create, confirm or delete one cross-model reliance edge') and immediately flags the mutating nature. It explicitly distinguishes itself from the sibling list_reliance, which it names as the read path. An agent can tell exactly what this tool does without opening the schema.

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?

Each action is given its own condition: create declares a reliance with a mode-dependent source id, confirm is the credit-soundness gate that requires valid validation, delete withdraws derived credit. It also routes to list_reliance for retrieving edge ids. It lacks explicit 'when not to use' guidance, so it falls just short of a 5.

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

Deploy Server

Other Tools