list_loopsThe loops this account has for a company, or for every company when none is named: each one's id, whether it is active or paused, the sentence it came from, what it does read back in the user's words, and when it last ran and runs next. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| company | No | Which connected company. Every company when left out. |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly says 'Read-only', which aligns with the annotations (readOnlyHint: true) and adds clarity. It also mentions the specific fields returned (id, active/paused status, sentence origin, user-words read-back, last/next run times), which is helpful context beyond the annotations. No contradictions found.
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?
The description is a single, dense sentence that packs all necessary information without any fluff. It front-loads the primary function (listing loops) and then provides scope and output details efficiently. No unnecessary words.
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?
Given the simple nature of the tool (one optional parameter, no output schema needed because the description itemizes the return fields), the description is complete enough for an agent to call it correctly. It covers scope, filtering, and output composition, leaving little ambiguity.
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?
The schema already provides complete descriptions for the single parameter 'company' (coverage 100%), so the description adds little additional meaning. However, the description's phrase 'or for every company when none is named' reinforces the optionality and default behavior, which is a slight enhancement.
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?
The description clearly states that this tool lists loops for a company or for all companies when none is named, which distinguishes it from related sibling tools like list_proposals and list_rules. While it doesn't explicitly name a sibling, the scope (loops vs. proposals vs. rules) is clear and 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?
The description implies when to use this tool: to retrieve loops for a specific company or across all companies. It doesn't explicitly state when not to use it or mention alternatives, but the context is clear enough for an agent to select it over siblings like search_* tools when a simple list is needed.
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.