Skip to main content
Glama
Sign In

Argorant

by com.argorant
OverviewDiscussionsAdmin

List saved lists

argorant_list_lists
Read-onlyIdempotent

List the user's saved lists and saved searches, newest first, with each one's id, name, size and when it changed. Use it to find a list id for argorant_list_status, argorant_export_list, argorant_add_campaign_leads or argorant_rename_list; for one list's progress use argorant_list_status. kind picks lists (people the user picked), saved_searches (searches that stay up to date) or all. A page holds up to 100; when has_more is true, call again with next_cursor as cursor. It is free. More in the docs at https://docs.argorant.com/docs/agents/tools#lists

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

Input Schema

NameRequiredDescriptionDefault
kindNoall (the default), lists or saved_searches.all
limitNoLists per page, up to 100 (default 25).
cursorNonext_cursor from the previous page

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, but the description adds substantive behavior: result ordering (newest first), page size cap of 100, the has_more/next_cursor pagination loop, and that the call is free. These are exactly the operational facts annotations cannot express.

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 purpose and return fields, then routing, then parameters, then pagination and cost — a sensible order with no filler. It is one dense semicolon-chained block, which is slightly harder to scan than short separated clauses, but every sentence carries information.

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 three-parameter read tool with an output schema and full annotation coverage, the description supplies everything else an agent needs: what comes back, ordering, page size, how to continue pagination, cost, and where to go next. Nothing material 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?

Schema coverage is 100%, so baseline is 3, and the description earns above that by explaining what the enum values actually mean ('lists (people the user picked)' vs 'saved_searches (searches that stay up to date)') rather than just repeating the enum labels. It also explains the cursor mechanics ('call again with next_cursor as cursor'), though it does not discuss the limit default of 25 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?

States a specific verb and resource ('List the user's saved lists and saved searches') plus scope details: newest-first ordering and the exact fields returned (id, name, size, when it changed). It also explicitly contrasts itself with argorant_list_status, so an agent can distinguish it from the closest sibling without opening either 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?

Names four downstream consumers of the returned list id (list_status, export_list, add_campaign_leads, rename_list) and states the exclusion case explicitly: 'for one list's progress use argorant_list_status.' That is when-to-use plus when-not-to-use plus named alternatives in two sentences.

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

All Argorant toolsInspect
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