Skip to main content
Glama
affinity-mcp

affinity-mcp

by StevenJPx2

affinity_save_script_to_library

Destructive

Save a completed JavaScript script to Affinity's script library so you can reuse it across design document workflows.

Instructions

Save a completed JavaScript script to Affinity's script library.

Input Schema

NameRequiredDescriptionDefault
codeYes
titleYes
descriptionYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.6/5.0
Behavior2/5

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

Annotations declare destructiveHint=true and idempotentHint=false, so the agent knows this is a mutating, non-idempotent write. The description, however, never mentions overwrite risk, whether saving the same title twice duplicates or replaces, or any prerequisites such as an open document — all of which are critical for a destructive write. It reads as a harmless additive 'save' and masks the risk the annotations flag.

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?

A single front-loaded sentence with no filler or redundancy. It is efficient, though its brevity is the direct cause of the missing behavioral and parameter detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-idempotent mutation with three undocumented parameters and no output schema, the description supplies only the barest statement of intent. It omits overwrite behavior, error conditions, and what the tool returns, so an agent cannot call it confidently without trial and error.

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

Parameters1/5

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

All three parameters have 0% schema description coverage and no required/enum hints in the schema beyond type and minLength. The description adds no meaning to title, description, or code, leaving the agent with no idea of expected format, length, or content conventions for any of them.

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 names a specific verb and resource (save a script to the script library), which is clearly distinct from affinity_execute_script and affinity_read_library_script by name. It stops short of explicitly contrasting with those siblings, but the action 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 word 'completed' hints that only finished scripts belong here, but there is no guidance on when to save versus execute directly, whether saving is required before execution, or what happens if a script with the same title already exists. The agent must guess the workflow position of this tool.

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