Skip to main content
Glama

Kindnod cookie consent

Get the Shortbread install snippet

get_snippet

Returns the keyless install snippet (works for any public domain with no setup) and the npm usage for React/Next.js. Use provision_site instead when you want a site key and a claim link now.

Input Schema

NameRequiredDescriptionDefault
viaNo
ownerNoSite owner's email to put on the tag so they get the claim link

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior3/5

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

With no annotations, the description carries the burden and does disclose the key behavioral trait: the snippet is keyless and needs no setup for any public domain. It does not say whether the tool is rate limited, how the snippet is delivered (payload vs URL), or that passing 'owner' changes the output into a claim-link-bearing tag, which mildly undercuts its own advice to use provision_site for claim links.

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?

Two sentences, zero filler, with the return content front-loaded and the sibling routing held for the second sentence. Nothing is repeated from the schema or title.

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?

For a zero-required-parameter read tool with no output schema and no annotations, the description covers purpose and routing but leaves the return shape generic ('install snippet', 'npm usage') and does not mention that 'via'/'owner' alter what comes back. Adequate but with a real gap around optional-parameter behavior.

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 only 50% and the description explains neither parameter. 'via' appears in the schema with no description anywhere, and 'owner' is left entirely to the schema's one-liner even though it materially changes the returned snippet — the description's steer toward provision_site for claim links conflicts with the fact that get_snippet can put the owner on the tag itself.

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?

A specific verb (retrieves) plus a precisely described resource (keyless install snippet and React/Next.js npm usage), with the scope constraint 'works for any public domain with no setup' stated up front. An agent can distinguish it from provision_site purely from the description.

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?

Explicitly routes the agent to an alternative with the selecting condition: 'Use provision_site instead when you want a site key and a claim link now.' That is an explicit when-not with a named sibling, which is the strongest form of usage guidance.

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