Foliyo

Save a project, and open its hub

save_project

DestructiveIdempotent

Save or update a client or project record with default sender, design guide, audience, presentation format and access settings. Optionally create a hosted project hub that groups its published pages. Existing pages retain their own access settings. Returns the saved project and any generated hub links and access code.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>"
    },
    "name": "save_project"
  }
}

Input Schema

Name	Required	Description
`hub`	No	true to give the project a hub, or your own address for it.
`gate`	No	How the hub is locked: "email" (each reader types an address once, and the report names them - prefer this) or "pin" (six digits everyone shares, so every reader stays anonymous). Also accepted: "password" (the old name for "pin"), "domain:acme.com", "none".
`name`	Yes	Short handle, e.g. "acme". Reusing one updates it in place.
`guide`	No	Saved design guide name to write this project's HTML to.
`label`	No	Shown on the hub, e.g. "Acme Q3".
`format`	No	Default presentation format for new pages.
`verify`	No	Email a code to prove the reader owns the address.
`audience`	No	Saved audience id: who reads this project by default.
`password`	No	The hub PIN, when gate is "pin". Six digits are minted if you omit it.
`senderId`	No	Saved sender identity, by id or label.
`shareGate`	No	Default gate for NEW pages: pin, email, domain:acme.com or none. Separate from the hub gate. Email/domain require Pro.
`description`	No	One line under the hub title.
`shareVerify`	No	Prove mailbox access for the default email/domain share gate.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 26, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```

Changed1 schema field changedSep 27, 2026

addedInput schema / properties / format

Added value: +{
+  "description": "Default presentation format for new pages.",
+  "enum": [
+    "web",
+    "slides-16-9",
+    "slides-flexible",
+    "interactive-static"
+  ],
+  "type": "string"
+}

First observedSep 14, 2026

TDQS

A4/5.0

Behavior4/5

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

Goes meaningfully beyond the annotations by disclosing non-obvious behavior: the hub is optional, existing pages keep their own access settings when the project is re-saved, and the response includes generated hub links and an access code. It does not, however, explain what the destructiveHint=true implies (which existing settings get overwritten on update) or the Pro gating that the annotations leave open.

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?

Three sentences, zero padding. The core upsert behavior is front-loaded, the optional hub follows, and the return contract closes it out.

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?

With 13 parameters, no output schema, and destructive+openWorld annotations, the description does solid work: it explains the hub-creation branch and returns. What's missing is the destructive side of update (what gets replaced), and the distinction the schema draws between hub gate and shareGate for new pages.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already explains hub, gate, guide, shareGate, format, and the rest in detail. The description only summarizes the field groups and adds no syntax, defaults, or interaction rules beyond schema text. Baseline 3 applies.

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?

States a specific verb pair (save or update) and resource (client/project record), and enumerates exactly which settings it owns: sender, design guide, audience, presentation format, access. That scope cleanly separates it from save_guide, save_sender, and save_audience without needing to name them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: 'save or update' plus the 'reusing one updates it in place' hint conveys the upsert pattern. But there is no explicit when-to-use guidance versus get_project, delete_project, or the other save_* siblings, and no prerequisites (e.g., Pro for email/domain gates) surfaced in the description.

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

All Foliyo tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?