Mark

Search CMS Media

search_cms_media

Read-onlyIdempotent

Searches the images already in one of the connected CMS's media collections, newest first, 24 per page. get_website_cms lists the collections Mark can read (mediaCollections); left out, Mark uses the default, and the reply names the collection it searched. Use a result as a website post's cover with save_post meta.cover = { source: "cms", mediaId, collection }, or attach it to a social post with save_post meta.cmsImages = [{ mediaId, collection }]: Mark keeps a reference, never a copy, and a social post's image is copied to the platform when the post is scheduled. To put one in a website post's body, add alt on its own line with the result's url (the original file): on a rich-text (lexical) mapping Mark publishes it as that media document, uploading nothing. Does not change anything; reads from the customer's CMS. These ids are not Mark asset ids. Related: save_post, get_website_cms, search_assets.

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": "search_cms_media"
  }
}

Input Schema

Name	Required	Description
`page`	No	Page number, from 1.
`query`	No	Matches file name or alt text.
`channel`	No	For a website cover, its channel (blog, faq, competitor_page): limits the search to the collections that channel's cover field accepts. Leave it out for a social post or a body image.
`collection`	No	Media collection slug from get_website_cms mediaCollections. Left out, the default (where new media goes, else the first readable).

Output Schema

Name	Required	Description	Default
`items`	Yes
`collection`	Yes
`hasNextPage`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 27, 2026

changedInput schema / properties / channel / description

Previous value: -"For a website cover, its channel (blog, faq, competitor_page, landing_page): limits the search to the collections that channel's cover field accepts. Leave it out for a social post or a body image."New value: +"For a website cover, its channel (blog, faq, competitor_page): limits the search to the collections that channel's cover field accepts. Leave it out for a social post or a body image."

Changed4 schema fields changedOct 22, 2026

changedInput schema / properties / channel / description

Previous value: -"Website channel whose CMS mapping names the media collection. Leave it out for a social post: Mark uses the first website channel with a media collection."New value: +"For a website cover, its channel (blog, faq, competitor_page, landing_page): limits the search to the collections that channel's cover field accepts. Leave it out for a social post or a body image."

addedInput schema / properties / collection

Added value: +{
+  "description": "Media collection slug from get_website_cms mediaCollections. Left out, the default (where new media goes, else the first readable).",
+  "maxLength": 64,
+  "minLength": 1,
+  "type": "string"
+}

addedOutput schema / properties / collection
```
Added value: +{
+  "type": "string"
+}
```

changedOutput schema / required

Previous value: -[
-  "hasNextPage",
-  "items"
-]New value: +[
+  "collection",
+  "hasNextPage",
+  "items"
+]

Changed2 schema fields changedOct 17, 2026

changedInput schema / properties / channel / description

Previous value: -"Website channel whose CMS mapping names the media collection."New value: +"Website channel whose CMS mapping names the media collection. Leave it out for a social post: Mark uses the first website channel with a media collection."

removedInput schema / required
```
Removed value: -[
-  "channel"
-]
```

AddedOct 15, 2026

TDQS

A4.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the safety profile is covered; the description's 'Does not change anything' is largely redundant. It does add real behavioral context beyond annotations — newest-first ordering, 24 per page, reference-not-copy semantics, and copy-at-scheduling for social posts — but much of the length is workflow advice for other tools rather than traits of this call.

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?

Front-loaded with the core action, ordering, and pagination, then conditional guidance. However, it is long for a search tool, and a chunk of the middle is instruction for save_post usage rather than for selecting or invoking this tool, which dilutes focus slightly.

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?

An output schema exists, so return values need not be re-explained, and annotations cover safety. Combined with the description's guidance on defaults, channel scoping, and id semantics, an agent has everything needed to call it correctly and route results downstream.

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 descriptions already document each parameter; the prose still adds meaning by explaining why channel restricts collections and what happens when collection is omitted (default where new media goes). No enum data exists, so the channel value list is only conveyed in prose, which is helpful.

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 ('Searches the images already in one of the connected CMS's media collections') plus ordering and page size. It also explicitly disambiguates from the closest sibling by noting 'These ids are not Mark asset ids' and naming search_assets among related tools.

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 explicit routing: use get_website_cms mediaCollections to list collections, omit collection to take the default, and omit channel unless the image is a website cover. It further explains the two distinct downstream uses (save_post meta.cover vs meta.cmsImages) so the agent knows which params and follow-up calls apply.

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

All Mark 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?