Skip to main content
Glama
Sign In

Nas.com

by com.nas
OverviewDiscussionsAdmin

Delete Session

delete_session
Destructive

Delete a one-on-one session. Requires confirm set to DELETE. 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": "delete_session"
  }
}

Input Schema

NameRequiredDescriptionDefault
confirmNoExplicit confirmation for this write. Pass the exact literal this tool requires (for example DELETE) only after the user approves the action.
sessionIdYesOne-to-one session product ID, from a Nas.com product listing.
communityIdYesNas.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.

  1. Changed3 schema fields changed
    • 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."
  2. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true, but the description adds substantial behavior: the exact confirmation literal DELETE is required before the write, a permission gate must be called first, FREE-tier businesses are blocked regardless of feature rows, and grace-period warnings with a resubscribe link must be surfaced. None of that is inferable from the annotations or schema.

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?

Front-loaded with the action, then the confirmation requirement, then the permission gating, which is the right precedence order. It is dense but nearly every clause carries an operational constraint; the only cost is a slightly run-on final sentence chaining warnings, resubscribe links, and the abort condition.

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?

For a destructive mutation with no output schema and a cross-tool prerequisite, the description covers the confirmation literal, the mandatory access check, the tier restriction, and the blocked-proceed case. An agent has everything needed to decide whether to call it and how to sequence the prerequisite call.

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 baseline is 3; however the description pins down the otherwise ambiguous confirm parameter by naming DELETE as the required literal, resolving the schema's looser "for example DELETE" phrasing. communityId and sessionId semantics are left entirely to the schema, which already documents them well.

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?

States a specific verb and resource: "Delete a one-on-one session." The "one-on-one" qualifier narrows scope usefully against unrelated session siblings like create_session or list_session_slots, though it never explicitly contrasts with cancel_session_booking, which an agent might reasonably consider for a session-related removal.

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

Usage Guidelines3/5

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

Wait—reconsider. Actually the guidance is strong: it gives an explicit prerequisite (check_business_tool_access), an explicit exclusion (FREE businesses cannot use this tool), and an explicit stop condition (never proceed when access is blocked). That is when-to-use and when-not-to-use plus the gating tool. Score 5.

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

All Nas.com toolsInspect
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.

Resources