Skip to main content
Glama

get_suprsend_tenant

Read-onlyDestructiveIdempotent

Retrieve a tenant's settings, branding URLs, contact info, and custom fields using tenant_id. Useful for inspecting full tenant state in multi-tenant SaaS deployments.

Instructions

Get a tenant's settings, branding metadata, and custom properties by tenant_id. Tenants are sub-accounts of a workspace, modeling end-customers in multi-tenant SaaS deployments.

When to use: the user references a tenant by id and you need its full state.

When NOT to use:

  • To enumerate all tenants — use get_suprsend_tenants.

  • For tenant-level preference defaults — use get_tenant_default_preference.

Returns: the tenant's settings (branding URLs, contact info, custom fields).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tenant_idYesThe tenant_id of the tenant to get.
workspaceNoSuprSend workspace to get the tenant from.
Behavior1/5

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

Description describes a read-only get operation, but annotations include destructiveHint=true, which contradicts the non-destructive nature implied. The description does not address this contradiction or explain any potential 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.

Conciseness5/5

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

Concise with clear sections: purpose, usage guidelines, returns. Only 4 sentences, no fluff, and front-loaded with the core functionality.

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?

Covers purpose, usage context, and return values adequately for a simple get tool with full schema coverage. However, lack of clarification on the destructiveHint contradiction leaves a gap in behavioral understanding.

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 coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema; it only mentions 'by tenant_id' which aligns with the required parameter, but no additional details on format or behavior.

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?

The description clearly states 'Get a tenant's settings, branding metadata, and custom properties by tenant_id', specifying the verb and resource, and distinguishes from siblings like get_suprsend_tenants and get_tenant_default_preference by mentioning the identifier.

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?

Explicitly includes 'When to use' and 'When NOT to use' sections, naming alternatives (get_suprsend_tenants for enumeration, get_tenant_default_preference for defaults), providing clear context for tool selection.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/suprsend/cli'

If you have feedback or need assistance with the MCP directory API, please join our Discord server