Skip to main content
Glama
lincalinca

Crescender MCP Server

by lincalinca

list_asset_threads

Retrieve vendor, repair, and service conversations associated with school assets. Filter by status and paginate results for easy review.

Instructions

List asset-comms threads (vendor / repair / service conversations attached to assets). Read-only — vendor-token issuance is NOT exposed via this MCP.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
statusNoFilter by status: 'open', 'scheduled', 'closed', etc.
cursorNoOpaque pagination cursor.

Implementation Reference

  • Handler function for the list_asset_threads tool. Gets the school context from the API client and makes a GET request to /v1/schools/{schoolId}/asset-threads with optional status and cursor query parameters.
      async handler(args, client) {
        const ctx = await client.getContext();
        return client.get<unknown>(`/v1/schools/${ctx.schoolId}/asset-threads`, {
          status: typeof args.status === 'string' ? args.status : undefined,
          cursor: typeof args.cursor === 'string' ? args.cursor : undefined,
        });
      },
    };
  • Input schema for the list_asset_threads tool, defining optional 'status' and 'cursor' string properties.
    inputSchema: {
      type: 'object',
      properties: {
        status: {
          type: 'string',
          description: "Filter by status: 'open', 'scheduled', 'closed', etc.",
        },
        cursor: { type: 'string', description: 'Opaque pagination cursor.' },
      },
      additionalProperties: false,
    },
  • Registration of list_asset_threads in the tools array and the toolByName lookup map.
    export const tools: ToolDef[] = [
      listSchools,
      getAsset,
      searchAssets,
      getLoansForAsset,
      listMembers,
      listAssetThreads,
    ];
  • Definition and name registration of the list_asset_threads tool.
    const listAssetThreads: ToolDef = {
      name: 'list_asset_threads',
      description:
Behavior3/5

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

Without annotations, the description carries full burden. It discloses the read-only nature but does not cover pagination behavior, error conditions, or what happens when no threads exist. The mention of vendor-token issuance being excluded is a limitation but not a behavioral trait.

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?

Two sentences, no wasted words. Front-loaded with the purpose, followed by a key behavioral note. Every sentence earns its place.

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?

Given 2 optional parameters and no output schema, the description adequately explains what the tool does and its read-only nature. It could benefit from mentioning pagination details or return format, but for a simple list tool it is reasonably complete.

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% with descriptions for both parameters (status, cursor). The description adds context about the resource (vendor/repair/service conversations) but does not enhance parameter meaning beyond the schema. Baseline 3 is appropriate.

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 the verb 'List' and the resource 'asset-comms threads', specifying that these are vendor/repair/service conversations attached to assets. This distinguishes it from sibling tools like get_asset or search_assets.

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?

The description explicitly states 'Read-only' and clarifies that vendor-token issuance is NOT exposed, indicating when to use this tool (for reading threads) and what not to expect. However, it does not contrast with sibling tools like search_assets for broader asset searches.

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/lincalinca/crescender-mcp-server'

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