ShortsIntel

Create a collection

create_collection

Use when the Customer wants an empty named Collection before adding Trackers. Not usually needed first: add_to_collection and track create a Collection from a name you have not used yet. Price: Free. kind (creator, hashtag, keyword, sound or advertiser) is fixed once created. A Collection is only a set: pausing, analysis and cycles are per Tracker, charged once per cycle however many Collections hold it.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>",
      "kind": "<kind>"
    },
    "name": "create_collection"
  }
}

Input Schema

Name	Required	Description	Default
`kind`	Yes	What the Collection holds. Fixed once created.
`name`	Yes	The new Collection's name.

Output Schema

Name	Required	Description	Default
`collection`	No	A named set of Trackers of one kind.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 5, 2026
- changedOutput schema / properties / collection / additionalProperties
```
Previous value: -trueNew value: +{}
```
- removedOutput schema / properties / collection / properties
```
Removed value: -{}
```

Changed1 schema field changedNov 4, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": true,
+  "properties": {
+    "collection": {
+      "additionalProperties": true,
+      "description": "A named set of Trackers of one kind.",
+      "properties": {},
+      "type": "object"
+    }
+  },
+  "type": "object"
+}

First observedNov 2, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare this is a non-read-only, non-idempotent, non-destructive local operation, but the description adds real context: kind is immutable after creation, the operation is free, and a Collection carries no pausing/analysis/cycle semantics because those live per Tracker and are billed once per cycle regardless of Collection membership. It stops short of covering name-collision behavior or permissions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

The when-to-use clause and the sibling alternatives are front-loaded, which is the right ordering. The closing sentences on pricing and Tracker-level cycles are useful but slightly tangential to invoking this specific tool, keeping it from being maximally tight.

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?

With only two required, fully documented parameters and an output schema available, an agent has nearly everything needed; the description contributes usage routing, cost, and immutability. It leaves one plausible ambiguity unaddressed — what happens if the name already exists — but that is a small gap for a low-complexity create tool.

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 both parameters are already documented, including that kind is 'Fixed once created' — which the description repeats almost verbatim. The only added meaning is the enumeration of kinds inline and the framing of a Collection as 'only a set', which is marginal beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the outcome precisely: an 'empty named Collection' created before Trackers are added, which is a specific resource with clearly bounded membership. The creation verb is implied by the name rather than stated, but the distinction from siblings is made explicit ('add_to_collection and track create a Collection from a name you have not used yet').

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?

It gives an explicit when-to-use condition ('when the Customer wants an empty named Collection before adding Trackers') and an explicit when-not, naming the two alternatives (add_to_collection, track) that create Collections implicitly. An agent can route correctly without inspecting any other schema.

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

All ShortsIntel tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?