Publish what your agent just made to a public HTTPS link. Pass the content — a page, a report, a deck — and get a live URL that keeps working with no machine online, plus password protection, credential rotation and takedown. 8 tools. The local companion (npm i -g @servelink/serve) adds tunnels to a running dev server.
Return the account's plan, entitlement, live tunnels, and owned links, plus storage/transfer/publish usage. Owned links are unlimited by count.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description describes a pure read/retrieval action ('Return the account's ...'), but the annotations set destructiveHint=true, which directly contradicts that read-only nature. This is a serious inconsistency that could lead an agent to believe calling it has destructive side effects.
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 short sentences; the first front-loads the purpose and contents, and the second adds a useful clarifying detail about owned-link count limits. No words are wasted.
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 zero-parameter status tool, the description covers the main response categories but no output schema is provided, so the exact response shape is unverified. The contradictory destructiveHint in annotations also slightly undermines completeness, though the description itself is clear.
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?
There are no parameters in the schema and no required fields, so there is nothing for the description to clarify. Baseline 4 applies because parameter semantics are moot.
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 begins with the specific verb 'Return' and enumerates exactly what is provided: the account's plan, entitlement, live tunnels, owned links, and usage metrics. This clearly positions it as the read-only status tool among siblings like revoke_link and unprotect_link, which are mutation actions.
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 no explicit when-to-use or alternative guidance, leaving the agent to infer that this is the generic account overview. Even though the 0-parameter signature makes it trivially callable, there is no statement distinguishing it from sibling tools like links or serve for account-related queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all owned links with residency, protection, and published-artifact info, plus live-tunnel capacity and storage/transfer/publish usage. Owned links are unlimited by count.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description 'List all owned links' depicts a non-destructive read operation, yet annotations set destructiveHint=true. The description provides no caveats to explain destructive behavior, and readOnlyHint=true makes the contradiction more acute. Per rubric this is an annotation contradiction.
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?
A single well-structured sentence front-loads the verb and resource, then packs relevant result categories. Every clause contributes; 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?
Without an output schema, the description enumerates key result facets and resource scope. It does not specify exact response format or pagination, but for a no-parameter listing tool this is reasonably complete. The destructive annotation inconsistency slightly undermines completeness but is already penalized in behavioral_transparency.
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 (schema is an empty object), so there is no parameter ambiguity for the description to resolve. Baseline 4 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?
Description opens with a specific verb and resource: 'List all owned links'. It enumerates the returned dimensions (residency, protection, published-artifact info, live-tunnel capacity, storage/transfer/publish usage) and adds the count-limitation caveat. This clearly differentiates it from mutation siblings like protect_link and revoke_link.
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?
No explicit when-to-use or alternative guidance appears. The phrase 'List all owned links' implies a read-only inventory use case, but the description does not tell the agent when to choose this over account_status or serve. This is usable but leaves routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enable capability-token protection on an owned link. Returns a share URL that carries the capability — anyone holding that URL can view the link. A viewer secret code is also set, but it is shown only in the serve console, never here.
| Name | Required | Description | Default |
|---|---|---|---|
| ttl | No | Optional TTL duration (e.g. 24h, 7d). | |
| label | No | Label of the link to protect (optional; defaults to first active link). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description adds meaningful behavioral detail: the returned URL carries the capability, anyone holding it can view the link, and a viewer secret code is set but only visible in the serve console, never returned here. It does not contradict the destructiveHint annotation, though it does not elaborate on what destructive side effects may occur.
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 serving a purpose: the action, the primary return value with an important security caveat, and the behavior of the secret code. No redundant or extraneous wording.
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?
With no output schema, the description adequately conveys the main return value and what is not returned. However, it omits details about the destructive nature hinted by the annotation, how the 'owned link' requirement is enforced, and how the viewer secret code can be retrieved in the serve console.
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 both ttl and label. The description itself adds no parameter-level meaning beyond implying the link must be owned and active for the label default behavior; it does not discuss TTL at all.
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 action ('Enable capability-token protection') and the resource ('an owned link'), and it clarifies the return value (a capability-bearing share URL). It is distinguishable from siblings like unprotect_link or revoke_link by the 'protection' framing, though it does not explicitly name the alternatives.
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 this is used when a user owns a link and wants to enable capability-token protection, and it warns that anyone holding the returned URL can view the link. However, it never explicitly says when to choose this over unprotect_link or revoke_link, and no exclusions or prerequisites are articulated beyond 'owned link'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Regenerate the capability token for a protected link and reset its timer. Returns a new share URL; the previous one stops working. The regenerated viewer secret code is shown only in the serve console, never here.
| Name | Required | Description | Default |
|---|---|---|---|
| ttl | No | Optional updated TTL duration (e.g. 24h, 7d). | |
| label | Yes | Label of the link to renew. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal destructive and non-read-only behavior, so the description adds valuable context beyond them: 'the previous one stops working' and 'the regenerated viewer secret code is shown only in the serve console, never here.' This clarifies side effects and security-sensitive return 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?
Three sentences with no filler. The primary action is front-loaded, followed by the key consequence, then a critical security caveat. 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?
For a destructive operation with no output schema, the description covers the return value, the invalidation side effect, and the secret-code limitation. Minor gaps remain, such as what happens if the label does not refer to a protected link, but overall the agent has enough to call it 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 description coverage is 100%, so the schema already documents both label and ttl. The description reinforces the timer-reset concept tied to ttl, but does not add meaning beyond the schema. 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 names a specific verb and resource: 'Regenerate the capability token for a protected link and reset its timer.' It clearly distinguishes this from revoke, protect/unprotect, and serve by describing renewal, return of a new share URL, and invalidation of the previous one.
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?
Usage is implied rather than explicit: the tool is for regenerating a link's token and extending its timer, but there is no explicit 'use this when...' or contrast with revoke_link or protect_link. The behavior makes the use case fairly clear, but the description does not provide direct routing guidance among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Revoke the active secret code and capability token while keeping owner access intact.
| Name | Required | Description | Default |
|---|---|---|---|
| label | Yes | Label of the link whose credentials should be revoked. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the destructive nature is known. The description adds valuable context beyond that: exactly what gets revoked (secret code and capability token) and what is preserved (owner access). This clarifies the blast radius of the destructive action.
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?
A single sentence that front-loads the core action and immediately states the key qualifier about owner access. There is no filler, repetition, or irrelevant detail; every word contributes to the tool's meaning.
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 one-parameter destructive tool, the description is complete: it states what is revoked, what is preserved, and the schema fully documents the required label. No output schema is present, but a revocation tool's return value is not essential for correct invocation. The annotations cover the remaining safety 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%; the label parameter is already well documented as 'Label of the link whose credentials should be revoked.' The tool description adds no additional parameter-level detail, but it does reinforce the purpose of the parameter by tying it to credential revocation. 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 names a specific verb ('Revoke') and resource ('active secret code and capability token'), and adds a boundary condition ('keeping owner access intact') that distinguishes it from broader access-revocation siblings like stop_remote. It is immediately clear what this tool does and what it uniquely handles.
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 clear context for when to use the tool: when you need to revoke a link's active credentials without removing owner access. It does not explicitly name alternatives such as renew_link or stop_remote, but the scoping phrase provides enough guidance for a competent agent to select it over those alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Publish inline content to a public HTTPS URL that serves from the cloud. Pass content (text) or content_base64 (binary), plus filename. Set name to request a specific link. The link stays live with no machine online until stop_remote is called.
| Name | Required | Description | Default |
|---|---|---|---|
| ttl | No | Optional protection TTL (e.g. 24h, 7d). | |
| name | No | Optional requested subdomain; a fresh generated link is used if omitted. | |
| content | No | Text content of the file to publish. | |
| protect | No | If true, enables capability token + secret code protection on the link. | |
| replace | No | true replaces an existing published artifact at the requested name (Pro); false returns a residency_conflict error | |
| filename | No | Filename / entry name for the artifact (e.g. index.html, deck.html). Defaults to index.html. | |
| content_base64 | No | Base64-encoded binary content of the file to publish (use instead of content for binaries). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal readOnly=false, idempotent=true, and destructive=true, so the safety profile is structured. The description adds genuinely useful behavioral context: the published link remains live in the cloud with no machine online until stop_remote is called. It does not detail destructive replacement semantics, but the replace parameter describes that and the annotation already flags destructiveness.
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 tight sentences with no filler. The purpose is front-loaded, the parameter usage is condensed into one instructive sentence, and the lifecycle caveat is placed at the end where it reinforces why this tool exists relative to stop_remote.
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 creation tool with 7 self-documenting parameters and a rich annotation block, the description covers the essential behavioral context: public URL, cloud hosting, content variants, optional naming, and persistence until stop_remote is called. The lack of an output schema means return details are not explicitly stated, but the public URL and link concept make the primary return value clear enough.
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 relational meaning by explaining that content is for text, content_base64 is for binary, and filename accompanies the content; it also notes that name controls the requested subdomain. This goes slightly beyond raw schema fields, though it does not explain defaults or the ttl/protect interaction.
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 verb and resource: 'Publish inline content to a public HTTPS URL that serves from the cloud.' This immediately distinguishes serve from sibling management tools like stop_remote, renew_link, and protect_link, and makes its role as a creation/deployment tool obvious.
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 a practical usage pattern: pass content for text or content_base64 for binary, supply a filename, and set name to request a specific link. It also names stop_remote as the counterpart for keeping links alive. It does not explicitly enumerate when to use protect_link, renew_link, or revoke_link, but those are reasonably inferable from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unpublish a remote link, deleting its stored bytes immediately and returning the link to local residency.
| Name | Required | Description | Default |
|---|---|---|---|
| label | Yes | Label of the published (remote) link to unpublish. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this operation destructive and not read-only. The description adds valuable behavioral detail beyond the annotations: it explicitly states that stored bytes are deleted immediately and that the link returns to local residency. This gives the agent a clearer understanding of side effects.
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 a single, tightly worded sentence that leads with the primary action and then supplies the most important behavioral details. Every word contributes meaning, and there is no redundancy with the annotations or schema.
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 destructive, single-parameter operation, the description provides adequate context: what it does, what it deletes, and what the resulting state is. There is no output schema, so return-value documentation would be nice, but the core decision to invoke the tool and expectation of effect are sufficiently covered.
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 input schema fully documents the single 'label' parameter with a clear description, so the schema carries the burden. The tool description does not add any additional parameter-level semantics, but none are really needed given 100% schema coverage.
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 begins with a specific verb and resource: 'Unpublish a remote link.' It further clarifies the effect ('returning the link to local residency'), which distinguishes this from sibling tools like revoke_link or unprotect_link. The purpose is unambiguous and specific.
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 the tool should be used when a remote link should be unpublished and returned to local residency. However, it does not explicitly discuss when to prefer this tool over siblings such as revoke_link or unprotect_link, nor does it provide any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear protection on an owned link, returning it to public access.
| Name | Required | Description | Default |
|---|---|---|---|
| label | Yes | Label of the link to unprotect. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal destructive behavior (destructiveHint: true), and the description adds valuable context beyond that: the operation only applies to owned links and results in public access. It is consistent with the annotations and clarifies the real-world effect.
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 a single, well-structured sentence with no filler. It front-loads the action, states the target resource, includes a precondition ('owned'), and explains the outcome ('public access').
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, no-output-schema tool with strong annotations, the description covers the essential behavior and outcome. The only minor gap is the lack of explicit routing between unprotect_link, protect_link, and revoke_link, but the core calling context is sufficiently clear.
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 the label parameter already described as 'Label of the link to unprotect.' The description adds context about ownership and public access but does not add new parameter-level meaning, 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 uses a specific verb ('Clear') and names the resource ('an owned link') plus the resulting state ('public access'). This clearly distinguishes it from protect_link and revoke_link, even without naming them.
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 to use it: when you want to remove protection from a link you own and make it public. However, it does not explicitly mention alternatives or exclusions, such as 'use protect_link for the reverse' or contrast with revoke_link.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming 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 or an account that owns the GitHub organization, then choose Claim with GitHub.
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!
Add one secure layer between your agents and this server.
The lifecycle tools (serve, stop_remote, protect_link, renew_link, revoke_link, unprotect_link) are clearly distinct. The only ambiguity is between account_status and links, which both report usage, live tunnels, and owned-link counts, though one is an account-level summary and the other a detailed link listing.
Most tools follow a clear lowercase verb_noun pattern (protect_link, renew_link, revoke_link, unprotect_link, stop_remote). The main inconsistency is that query tools are nouns (account_status, links) and serve is a bare verb, but the style remains readable and predictable.
Eight tools is well-scoped for a serve-and-link-management server: one publish action, one unpublish action, four protection lifecycle operations, and two query/status tools. Each tool earns its place without bloat.
The set covers the full remote-link lifecycle: publish content, stop/unpublish it, list links, check account status, and protect/renew/revoke/unprotect access. No obvious dead ends or critical missing operations for the stated purpose.