Skip to main content
Glama
nerdit-ai

Nerdit

Official
by nerdit-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

unshare_service

Stops a deployed app from answering at its hosted URL by removing its share. Idempotent removal returns a receipt indicating whether the share was removed.

Instructions

Use when: an app should stop being reachable at its hosted URL.

    The URL stops answering on the next request (the tunnel re-reads the row
    per stream — there is no cache to wait out). Idempotent: removing a
    share that does not exist is a success returning ``removed: false``,
    never an error. The response is the removal receipt
    (``{service_name, removed}``), not a share view — read ``share_service``
    or ``get_service`` for the state of a share that still exists.

Input Schema

NameRequiredDescriptionDefault
nameYesName (or row id) of an existing deployed app — only kind 'service' can be exposed: ``share_service``/``add_domain`` refuse a model or database with 422 ``*.kind_unsupported``, while the remove tools just find nothing to undo.
idempotency_keyNoCaller-chosen key: a retry with the same key replays the first result instead of acting twice. Omit and a fresh key is minted per call, so each call acts.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

No annotations exist, so the description carries the full burden and does so well: it states the effect latency ('stops answering on the next request… there is no cache to wait out'), declares idempotency and the exact non-error semantics of removing a non-existent share (removed: false), and describes the response shape as a receipt rather than a share view.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The 'Use when:' opening front-loads the trigger, and the remaining sentences each carry a distinct fact (latency, idempotency, return shape). The parenthetical about the tunnel re-reading the row per stream is slightly over-detailed but still justifies 'no cache to wait out'.

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

Completeness5/5

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

With no output schema, the description supplies the return contract (`{service_name, removed}`) itself, plus failure semantics and effect timing — everything needed to call the tool and interpret the result. Nothing material for a 2-parameter unshare operation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both `name` (including the kind='service' constraint and 422 behavior) and `idempotency_key` (replay semantics) are already fully documented in the schema. The description adds only the `service_name` field name from the response and otherwise repeats the idempotency idea — baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb+resource+effect: stop an app being reachable at its hosted URL. That is clearly distinct from share_service (add), remove_service (delete the app) and remove_domain (remove a custom domain), all of which are siblings an agent could otherwise conflate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Opens with an explicit trigger ('Use when: an app should stop being reachable at its hosted URL') and points to share_service/get_service for reading state after removal. It does not explicitly exclude the neighboring remove_service or remove_domain, which is the main remaining ambiguity for an agent choosing among the removal tools.

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

Deploy Server

Other Tools