save_blueprintSave a blueprint to the local store for reuse: apply it to other servers with execute_build_plan or track drift with diff_blueprint. Names are unique.
Save a blueprint to the local store for reuse: apply it to other servers with execute_build_plan or track drift with diff_blueprint. Names are unique.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| blueprint | Yes | ||
| description | No |
Changes observed during successful MCP inspections.
v1.4.0Input schema / properties / blueprint / properties / channels / maxItemsPrevious value: -100New value: +500Input schema / properties / blueprint / properties / roles / descriptionAdded value: +"Highest role first, the way the server settings list them. A build creates them in this order and that order is the hierarchy."Input schema / properties / blueprint / properties / roles / maxItemsPrevious value: -50New value: +250v1.3.0Input schema / additionalPropertiesRemoved value: -falseInput schema / properties / blueprint / additionalPropertiesRemoved value: -falseInput schema / properties / blueprint / properties / categories / items / additionalPropertiesRemoved value: -falseInput schema / properties / blueprint / properties / categories / items / properties / channels / items / additionalPropertiesRemoved value: -falseInput schema / properties / blueprint / properties / channels / items / $refRemoved value: -"#/properties/blueprint/properties/categories/items/properties/channels/items"Input schema / properties / blueprint / properties / channels / items / propertiesAdded value: +{
+ "name": {
+ "maxLength": 100,
+ "minLength": 1,
+ "type": "string"
+ },
+ "nsfw": {
+ "type": "boolean"
+ },
+ "posting_roles": {
+ "description": "With read_only: role names that may still post.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "private_to": {
+ "description": "Role names that can see this channel. Everyone else is denied view.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "read_only": {
+ "description": "Deny sending for everyone; for rules and announcements.",
+ "type": "boolean"
+ },
+ "slowmode_seconds": {
+ "maximum": 21600,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "topic": {
+ "maxLength": 1024,
+ "type": "string"
+ },
+ "type": {
+ "description": "Default text.",
+ "enum": [
+ "text",
+ "voice",
+ "forum",
+ "stage",
+ "announcement"
+ ],
+ "type": "string"
+ }
+}Input schema / properties / blueprint / properties / channels / items / requiredAdded value: +[
+ "name"
+]Input schema / properties / blueprint / properties / channels / items / typeAdded value: +"object"Input schema / properties / blueprint / properties / roles / items / additionalPropertiesRemoved value: -falsev1.0.2Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=false, so the mutation/safe-save profile is already given. The description adds the uniqueness constraint ('Names are unique'), which is genuinely useful behavioral context, but does not state what happens on a name collision (overwrite vs error) or where the local store lives. With annotations covering safety, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence plus a short uniqueness note, front-loaded with the core action and its two reuse paths. No filler or restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a save tool with nested blueprint input and no output schema, the description gives the purpose and reuse path but omits collision behavior, store location, and any pointer to validate the blueprint first (e.g., with a plan tool). Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% at the top level, so the description must compensate. It notes that names are unique, which speaks to the 'name' parameter, but says nothing about the large nested 'blueprint' object or the optional 'description' field, leaving most parameter semantics unexplained. Baseline 3 reflects partial added meaning over a schema that itself documents nested fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (save) and resource (blueprint) and destination (local store), clearly distinguishing from siblings like export_server_blueprint (which likely serializes) and list/get_blueprint. The mention of reuse via execute_build_plan and diff_blueprint gives precise scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the two downstream alternatives (execute_build_plan, diff_blueprint) and the condition that selects each, effectively telling an agent when this tool is the right precursor. Nothing to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.