Skip to main content
Glama
Sign In
Commonly

Commonly

Official
by Team-Commonly
OverviewSchemaRelated ServersDiscussionsAdmin
JavaScript

commonly_get_ui_card_catalogue

Read-only

Fetch the UI card catalogue to get the current catalogId, catalogRev and catalogHash plus envelope shape and component grammar. Call before posting a card; stale hashes are rejected with 400 invalid_ui_card.

Instructions

Read the UI card catalogue the server accepts: the catalogId, catalogRev and catalogHash to put in a card payload, the envelope shape, the component grammar, and three worked examples. Call it before you post a card with commonly_post_message. Served from this package, no network call and no auth. Copy the tuple from this result, not from memory: a stale catalogHash is refused with 400 invalid_ui_card.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "commonly_get_ui_card_catalogue"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.16

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, but the description adds non-obvious behavior: served from the package with no network call and no auth, and a stale catalogHash is rejected with 400 invalid_ui_card. That error contract is the kind of context annotations cannot convey; only the absence of any note on response size or pagination keeps it from 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 the resource and its contents, then the call-ordering rule, then the failure mode. No filler; every clause carries a distinct instruction or constraint.

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?

No output schema exists, yet the description enumerates what comes back (tuple, envelope shape, grammar, examples) plus the auth/network profile and the 400 error case. For a zero-parameter local read tool, nothing an agent needs to invoke it correctly is missing.

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?

Zero parameters, so the baseline is 4, and the description goes slightly beyond by naming the three tuple fields (catalogId, catalogRev, catalogHash) the agent must reuse downstream. That is return-value semantics rather than parameter semantics, so it does not lift the score further.

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?

States a specific verb and resource ('Read the UI card catalogue the server accepts') and immediately enumerates the contents: catalogId, catalogRev, catalogHash, envelope shape, component grammar, and three worked examples. An agent can distinguish it from commonly_post_message without opening any schema.

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?

Gives an explicit ordering rule ('Call it before you post a card with commonly_post_message'), names the sibling it precedes, and adds a hard constraint: copy the tuple from this result rather than memory. Both the when-to-use and the failure mode are spelled out.

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

Deploy Server

Other Tools