Skip to main content
Glama

count assets

assets_count
Read-only

Count accessible organization assets that match project, user, search text, or media type filters and exclude deleted ones; returns only the total number.

Instructions

Count the assets you can access in the current organization that match projectId, userId, searchQuery and types, the same filters as assets_list; filters combine, and deleted assets are not counted. Use it when you only need how many; use assets_list to see, pick or page through assets. Returns a bare number, not asset records. Omit sortBy, limit and cursor: they do not change the count, but they are still validated, so a limit outside 1 to 100 fails the call.

Input Schema

NameRequiredDescriptionDefault
limitNoNo effect on the count; omit it. If sent, it must be an integer from 1 to 100 or the call fails validation.
typesNoOnly these media types: VIDEO, AUDIO or IMAGE, as one value or a list; an asset of any listed type matches.
cursorNoNo effect on the count; omit it.
sortByNoNo effect on the count; omit it.
userIdNoOnly assets created by this user: a user UUID.
projectIdNoOnly assets attached to this project: a project UUID from projects_list or projects_create.
searchQueryNoCase-insensitive text matched anywhere in the asset name.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv0.2.4
    • changedInput schema / properties / cursor / description
      Previous value: -"Ignored when counting."New value: +"No effect on the count; omit it."
    • changedInput schema / properties / limit / description
      Previous value: -"Ignored when counting."New value: +"No effect on the count; omit it. If sent, it must be an integer from 1 to 100 or the call fails validation."
    • changedInput schema / properties / projectId / description
      Previous value: -"Only assets attached to this project (an id from projects_list or projects_create)."New value: +"Only assets attached to this project: a project UUID from projects_list or projects_create."
    • changedInput schema / properties / searchQuery / description
      Previous value: -"Text to match against names."New value: +"Case-insensitive text matched anywhere in the asset name."
    • changedInput schema / properties / sortBy / description
      Previous value: -"Sort order, such as dateDesc for newest first."New value: +"No effect on the count; omit it."
    • changedInput schema / properties / types / description
      Previous value: -"Only these media types: VIDEO, AUDIO or IMAGE, as one value or a list."New value: +"Only these media types: VIDEO, AUDIO or IMAGE, as one value or a list; an asset of any listed type matches."
    • changedInput schema / properties / userId / description
      Previous value: -"Only assets created by this user id."New value: +"Only assets created by this user: a user UUID."
  2. Changed7 schema fields changed
    • addedInput schema / properties / cursor / description
      Added value: +"Ignored when counting."
    • addedInput schema / properties / limit / description
      Added value: +"Ignored when counting."
    • addedInput schema / properties / projectId / description
      Added value: +"Only assets attached to this project (an id from projects_list or projects_create)."
    • addedInput schema / properties / searchQuery / description
      Added value: +"Text to match against names."
    • addedInput schema / properties / sortBy / description
      Added value: +"Sort order, such as dateDesc for newest first."
    • addedInput schema / properties / types / description
      Added value: +"Only these media types: VIDEO, AUDIO or IMAGE, as one value or a list."
    • addedInput schema / properties / userId / description
      Added value: +"Only assets created by this user id."
  3. Addedv0.1.5

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already establish a safe read operation, but the description adds real behavioral context: deleted assets are excluded from the count, filters combine conjunctively, and passing a limit outside 1-100 causes a validation failure. That last point is a genuine trap the annotations don't reveal. It doesn't discuss permission scoping beyond 'you can access', which keeps it just under a 5.

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 sentences, front-loaded with purpose, then the alternative, then the return type and the parameter trap. Nothing is wasted and the ordering mirrors what an agent needs to decide before calling.

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?

There is no output schema, and the description compensates by saying it returns a bare number rather than records. All seven parameters are documented in the schema, no parameters are required, and the description covers the non-obvious validated-but-ignored behavior, so an agent can call this correctly without further inference.

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, but the description adds the combination rule (multiple filters AND together) and the no-effect/validated distinction for sortBy, limit and cursor, which the schema states per-parameter but never as a coherent rule. That is useful meaning beyond the schema's field-by-field text.

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?

Opens with a specific verb and resource ('Count the assets you can access in the current organization') and scopes it to the same filter set as assets_list. It states the return type ('a bare number, not asset records'), which removes any ambiguity about whether this is a listing tool.

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 routes between the two siblings: 'Use it when you only need how many; use assets_list to see, pick or page through assets.' It also gives a when-not rule for pagination/sort parameters, warning that they are validated even though they have no effect.

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