Skip to main content
Glama

Brand Asset Management

asset_manage
Destructive

Brand assets (logos, banners, profile photos) on an org, workspace, share, or user: upload, delete. Destructive: delete. Reads are on asset.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYesOperation. Use 'describe' for full action reference.
contentNoPlain text content (e.g. SVG).
asset_idNoAsset ID or name.
metadataNoAdditional metadata as JSON array string.
entity_idNoEntity ID (optional for user).
file_nameNoOriginal file name.
asset_typeNoAsset type key (e.g. 'logo', 'banner', 'photo').
entity_typeNoEntity type.
file_base64NoBase64-encoded binary content.
content_typeNoMIME type (default application/octet-stream).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and openWorldHint=true, but the description adds precision annotations cannot: it pinpoints that `delete` specifically is the destructive path, leaving `upload` non-destructive-by-capability. It stops short of describing what deletion removes (asset only vs. referencing entities) or any auth/permission requirements.

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?

Three short clauses, front-loaded with the resource and scope, followed by the destructive-action warning and the sibling pointer. No filler and nothing buried.

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 10-parameter, multi-action tool with no output schema, the description covers scope, entity types, the destructive action, and the read alternative. The notable omission is the `describe` action, which the schema itself surfaces and the description never mentions.

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 all 10 parameters are already documented in the schema, and every field carries its own description. The tool description adds no parameter-level meaning beyond that, so the baseline applies.

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 the resource (brand assets: logos, banners, profile photos), the scope (org, workspace, share, user), and the two mutating verbs (upload, delete). It also explicitly distinguishes itself from the read-only sibling `asset`, so an agent can route without opening either schema.

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?

States the conditional split clearly: writes belong here, 'Reads are on `asset`.' It also flags which action is destructive. It gives no guidance on the third action (`describe`) or on when a given entity_type should be chosen over another.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources