flingflyers

Publish a flyer

publish_flyer

Publish an HTML document at a short public URL and return the link. Use this when the user wants to view a page you made in a real browser, send it to someone, or open it on another device — anywhere handing back raw markup is not good enough.

The link works for anyone who has it, with no account and no sign-in, and expires on its own (7 days by default). It is public: anyone with the URL can read the page, so do not publish anything the user would not post openly, and confirm first unless they have asked you to share it.

Plain (unencrypted) only. The document reaches the server as text, so this cannot produce an encrypted flyer — for that the user runs npx flingflyers <file> -e --persist on their own machine, where the key is generated locally and never sent. Say so rather than implying this is private.

Single self-contained document: inline the CSS, JS and images, or use data URIs. External file references will not resolve.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`html`	Yes	The complete HTML document, including <!doctype html>. Must be self-contained.
`ttl_hours`	No	How long the link should live, in hours. Default 168 (7 days), maximum 720 (30 days).

TDQS

A4.9/5.0

Behavior5/5

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

The description discloses key behaviors beyond annotations: link is public, expires automatically (7 days default), is unencrypted, and requires a self-contained document. It also warns about external references not resolving. No contradiction with annotations.

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?

The description is well-structured, starting with the core action, then usage context, behavioral details, and technical constraints. Each sentence adds necessary information without redundancy.

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

Completeness5/5

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

Given the tool's simplicity (2 parameters, no output schema), the description covers all essential aspects: purpose, usage, security, constraints, and return value (implied link). It leaves no significant gaps.

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 100%, so baseline is 3. The description adds value by emphasizing that the HTML must be self-contained and include <!doctype html>, and warns that external files won't resolve. This goes beyond the schema's parameter descriptions.

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?

The description clearly states the tool publishes an HTML document to a short public URL and returns the link. It distinguishes itself from siblings (revoke_flyer, update_flyer) by focusing on creation of a flyer.

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?

The description explicitly states when to use the tool (e.g., when user wants to view in browser, send to someone) and when not to (e.g., for encrypted flyers, recommending an alternative command). It also advises to confirm before publishing sensitive content.

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

All flingflyers tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0

Disambiguation5/5

Each tool targets a distinct action on flyers: publish creates, revoke deletes, update replaces content. Descriptions clearly differentiate them with no overlap, ensuring an agent can reliably select the correct tool.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case: publish_flyer, revoke_flyer, update_flyer. The naming is predictable and uniform, aiding in quick understanding.

Tool Count4/5

With 3 tools, the server is minimal but well-scoped for its purpose of publishing and managing individual flyers. While a few more tools (e.g., list or extend expiry) could be useful, the current count is not too few for the core functionality.

Completeness4/5

The tool set covers the essential lifecycle: create, read (implicitly via publish), update, and delete. Minor gaps exist, such as no explicit retrieval of a flyer's metadata or ability to extend expiration without updating content, but the core workflow is complete.

Resources

Need Help?