Skip to main content
Glama
Mipiti

Mipiti MCP Server

by Mipiti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Create Reliance

create_reliance

Declare a dependency from a model to a provider control, with delegated or relied-upon modes, to enable semantic validation of cross-model reliance within a workspace.

Instructions

Declare a cross-model dependency: this model relies on a provider control.

Two modes (the target is ALWAYS a provider control — credit terminates at a proven mechanism):

  • delegated: this model does NOT implement an objective locally; it is handled entirely by the provider's control. Pass source_objective_id.

  • relied_upon: this model has its OWN control whose validity depends on the provider's control. Pass source_control_id.

The provider must be a model in the SAME workspace as the consumer (reliance is workspace-scoped and does not reach across workspace boundaries). The edge enters draft and runs LLM semantic validation; it carries no credit until confirmed via confirm_reliance (and only when validation returned valid). Returns the created edge.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeYes"delegated" or "relied_upon".
model_idYesthe consumer model declaring the dependency.
server_versionYes
provider_model_idYesthe model whose control satisfies the dependency.
source_control_idNoconsumer control id (required for "relied_upon").
provider_control_idYesthe provider's control (the credit terminus).
source_objective_idNoconsumer objective id (required for "delegated").

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.62.2
  2. Removedv0.62.1
  3. First observedv0.57.0

TDQS

A4.8/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full behavioral burden. It clearly discloses that the edge enters draft state, runs LLM semantic validation, carries no credit until confirmed, only receives credit when validation returned 'valid', and returns the created edge. This is strong transparency for a creation 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 well-structured and scannable: a front-loaded purpose, a clear two-mode breakdown using backticks and dashes, and no filler sentences. Every sentence contributes either a mode rule, a prerequisite, or a lifecycle fact.

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 complex 7-parameter, two-mode creation tool, the description covers the essential context: mode semantics, conditional parameter usage, workspace scoping, lifecycle behavior, and the return value. It is only slightly incomplete because the required server_version parameter is unexplained and error/idempotency behavior is not addressed.

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 description adds meaningful parameter semantics by mapping modes to conditional parameters: delegated -> source_objective_id, relied_upon -> source_control_id. It also clarifies provider_control_id as the 'credit terminus' and adds a workspace-constraint meaning for provider_model_id. However, the required server_version parameter remains undocumented in both the schema and the 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 opens with a specific verb ('Declare') and a clear resource ('cross-model dependency'), then immediately explains the core concept: this model relies on a provider control. The lifecycle note (draft -> confirm_reliance) also helps distinguish this tool from siblings like list_reliance, confirm_reliance, and delete_reliance.

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?

The two modes are explicitly defined with conditions for choosing each: delegated means no local implementation and requires source_objective_id; relied_upon means the model has its own control and requires source_control_id. It also states the workspace-scoping prerequisite and the required follow-up step through confirm_reliance, giving concrete when-to-use guidance.

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