Skip to main content
Glama
Athenaxlee

llm-migrate

by Athenaxlee
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Submit Adapted Prompt

submit_adapted_prompt

Validate and store an adapted prompt for the target model, ensuring minimal changes and documented guidance dispositions.

Instructions

Validate and store one adapted prompt for the target model.

Adapt minimally: change only what a listed model difference or guidance item requires. Dispose EVERY guidance item of the task (its guidance plus shared_prompt_guidance) exactly once in guidance_dispositions: {guidance_id, disposition: applied|not_applicable|declined, note (required when declined)}. Document every edit in annotated_changes against the DECODED runtime values: {operation: edit|insert|delete| restructure, original_anchor/adapted_anchor (exact spans), why, evidence: [{kind: model_guidance|model_difference|analysis_finding| research|mechanical, url|reference}]}; every diff hunk covered, no phantom annotations. Serialization-, whitespace-, or case-only edits are rejected; structural drops need allow_restructure=true plus a recorded justification. No change needed? Pass unchanged=true with an EMPTY adapted_prompt (refused while the prompt still references the source model). Shared guidance already disposed earlier in the run is no longer owed, and default_disposition covers unlisted items as visibly defaulted records. Deliverables land under /output/prompts/.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
changesNo
run_dirYes
rationaleYes
unchangedNo
source_pathYes
adapted_promptYes
allow_restructureNo
annotated_changesNo
default_dispositionNo
guidance_dispositionsNo
default_disposition_noteNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.6.0
    • addedInput schema / properties / annotated_changes
      Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}
    • addedInput schema / properties / default_disposition
      Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "applied",
+        "not_applicable",
+        "declined"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}
    • addedInput schema / properties / default_disposition_note
      Added value: +{
+  "default": "",
+  "type": "string"
+}
    • addedInput schema / properties / guidance_dispositions
      Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "additionalProperties": {
+          "type": "string"
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}
  2. Changed2 schema fields changedv1.3.0
    • addedInput schema / properties / allow_restructure
      Added value: +{
+  "default": false,
+  "type": "boolean"
+}
    • addedInput schema / properties / unchanged
      Added value: +{
+  "default": false,
+  "type": "boolean"
+}
  3. Addedv1.2.0

TDQS

A3.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden. It discloses several behavioral traits: it rejects serialization/whitespace/case-only edits, refuses when unchanged=true but prompt still references source model, treats shared guidance already disposed as no longer owed, and writes deliverables to <run>/output/prompts/. It also requires allow_restructure for structural drops. This is substantive behavioral disclosure, though it does not cover permissions, idempotency, or failure modes beyond rejections.

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?

The description is a single dense paragraph with many semicolon-separated rules. It front-loads the purpose but then packs in a large number of constraints with no visual structure (bullets, sections). Each sentence has content, but the density makes it harder to scan. It is longer than ideal, though appropriate for a complex validation workflow. Loses points for organization, not content.

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 an 11-parameter tool with 0% schema coverage and no annotations, this description covers a remarkable number of edge cases: minimal-adaptation policy, guidance disposition completeness, annotation exactness, rejection criteria, restructure permission, default disposition behavior, and output location. Since an output schema exists, the return value need not be described. Minor gaps: 'DECODED runtime values' and 'listed model difference' are assumed knowledge. Overall, it is nearly complete for an agent.

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 description coverage is 0%, so the description must add meaning. It does—substantially. It specifies the exact structure and semantics for guidance_dispositions, annotated_changes, the meaning of unchanged (with empty adapted_prompt), allow_restructure, and default_disposition. However, it leaves several parameters (rationale, changes, default_disposition_note, source_path) under-explained, and some references ('DECODED runtime values') are ambiguous. Still, the description adds significant value beyond the raw schema.

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

Purpose4/5

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

The description opens with 'Validate and store one adapted prompt for the target model,' naming a specific verb (validate/store), resource (adapted prompt), and scope (one, target model). This distinguishes it from broader siblings like submit_adaptations or submit_adapted_file, though it does not name them explicitly. The purpose is unambiguous.

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?

The description is entirely procedural—how to adapt, dispose guidance, and annotate changes—but never states when to choose this tool over siblings like submit_adaptations, submit_adapted_file, or record_change_decisions. There is no explicit use-case guidance, prerequisites, or exclusion conditions. The implied usage is that this is the only submission point for adapted prompts, but that is not stated.

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