Skip to main content
Glama
Sign In

Supero

by io.github.supero-platform
OverviewDiscussions(2)Admin

schema_save

DestructiveIdempotent

Save/upload schemas into a project. Schemas are validated before saving and linked to the project. Returns the saved schemas with their UUIDs; skipped schemas carry the platform's reason.

IMPORTANT: Pass FLAT schema objects directly — do NOT wrap in schema_content. The tool handles schema_type detection and wrapping automatically.

Required fields: name, namespace, parent_type, attributes. Set namespace to your app's namespace (e.g. 'shop'); the schema is stored as namespace:name. Mark required attributes with "mandatory": true.

Supported attribute types: 'string' for text, 'float' for decimal numbers (NOT 'number'), 'integer' for whole numbers, 'boolean' for true/false.

project_uuid defaults to your key's project; a project-scoped key can only save into its own project. A schema skipped for compatibility warnings is applied with force_upload=true.

Example: { "schemas": [{ "name": "product", "namespace": "shop", "description": "Product catalog entry", "parent_type": "tenant", "attributes": [ {"name": "title", "type": "string", "mandatory": true}, {"name": "price", "type": "float"}, {"name": "stock", "type": "integer"} ] }] }

Input Schema

NameRequiredDescriptionDefault
schemasYesArray of schema definitions to save.
force_uploadNoApply changes that only have compatibility WARNINGS (default: false). Breaking changes are still refused.
project_uuidNoProject to save into (defaults to your key's project; required for a domain-admin key).
skip_existingNoSkip schemas that already exist (default: true).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / force_upload
      Added value: +{
+  "description": "Apply changes that only have compatibility WARNINGS (default: false). Breaking changes are still refused.",
+  "type": "boolean"
+}
    • changedInput schema / properties / project_uuid / description
      Previous value: -"Optional project UUID to auto-link saved schemas to."New value: +"Project to save into (defaults to your key's project; required for a domain-admin key)."
  2. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true and idempotentHint=true; the description adds genuine context beyond that — pre-save validation, what the return value contains (UUIDs and skip reasons), key scoping limits, and the force_upload escape hatch for warnings only. This is the kind of disclosure the annotation bar rewards.

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?

Front-loaded with purpose first, then the critical 'do NOT wrap' warning, then field rules, then a worked example. Slightly long and the attribute-type list reads as a block, but every segment carries actionable content.

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?

No output schema exists, and the description supplies the return shape itself (saved schemas with UUIDs, skipped ones with reasons). Combined with the required-fields and example coverage, an agent has everything needed to construct a valid call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline would be 3, but the description goes materially further: it demands FLAT objects (no schema_content wrapper), lists the required fields, explains namespace semantics ('stored as namespace:name'), documents mandatory flags, and enumerates valid attribute types including the 'float' vs 'number' trap.

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?

States a specific verb+resource ('Save/upload schemas into a project') plus the side effects of validation and project linkage. It does not explicitly distinguish itself from schema_update or schema_validate, which are the closest siblings, so the agent must infer the boundary.

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?

Gives real operational context: schemas are validated first, skipped ones come back with reasons, project_uuid defaults to the key's project, and force_upload is the remedy for compatibility warnings. It stops short of saying when to use this versus schema_update for an already-existing schema.

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

All Supero toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources