Tick Mark Books

Read your listings

my_listings

Read-onlyIdempotent

What the Tick Mark Books owner dashboard shows about the listings an account owns: each one's status (status.kind: review with the expected date, accepted with liveOn and paid ('express' | 'featured' | null: the paid way that releases it, Featured including VIP listing), live, refused with the reason, or archived), the listing as it shows, where AI answers named the product or cited its page, and what it can buy here at this site's prices. Only for the account itself: send its session Cookie header, or its agent key with "Read your listings" as Authorization: Bearer. Same answer as GET https://tickmarkbooks.com/api/owner/listings. Read-only: corrections go through the dashboard's request form.

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

Input Schema

Name	Required	Description	Default
`slug`	No	Optional: one listing, by its slug. Without it, every listing the account owns.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 5, 2026

TDQS

A4.4/5.0

Behavior5/5

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

The readOnlyHint and idempotentHint annotations already identify this as a safe read, and the description adds important context: account-only access, required auth headers, equivalence to GET /api/owner/listings, and that corrections happen elsewhere. It also discloses the status semantics an agent will encounter, which is meaningful behavioral detail beyond the annotations.

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 description is front-loaded with what the tool returns and is organized around scope, auth, endpoint equivalence, and read-only behavior. It is dense and parenthetical in places, but the detail largely earns its place because there is no output schema to document the returned statuses.

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?

For a one-parameter read tool with no output schema, the description is complete: it covers account scope, auth, the equivalent HTTP endpoint, read-only behavior, and the key status information returned. The only minor omission is a full response shape, but the described status fields are sufficient for correct invocation.

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?

The schema already documents the single optional slug parameter at 100% coverage, including that omitting it returns every listing the account owns. The description reinforces that same meaning but does not add format details, edge cases, or other slug-specific semantics beyond the schema.

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 states a specific resource (the account's owned listings) and scope (the owner dashboard view), including what the response covers such as status, AI citations, and purchasable items. It also distinguishes the account-owned view from public listing tools by saying it is only for the account itself.

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?

It clearly explains that this is only for the account itself and gives the two accepted authentication methods: a session Cookie header or an agent key as Authorization: Bearer. It also directs corrections to the dashboard request form, though it does not explicitly name sibling alternatives such as get_listing or search_listings.

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

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