Your trackers, or every public one. Free. Same as GET /v1/trackers.
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": "list_trackers"
}
}| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | mine or public | mine |
| api_key | No |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose a genuinely useful trait ('Free', no credit cost) and that it is a thin wrapper over GET /v1/trackers, which hints at read-only semantics, but says nothing about pagination, result size limits, or authentication requirements for the api_key parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short fragments with zero waste and the key scoping fact front-loaded, but the terseness comes at the cost of real information — it reads as under-specified rather than efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 explained, but with no annotations the description should still cover auth behavior, result volume/pagination, and read-only safety. None of that is present, leaving an agent guessing before invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: scope is documented ('mine or public') and the description reinforces it by contrasting 'your trackers' vs 'every public one'. The api_key parameter is undocumented in both schema and description, so the description only partially compensates for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States the resource (trackers) and the scope split ('your trackers, or every public one'), which is specific enough to distinguish a listing call from get_tracker/create_tracker. It does not name any sibling explicitly, but the verb+resource combination is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Your trackers, or every public one' implies the two use cases and matches the scope parameter, but there is no explicit guidance on when to pick this over get_tracker or search-type siblings, and no preconditions stated. Usage is inferable rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.