Skip to main content
Glama

share_plan

Read-onlyIdempotent

Create a shareable link or sfplan line from a saved factory plan to open a copy on the page or share it with others.

Instructions

A saved plan as a link that opens a copy on the page, or as a sfplan: line.

Input Schema

NameRequiredDescriptionDefault
planYesthe saved plan's name or key
saveNo
as_ofNopin to one save: the sav:… token an earlier answer printed
notesNoinclude the plan's notes
worldNo
layoutNoinclude the graph layout
include_worldNoname this world in the link, so it opens straight into it here

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.0

TDQS

C2.7/5.0
Behavior3/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 bar is low. The description usefully discloses the output format (a page-opening link or an sfplan: line), but says nothing about whether the link encodes notes/layout/world state, whether it is stable or signed, or what the tool returns.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is a single tight sentence fragment with no padding, but it is under-specified rather than concise: 'the page' has no referent and no front-loaded statement of what the tool returns.

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

Completeness3/5

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

With seven parameters, no output schema, and a link-generation behavior whose content varies by flags, the description should explain what the emitted link/line actually encodes. It gives only the shape of the output, leaving the per-flag effects and return value entirely to inference.

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

Parameters2/5

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

Schema coverage is 71%, and 'save' and 'world' are undocumented in both schema and description. The description adds zero parameter meaning — nothing about how include_world, layout, notes, or as_of change the generated link, which is exactly the context a caller needs to pick flags.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description conveys that the tool produces a shareable representation of a saved plan in two forms — a link that opens a copy on the page, or an 'sfplan:' line. It never states a verb or that it generates/returns these artifacts, and it doesn't distinguish itself from the obvious counterpart import_plan, which is what consumes such links.

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?

There is no guidance on when to call this instead of siblings like import_plan, plans, plan_layout, or plan_from_factory. The reader must infer from the name alone that this is the export side of a share/import pair.

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