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.
Account-level state: plan, entitlement, and how much of the storage, transfer and publish allowance is used. Use this to check what the account may do or whether it is near a limit. For the links themselves — labels, residency, protection state — use links instead. 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 annotations already mark this as read-only and non-destructive. The description adds useful context about the kind of state surfaced ('plan, entitlement, storage/transfer/publish allowance'), making the read-only nature concrete. There is no contradiction with the annotations.
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 each earn their place: the first defines scope, the second states the use case, and the third routes the agent away from link-level questions. No filler or redundancy.
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, read-only status tool with no output schema, the description plus annotations fully cover what the agent needs: what the tool reports, when to use it, and how it differs from the sibling tool. Nothing essential 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?
The tool has zero parameters, so the input schema imposes no burden. The description adds contextual meaning by explaining what the state covers, which is sufficient for an agent to know this requires no inputs.
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 resource ('account-level state') and a clear purpose: reporting plan, entitlement, and allowance usage. It also distinguishes itself from the sibling 'links' tool, so an agent can immediately tell what this tool is about.
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 to use this tool ('check what the account may do or whether it is near a limit') and points to the alternative for link-specific data ('use links instead'). The distinction between account-level and link-level concerns is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inventory of every owned link, one record each: residency, protection state, and published-artifact detail. Use this to see what is currently published, or to find a label to act on. Live-tunnel capacity and usage totals come along as context. For plan, entitlement and quota headroom, use account_status instead. 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds useful context beyond that: the inventory scope, included context fields (live-tunnel capacity and usage totals), and the unlimited-count property. No contradictions 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences, each earning its place: what the inventory contains, when to use it, when to use the alternative, and a relevant count constraint. The core purpose is front-loaded.
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 parameterless read-only list tool, the description fully covers what the agent gets, when to call it, and what not to use it for. It even describes the record contents sufficiently in lieu of an output 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?
The tool has zero parameters and schema coverage is 100%, so the baseline is 4. The description adds no parameter details, but none are needed.
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: an inventory of every owned link with per-record fields (residency, protection state, published-artifact detail). It is clearly distinguishable from siblings like account_status, 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?
Explicitly says when to use it ('to see what is currently published, or to find a label to act on') and names the alternative for related but different needs ('For plan, entitlement and quota headroom, use account_status instead').
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?
The description adds meaningful behavior beyond the annotations: the returned URL carries the capability, anyone holding it can view the link, and the viewer secret code is set but never exposed here. This is especially useful because the tool has no output schema and the annotations only indicate mutating, non-idempotent, non-destructive 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 three tight sentences with no filler: it states the action, then the output behavior, then an important security note about the secret code. It is front-loaded and structured for quick comprehension.
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 2-parameter, no-output-schema tool, the description covers the essential outcome (the share URL), the access implications, and the visibility limitation of the secret code. Minor gaps include not clarifying whether protection can be applied to a specific non-active link, but the optional label parameter and default behavior are already 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 both ttl and label are already documented in the input schema. The description adds context like "owned link" and the default-to-first-active-link behavior, but it does not meaningfully elaborate on parameter formats or constraints 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 states a specific verb and resource: "Enable capability-token protection on an owned link." It also clarifies the key behavior—returns a share URL that grants anyone holding it view access—which clearly distinguishes it from siblings like unprotect_link, revoke_link, and renew_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?
The description implies the tool is used when you own a link and want to enable capability-token protection, and it notes the label defaults to the first active link. However, it does not explicitly state when to avoid this tool, mention prerequisites, or compare it with alternatives such as unprotect_link or revoke_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?
The description proactively discloses important behavioral consequences: the previous share URL stops working and the regenerated viewer secret code is never shown here. Annotations only provide generic hints, so this contextual detail is valuable and not contradictory.
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 deliver the action, return value, side effect, and a security-relevant caveat. No filler or redundant restatement of the 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?
With no output schema, the description adequately explains the return value (new share URL) and the key side effect (old URL stops working). It could mention what happens when the label does not match an existing protected link, but that is a minor gap.
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 label and ttl are already documented in the input schema. The description adds no new parameter-level meaning beyond reinforcing that ttl updates the timer, which is already stated.
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 and resource: 'Regenerate the capability token for a protected link and reset its timer.' It also explains the key behavioral outcome—returns a new share URL and invalidates the previous one—which clearly separates this from sibling tools like protect_link or 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?
The description implies the tool should be used when an existing protected link needs its token regenerated or its timer reset, but it never explicitly states when to choose this over protect_link or revoke_link. There are no exclusions or alternative routing cues, leaving some inference to the agent.
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?
The description adds meaningful detail beyond the destructiveHint annotation by specifying exactly what gets destroyed (active secret code and capability token) and what is preserved (owner access). This helps the agent anticipate the consequence of invoking the tool, though it does not state reversibility or implications for existing sessions.
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 delivers the action, the target, and the key side effect with no filler. Everything included is necessary and 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?
For a simple one-parameter, destructive tool with no output schema, the description is sufficient for an agent to invoke it correctly. It identifies the label input, the action, and the outcome regarding owner access, leaving no critical ambiguity.
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 already provides 100% coverage for the single parameter, describing it as the label of the link whose credentials should be revoked. The description does not add extra parameter-level detail such as formats, examples, or allowed values, so the schema carries the full burden.
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 ('revoke'), the target resource ('the active secret code and capability token'), and the preservation effect ('keeping owner access intact'). This makes it easily distinguibile from siblings like renew_link or protect_link, since it is uniquely about invalidating credentials.
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 phrase 'revoke the active secret code and capability token while keeping owner access intact' provides clear context for when this should be used. It does not explicitly name alternatives or exclusions, but the intended scenario is obvious: the agent should call this when link credentials need to be revoked without affecting owner privileges.
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 mark the tool as non-read-only, idempotent, and non-destructive. The description adds the key behavioral trait that the link persists in the cloud with no machine online until stop_remote is called, which is not inferable from the schema or annotations. It does not contradict the annotations.
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 cover purpose, payload requirements, and lifecycle behavior. The most important facts are front-loaded, and every sentence earns its place without redundancy.
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 seven optional parameters and no output schema, the description provides enough context for selection and invocation: it clarifies the expected content parameter, optional name behavior, and persistence until stop_remote. It does not mention ttl, protect, or replace, but the schema fully documents those, so no necessary invocation detail 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 coverage is 100%, so the schema already documents all seven parameters. The description adds a useful grouping of content vs content_base64, filename, and name-to-link behavior, but it largely restates what the schema says. There is no need for the description to compensate for missing schema documentation.
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-resource pair: 'Publish inline content to a public HTTPS URL.' This clearly identifies the tool as the publishing action and distinguishes it from siblings like stop_remote, links, and protect_link, which handle lifecycle or listing rather than creation.
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 operational context: pass content or content_base64, optionally request a name, and the artifact remains live until stop_remote is called. This signals when serve is appropriate versus teardown tools, though it does not explicitly enumerate exclusions or alternatives such as protect_link for protection workflows.
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?
The description adds concrete behavioral detail beyond the annotations by specifying that stored bytes are deleted immediately and the link becomes local residency again. This complements the destructiveHint=true and idempotentHint=true annotations, giving the agent a clearer picture of consequences without contradicting any metadata.
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 front-loads the core action ('Unpublish a remote link') before explaining the immediate consequences. Every phrase adds value, with no redundant or filler content.
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 single-parameter tool with strong annotations (destructive, idempotent), the description covers the key state change and effect. It does not describe the return value or response, but the absence of an output schema reduces that burden. Slight gap remains around what 'local residency' means in practice, but it is not critical 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 input schema already provides 100% coverage for the single 'label' parameter, describing it as the label of the published remote link to unpublish. The tool description does not add further meaning about label format, validation, or default behavior, so it stays at the baseline for complete 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 uses a specific verb ('Unpublish') and clearly identifies the resource (a remote link), and goes further to state the precise effect: deleting stored bytes and returning to local residency. This distinguishes it from sibling tools like revoke_link or unprotect_link, which target different states or permissions.
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 implicitly conveys when to use the tool: when a remote link needs to be unpublished and its remote bytes deleted. However, it does not explicitly state any exclusions or point to alternatives among the sibling tools (e.g., revoke_link, unprotect_link), leaving the choice of tool to inference rather than direct guidance.
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?
The annotations already signal destructive and non-idempotent behavior. The description adds meaningful context beyond the annotations by stating the concrete effect on the link: protection is cleared and it becomes public. It also implies an ownership requirement, which is useful behavioral context.
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, tightly worded sentence that front-loads the verb and object, states the outcome, and includes the ownership qualifier. There is no redundant or filler content.
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 tool with no output schema, the description covers the action, the precondition (owned link), and the result (public access). It could be slightly more explicit about reversibility or behavior when the link is not protected, but overall it is sufficient 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 input schema covers the only parameter, label, with a clear description. The tool description does not add parameter-level detail, but schema coverage is 100%, 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 clearly identifies the action (clear protection), the object (an owned link), and the outcome (returning it to public access). It distinguishes itself from siblings like protect_link and revoke_link by specifying the result, so an agent can tell them apart without opening other definitions.
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 phrase 'on an owned link' sets the relevant context: the tool applies to links the user owns, and 'returning it to public access' implies the link is currently protected. It does not explicitly mention alternatives such as revoke_link, but the usage context is clear enough for correct selection.
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.
account_statuslinksprotect_linkrenew_linkrevoke_linkservestop_remoteunprotect_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!
Add one secure layer between your agents and this server.
Most tools target distinct actions: account_status is account-level, links is inventory, serve/stop_remote are publish/unpublish, and the protection tools form a clear lifecycle. The only possible confusion is revoke_link versus unprotect_link, since both invalidate access in different ways, but the descriptions distinguish them well.
The link-mutation tools follow a consistent verb_noun pattern: protect_link, renew_link, revoke_link, unprotect_link. However, account_status and links are noun-only, serve is a bare verb, and stop_remote uses an inconsistent object, so the naming conventions are mixed.
Eight tools is well-scoped for this server's purpose: account awareness, link inventory, publishing, unpublishing, and protection management. Each tool serves a distinct function and none feel redundant.
The core lifecycle is covered: publish via serve, unpublish via stop_remote, inventory via links, and full protection management via protect/renew/revoke/unprotect. Minor gaps exist such as no explicit update-to-existing-link operation, but agents can likely work around these.