Skip to main content
Glama

Prepare a Foliyo

prepare_foliyo
Read-onlyIdempotent

Required before creating a new Foliyo and after each setup answer. Pass all explicit choices already known from the brief/conversation. Returns exactly the next question or a summary to confirm. Ask it and wait; do not build or publish until readyToBuild=true. Never silently fill missing brand, access or recipient choices. Read-only; loads account, plan and optional saved project/guide. Updates use get_page instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
choicesNo
projectNoAn EXISTING saved project handle only. Omit for new work unless the user explicitly identifies a saved project; do not put the document title here.
confirmedNoTrue only after approval of the complete summary, or explicit delegation of ALL choices plus a request to publish. A number answering a setup question is not approval.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / choices
      Added value: +{
      +  "additionalProperties": false,
      +  "properties": {
      +    "access": {
      +      "$ref": "#/properties/choices/properties/audience",
      +      "description": "The user-selected gate: pin, none, email or domain:example.com. Do not fill an unanswered question with the default PIN."
      +    },
      +    "audience": {
      +      "description": "Audience explicitly identified in the brief or a prior answer.",
      +      "maxLength": 500,
      +      "minLength": 1,
      +      "type": "string"
      +    },
      +    "brand": {
      +      "description": "Only use foliyo when the user chooses or delegates the clean style. A sender name is not a brand choice.",
      +      "enum": [
      +        "mine",
      +        "client",
      +        "project",
      +        "foliyo"
      +      ],
      +      "type": "string"
      +    },
      +    "brandSource": {
      +      "$ref": "#/properties/choices/properties/audience",
      +      "description": "The chosen website URL, supplied assets, or saved design guide. Required for a non-Foliyo brand."
      +    },
      +    "format": {
      +      "enum": [
      +        "web",
      +        "slides-16-9",
      +        "slides-flexible",
      +        "interactive-static"
      +      ],
      +      "type": "string"
      +    },
      +    "recipientNames": {
      +      "description": "Names the user provided for personal links. Emails are optional at publication, never invented.",
      +      "items": {
      +        "$ref": "#/properties/choices/properties/audience"
      +      },
      +      "maxItems": 100,
      +      "minItems": 1,
      +      "type": "array"
      +    },
      +    "recipients": {
      +      "enum": [
      +        "personal",
      +        "shared"
      +      ],
      +      "type": "string"
      +    },
      +    "sender": {
      +      "$ref": "#/properties/choices/properties/audience",
      +      "description": "The actual person/company display name, not just individual/company/other."
      +    }
      +  },
      +  "type": "object"
      +}
    • addedInput schema / properties / confirmed
      Added value: +{
      +  "description": "True only after approval of the complete summary, or explicit delegation of ALL choices plus a request to publish. A number answering a setup question is not approval.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / project / description
      Added value: +"An EXISTING saved project handle only. Omit for new work unless the user explicitly identifies a saved project; do not put the document title here."
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare read-only/idempotent/non-destructive, so the safety profile is covered; the description still adds real value beyond them: the exact return shape (next question vs. confirmation summary), the readyToBuild gating rule, the side-effect of loading account/plan/saved project, and the constraint 'Never silently fill missing brand, access or recipient choices.' A modest deduction because 'Read-only' largely restates the annotation.

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?

Seven short sentences, each carrying a distinct instruction (precondition, input rule, return shape, wait/gating rule, no-fabrication rule, side effect, alternative tool). Front-loaded with the precondition and free of filler.

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 nested-schema, no-output-schema tool, the description supplies the return contract and the workflow gating an agent needs. The remaining gap is minor: the roles of 'confirmed' and 'project' are left entirely to the schema, but the schema documents them adequately.

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 coverage is 67% and the nested choice fields are already well documented, so the schema does much of the work. The description still adds directive semantics the schema lacks: pass all explicit choices known from the brief/conversation, and never invent unanswered values. It does not, however, clarify the 'confirmed' or 'project' params beyond what the schema says.

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 states the specific role: it must run before creating a new Foliyo and after each setup answer, and it returns 'exactly the next question or a summary to confirm.' That distinguishes it from a builder/publisher and from get_page, which it names for updates. The name/title alone ('Prepare a Foliyo') is vague, but the body resolves it clearly.

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?

Explicit when-to-use: 'Required before creating a new Foliyo and after each setup answer.' Explicit sequencing and gating: 'Ask it and wait; do not build or publish until readyToBuild=true.' It also names the alternative for the update path ('Updates use get_page instead'), leaving nothing to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources