Nas.com

Unpublish Session

unpublish_session

Destructive

Unpublish a one-on-one session. Requires confirm set to UNPUBLISH. Before offering this action or requesting its inputs, check business permissions. FREE businesses cannot use this tool, regardless of individual feature rows. Call check_business_tool_access before collecting inputs. Show any grace-period warning and verified resubscribe link before continuing, and never proceed when access is blocked.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "communityId": "<communityId>",
      "sessionId": "<sessionId>"
    },
    "name": "unpublish_session"
  }
}

Input Schema

Name	Required	Description
`confirm`	No	Explicit confirmation for this write. Pass the exact literal this tool requires (for example DELETE) only after the user approves the action.
`sessionId`	Yes	One-to-one session product ID, from a Nas.com product listing.
`communityId`	Yes	Nas.com business (community) ID. Use an ID returned by list_businesses or another Nas.com tool; never invent one.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 10, 2026

addedInput schema / properties / communityId / description

Added value: +"Nas.com business (community) ID. Use an ID returned by list_businesses or another Nas.com tool; never invent one."

addedInput schema / properties / confirm / description

Added value: +"Explicit confirmation for this write. Pass the exact literal this tool requires (for example DELETE) only after the user approves the action."

addedInput schema / properties / sessionId / description

Added value: +"One-to-one session product ID, from a Nas.com product listing."

First observedNov 10, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds substantial context beyond them: the exact confirmation literal 'UNPUBLISH', business-tier gating that overrides individual feature flags, a grace-period warning plus verified resubscribe link that must be shown, and an explicit stop condition. These are operational behaviors no annotation or schema field conveys.

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?

Four sentences, front-loaded with the action, then the confirmation literal, then the gating workflow. Every sentence carries a constraint the agent must obey; the sequencing is slightly procedural rather than strict priority order (the permissions check arguably precedes the confirm literal), but there is no filler.

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

Completeness4/5

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

For a destructive, no-output-schema mutation, the definition covers confirmation, entitlement gating, warning display, and abort conditions, which is most of what an agent needs. It does not say what happens to existing bookings on the session after unpublishing, the one residual gap for a destructive operation.

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

Parameters4/5

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 three parameters and the baseline would be 3. The description earns the bump by resolving the one genuine ambiguity: the schema's confirm field says only 'for example DELETE', while the description pins the actual required literal to 'UNPUBLISH' for this tool.

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

Purpose4/5

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, 'Unpublish a one-on-one session,' which separates it from publish_session and from the other unpublish_* siblings (event, challenge, folder_product, etc.) by resource type. It stops short of naming any sibling explicitly, so the differentiation comes from the noun alone rather than from a stated contrast.

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

Usage Guidelines5/5

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

It gives explicit preconditions and a named routing target: 'check business permissions,' 'Call check_business_tool_access before collecting inputs,' and 'never proceed when access is blocked.' It also states an exclusion ('FREE businesses cannot use this tool, regardless of individual feature rows'), which is exactly the when-not guidance an agent needs before offering the action.

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

All Nas.com tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.