Short links you can re-point after printing the QR, with click analytics. Free QR, no key.
FREE, no API key needed. Check whether a custom short code is still free before trying to claim it with shorten_url. Codes are lowercase letters, digits and hyphens, up to 10 characters.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The custom code to test, e.g. "spring26". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It adds useful operational context: the tool is FREE, requires no API key, and is a non-mutating availability check rather than a claim action. It does not describe the exact response when a code is unavailable, but the read-only nature is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with no filler. Operational context and usage come first, format constraints last, and every sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description covers purpose, usage timing, input constraints, and cost/auth. The main gap is the exact return signal when the code is not free, but this is minor for an availability-check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and includes an example. The description adds value beyond the schema by specifying accepted characters and length: lowercase letters, digits, hyphens, up to 10 characters, which helps avoid invalid calls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Check whether a custom short code is still free'. It also refers to shorten_url as the follow-up action, distinguishing this preflight check from the claiming tool and other link-management siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly positions the tool as a precondition: use it 'before trying to claim it with shorten_url'. It does not enumerate when not to use it or compare against other siblings, but the intended workflow is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE, no API key needed. Render any URL or text as a QR code and return it as SVG, optionally also as a PNG data URL. This QR is STATIC: its destination is baked in and cannot be changed once printed. If the destination might ever change, use shorten_url instead — that QR points at a ShareCut short link, stays editable after printing (see update_link) and counts every scan.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | URL or text to encode, up to 2000 characters. | |
| color | No | Foreground colour as a hex value, e.g. #2563eb. Background is always white. | |
| format | No | Also return a PNG data URL alongside the SVG. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it delivers: it discloses auth requirements ('no API key needed'), output formats (SVG plus optional PNG data URL), and the critical behavioral trait that the QR is static and immutable once created. It even explains scan-counting consequences when comparing to the dynamic alternative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences, with the most important facts (free, no auth, output format) front-loaded and the alternative/use condition in a compact second half. No filler or repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with 3 simple parameters and no output schema, the description plus schema fully cover what an agent needs: input, output, auth, and the key immutability constraint. The sibling-scoped alternative completes the decision context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3; the schema already explains data, color, and format. The description reinforces the format behavior ('optionally also as a PNG data URL') and the data meaning but adds no significant detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear action: 'Render any URL or text as a QR code and return it as SVG,' naming both the resource and the output format. It also differentiates the tool by labeling this QR as STATIC with a baked-in destination, setting it apart from dynamic alternatives like shorten_url.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when not to use this tool: if the destination might change, use shorten_url instead, with update_link called out for later edits. This gives an agent a concrete decision rule rather than leaving alternatives to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a link and its click history. Every QR code and shared copy pointing at it stops working immediately, and the short code is released. There is no undo. Prefer update_link when the goal is to send the link somewhere else. Requires a ShareCut API key (Business plan).
| Name | Required | Description | Default |
|---|---|---|---|
| link | Yes | The link, given either as its short code (the part after sharecut.site/) or as the id returned when it was created. A full ShareCut URL is accepted too. | |
| confirm | Yes | Must be true. Deletion is permanent and breaks every printed copy. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses irreversibility, cascading breakage of QR codes and shared copies, short-code release, and explicitly notes there is no undo, plus the access/auth constraint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence earns its place: destructive effect, cascading impact, irreversibility, preferred alternative, and access requirement. The core action is front-loaded, and there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter destructive tool with no annotations and no output schema, the description covers the operation's effect, side effects, permissions, irreversibility, and the correct alternative. Nothing essential for selecting or invoking the tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both link and confirm already well described. The tool description adds behavioral context but no additional parameter-level meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and object — 'Permanently delete a link and its click history' — and follows with concrete effects: QR codes and shared copies stop working and the short code is released. It clearly distinguishes the tool from update_link, the nearest sibling alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs the agent to prefer update_link when the goal is to send the link somewhere else, which is a clear when-not-to-use signal. It also states the API key and Business plan requirement, giving the agent actionable conditions for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE, no API key needed. Look up where a sharecut.site short link actually goes, and how many times it has been used, without opening it. Useful before following or forwarding a link someone sent. Only resolves ShareCut links.
| Name | Required | Description | Default |
|---|---|---|---|
| shortCode | Yes | The short code, or a full https://sharecut.site/... URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses that the tool is 'FREE, no API key needed,' that it resolves links 'without opening it,' and that it only supports ShareCut links. This gives an agent a solid safety and scope picture, though it does not describe rate limits or detailed output behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: it leads with the most operationally important facts (free, no key), states the core behavior, gives a practical use case, and ends with a scope limitation. Every sentence adds value and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description conveys what the tool returns conceptually — the destination and usage count — and covers authentication and scope. It does not specify error behavior or exact response format, but the core usage context is sufficiently complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents the single parameter, including that shortCode can be 'The short code, or a full https://sharecut.site/... URL.' The description adds no further parameter-specific meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action — resolving where a sharecut.site short link goes and how many times it has been used — with a clear resource and scope. It does not explicitly compare itself to sibling tools such as check_short_code or get_link, but the stated purpose is specific enough to distinguish itself functionally.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a concrete use case: 'Useful before following or forwarding a link someone sent.' It also provides an exclusion with 'Only resolves ShareCut links.' However, it does not mention alternatives or when not to use this tool in favor of a sibling, so it falls short of fully explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the plan behind the API key, what it entitles, how much of this month’s API quota is left and when it resets, plus how many links the account holds and their total clicks. Worth calling before a bulk run. Requires a ShareCut API key (Business plan).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It openly declares that the operation is a read ('Read'), mentions the authentication requirement, and specifies what data is returned. It doesn't detail response format or edge cases, but for a simple no-parameter getter this is solid disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and contains no filler. The first sentence packs a lot of detail into a long clause, but every piece is useful, and the second sentence adds concrete usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only, no-parameter tool, the description covers what it does, when to call it, and what prerequisite is needed. It doesn't enumerate response format or error behavior, but it is otherwise complete for an agent selecting and invoking it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so there are no parameter gaps. The description adds useful context by explaining that the implicit subject is the current API key's account, which clarifies what the empty input schema means.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a specific verb ('Read') and resource ('plan behind the API key', quota, link counts), and the scope is account-level, distinguishing it from all link/QR-focused siblings. It directly explains what information is returned, leaving no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit practical guidance: 'Worth calling before a bulk run' and states a prerequisite ('Requires a ShareCut API key (Business plan)'). It doesn't list exclusions or alternative tools, but no account-level sibling exists, so this is sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one link on the account: its destination, title, click count, creation date and UTM settings. Requires a ShareCut API key (Business plan).
| Name | Required | Description | Default |
|---|---|---|---|
| link | Yes | The link, given either as its short code (the part after sharecut.site/) or as the id returned when it was created. A full ShareCut URL is accepted too. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the operation is a read (non-destructive) and lists the returned fields, which is useful behavioral information. However, it does not address rate limits, failure modes, or any side effects, and the auth requirement is a prerequisite rather than a behavior. This is adequate for a simple read but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The core action is front-loaded ('Read one link'), followed by a concise list of returned fields, then a single prerequisite. No filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with no output schema, the description sufficiently covers what is returned (by listing fields) and the auth requirement. It doesn't describe the output shape or error cases, but given the simplicity and full schema coverage, it is almost complete; a minor gap on error behavior keeps it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the parameter's description already explains the accepted formats (short code, id, or full URL). The tool description adds no extra parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Read one link') and a clear resource, then enumerates the exact fields returned (destination, title, click count, creation date, UTM settings). This distinguishes it from siblings like list_links (lists many) and get_link_analytics (analytics focus), leaving no doubt about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It mentions a hard prerequisite (ShareCut API key, Business plan) which gives some usage context, but it offers no explicit guidance on when to choose this over alternatives like list_links or get_link_analytics. The phrasing 'Read one link' implies you want a specific link, but the distinction is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the click analytics of one link: total clicks, a daily series, and breakdowns by country, device, operating system, browser and referrer. Requires a ShareCut API key (Business plan).
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | How many days of the daily series to return. Default 30. | |
| link | Yes | The link, given either as its short code (the part after sharecut.site/) or as the id returned when it was created. A full ShareCut URL is accepted too. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It openly states this is a read operation, lists the returned data elements, and discloses the API key/Business plan requirement. It does not cover rate limits or error behavior, but it gives enough for a safe read-only call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, and the core purpose is front-loaded. The second sentence adds a necessary access prerequisite. Every part is useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema covers parameter details and defaults, while the description explains what the call returns and the access requirement. Given the low complexity and lack of output schema, this is complete enough for an agent to use correctly, though error behavior and output formatting are not described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description adds only the context that analytics apply to 'one link', which reinforces the link parameter but does not add meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb ('Read') and a clear resource ('click analytics of one link'), and it enumerates the exact metrics returned. This distinguishes it from generic link tools like get_link or list_links, so the agent knows precisely what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool: whenever click analytics for a single link are needed. It also provides an explicit prerequisite (ShareCut API key on the Business plan), though it does not name alternatives or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the QR code for an existing link, ready to print. Returns the artwork saved on the link when there is one (frames, colours and logo set in the ShareCut editor), otherwise renders a plain code for its short URL. Requires a ShareCut API key (Business plan).
| Name | Required | Description | Default |
|---|---|---|---|
| link | Yes | The link, given either as its short code (the part after sharecut.site/) or as the id returned when it was created. A full ShareCut URL is accepted too. | |
| color | No | Foreground hex colour for a plain code, e.g. #2563eb. | |
| style | No | Saved artwork if any (default), or force a plain black-and-white code. | |
| format | No | Also return a PNG data URL. Applies when a plain code is rendered. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It does well by revealing that saved artwork is returned when present, otherwise a plain code is rendered, and by disclosing the API key and plan requirement. It does not describe the exact return transport, but the behavior is substantially transparent for a read-only fetch operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler. It front-loads the core purpose, explains the conditional behavior in the second sentence, and closes with the access requirement. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The definition covers the main behavioral variants, auth requirements, and the meaning of 'plain' versus saved artwork. Since there is no output schema, it would be slightly stronger if it stated the exact return format, but the wording 'QR code ... ready to print' and the format parameter sufficiently imply the result for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents every parameter clearly. The description adds useful context about stored artwork, frames, colours, and logos, but it does not need to add parameter-level meaning and does not go significantly beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource, 'Fetch the QR code for an existing link', and clearly distinguishes itself from sibling tools like create_qr by emphasizing 'existing link'. It also explains the two possible result modes, stored artwork or plain code, which removes ambiguity about what the tool returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: use it when you have an existing link and need a print-ready QR code, and it warns about the Business plan requirement. However, it does not explicitly name alternatives such as create_qr or state when this tool should not be used, leaving the routing decision mostly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the links on the account the API key belongs to: short links, link-in-bio pages and restaurant menus, with their click counts. Filter by type or by a search term, and sort by newest or by most clicked. Requires a ShareCut API key (Business plan).
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Match against short code, title, description and destination. | |
| sort | No | Newest first (default) or most clicked first. | |
| type | No | Only links of this kind. | |
| limit | No | How many to return. Default 20. | |
| offset | No | How many to skip, for paging. Default 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the authentication requirement (Business plan API key) and the data scope (links with click counts). It implies a read-only operation via the verb 'list,' and describes filtering/sorting capabilities. However, it does not explicitly state that the operation is non-mutating, nor mention rate limits or response pagination behavior, which are minor gaps given the simplicity of the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence front-loads the primary purpose and scope, and the second sentence efficiently covers filtering, sorting, and the authentication requirement. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list operation with 5 optional parameters and no output schema, the description adequately conveys the core behavior: it returns links of the specified types with their click counts, and supports filtering and sorting. It does not explicitly describe the response shape, but the mention of click counts and link types gives a sufficient hint. Given the simplicity of the tool and the absence of an output schema, this is reasonably complete; the only minor gap is not mentioning pagination behavior, though offset/limit are in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds some context by mapping 'filter by type or search term' to 'type' and 'q', and 'sort by newest or most clicked' to 'sort', but these details are already fully described in the schema enums. It does not add significantly new meaning beyond what the parameter descriptions already provide, so a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'lists the links on the account the API key belongs to,' specifying three distinct link types (short links, link-in-bio pages, restaurant menus) and that click counts are included. This is a specific verb-resource combination that clearly distinguishes it from siblings like get_link (single link) or get_link_analytics (analytics).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (listing all account links) and includes a prerequisite (requires a ShareCut API key on a Business plan). While it does not explicitly name alternatives or exclusions, the context is sufficient for an agent to distinguish it from sibling tools. The lack of explicit 'when not to use' guidance prevents a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a ShareCut short link for a URL and get a matching QR code. Unlike a static QR, this one points at the short link, so update_link can change where it goes after it has been printed, and every scan is counted (country, device, referrer). Destinations are screened with Google Safe Browsing. Requires a ShareCut API key (Business plan).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The http(s) destination to shorten. | |
| utm | No | Optional UTM parameters appended to the destination at redirect time: source, medium, campaign, term, content. The stored destination stays clean. | |
| title | No | Optional label for the link, shown in the owner dashboard. Not visible to visitors. | |
| customCode | No | Optional custom short code: lowercase letters, digits and hyphens, up to 10 characters. Fails if already taken — check_short_code tests one first. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing side effects and preconditions. It discloses the requirement of a ShareCut API key (Business plan), the Google Safe Browsing screening, the ability to later change destinations via update_link, and the fact that scans are counted. It does not explicitly state that the operation is stateful or irreversible, but its behavioral details go well beyond a generic 'create' and meaningfully inform an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: it opens with the core action and key deliverable, then flows naturally through QR behavior, analytics, safety screening, and the API key requirement. Every sentence earns its place, and nothing is redundant with the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 params, nested object, no output schema), the description covers the action, the key preconditions, the post-creation behavior, and the relevant sibling tools for verification and follow-up. It omits explicit details about the response shape or failure modes, but the absence of an output schema and the rich behavioral context keep this strong — just short of fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers all parameters (100% coverage), so the baseline is 3. The description adds useful context about UTM handling ('The stored destination stays clean'), title visibility, and customCode constraints/conflicts, which enriches understanding without repeating the schema verbatim. It doesn't fully compensate with extra field semantics, but it does add some value, matching the baseline-3 expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Create a ShareCut short link for a URL'), and clearly differentiates this tool from siblings by emphasizing the bundled QR code and analytics. It also adds the unique behavioral fact that the QR points at the short link (so update_link can retarget it) and mentions safety screening — distinguishing it from alternatives like create_qr or shorten_urls_bulk.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool versus alternatives by noting the QR code and counted-scan benefits ('every scan is counted'), and explicitly names update_link as the follow-up tool for changing destinations. It also instructs that customCode failures should be pre-checked via check_short_code, giving clear routing guidance. A 'when not to use' statement is absent, but context signals and the explicit alternative references make the usage guidance strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create up to 25 short links in one call. Each entry takes the same fields as shorten_url. Failures are reported per item, so one bad URL does not discard the rest. Requires a ShareCut API key (Business plan).
| Name | Required | Description | Default |
|---|---|---|---|
| links | Yes | The links to create. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does well by revealing that failures are reported per item, preventing one bad URL from discarding the rest, and noting the API key/plan requirement. It does not describe the exact response shape, but the per-item failure behavior is a meaningful and useful disclosure beyond basic creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each providing distinct value: the core capability and limit, the field reuse, and the failure isolation behavior. It is front-loaded and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple bulk creation tool with a single parameter, the description covers the critical context: limits, plan requirement, field reuse, and partial failure handling. The lack of an output schema is somewhat mitigated by the per-item failure note, but a bit more detail about the response format would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the 'links' array and each nested field (url, title, customCode) with 100% coverage, so the description does not need to repeat them. It does add a useful pointer that each entry takes the same fields as shorten_url, but this only slightly supplements what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Create up to 25 short links in one call') and distinguishes itself from the sibling tool shorten_url by explicitly calling out the bulk behavior. It also communicates key constraints like the 25-link limit and the shared field structure, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when this tool should be used instead of shorten_url: when multiple links need to be created at once. It also gives relevant context about the required ShareCut API key and Business plan. However, it does not explicitly say 'use this instead of shorten_url for batches,' so the routing guidance is good but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-point an existing short link at a new destination, or change its title, description or UTM parameters. This is what makes a printed QR code reusable: the code encodes the short link, so changing the destination redirects every copy already printed, shared or stuck on a wall, and the click history is kept. The new destination is screened with Google Safe Browsing. The short code itself never changes here, because changing it would break every copy already out there. Requires a ShareCut API key (Business plan).
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | The new http(s) destination. Short links only — a menu or link-in-bio page has no single destination. | |
| utm | No | UTM parameters appended at redirect time. Pass an empty object to switch UTM tracking off. | |
| link | Yes | The link, given either as its short code (the part after sharecut.site/) or as the id returned when it was created. A full ShareCut URL is accepted too. | |
| title | No | New label for the owner dashboard. | |
| description | No | New description. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it discloses meaningful behavior: changing the destination redirects all existing printed copies, click history is preserved, new destinations are screened with Google Safe Browsing, and the short code is immutable in this operation. It leaves minor gaps around response/error behavior, but the core side effects and constraints are well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main action, and every sentence earns its place: operation, real-world implication, safety screening, immutability constraint, and authentication requirement. It is detailed without being wordy or redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no annotations and no output schema, the description is unusually complete: it explains side effects, constraints, screening behavior, and the required plan. It does not mention the response shape or failure cases, but an agent has enough context to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents every parameter. The description adds only high-level framing—such as 'new destination' for url and UTM switchability—and does not materially expand on the schema's own descriptions. This matches the baseline for fully covered schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Re-point... or change') and a named resource ('existing short link'), and enumerates the mutable fields: destination, title, description, and UTM parameters. It also clarifies what the tool does not do (changing the short code), which distinguishes it from sibling operations. The title reinforces the resource without being relied upon.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a concrete use case—repurposing printed QR codes—and states the Business-plan API key prerequisite. It does not explicitly name an alternative tool for changing the short code or creating a new link, so it stops short of a full when-to-use/when-not-to-use guide. The context is clear, but exclusions are only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
check_short_codecreate_qrdelete_linkexpand_short_linkget_accountget_linkget_link_analyticsget_link_qrlist_linksshorten_urlshorten_urls_bulkupdate_linkClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Dynamic, editable QR codes + short links with scan analytics and branded QR rendering.
Create, manage and measure short links: branded domains, cookie-less analytics and QR codes
Create, edit and analyse short links and QR codes. OAuth sign-in works on the free plan.
Add one secure layer between your agents and this server.
Most tools have clearly distinct purposes with strong descriptions, but three tools (create_qr, shorten_url, get_link_qr) can all produce a QR code, which could cause misselection without careful reading. The public-versus-account split and singular-versus-bulk variants are otherwise well separated.
All tool names follow a consistent verb_noun pattern in snake_case: check_, create_, delete_, expand_, get_, list_, shorten_, update_. Composite names like get_link_analytics and shorten_urls_bulk extend the pattern predictably without mixing conventions.
With 12 tools, the server is well-scoped for a QR and short-link management API. It includes public query tools, full CRUD for links, bulk creation, QR retrieval, analytics, and account status, with no unnecessary duplication.
The core link lifecycle is covered: create, read, list, update, delete, plus QR generation, analytics, and account info. Minor gaps exist around non-link resources like link-in-bio pages or restaurant menus that are only referenced by list_links, and there is no API to edit QR artwork directly, but these are peripheral to the stated purpose.
