get_list_of_solution_folderList folders in a Freshservice solution category by category ID, with pagination and an optional trash filter.
List the folders in a category.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, starting at 1 | |
| filter | No | Pass 'trash' to list deleted items | |
| per_page | No | Records per page (max 100) | |
| category_id | Yes | Solution category ID |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v2.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds essentially nothing beyond that: it doesn't mention pagination behaviour, the trash filter, or completeness/ordering of results — all of which are behaviours an agent would want described.
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?
A single short sentence, front-loaded and free of filler. It is efficient, though the terseness is partly the cause of the gaps elsewhere rather than a virtue in itself.
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?
With an output schema and fully documented parameters, the definition is callable without ambiguity, and a 3 reflects that minimum-viable adequacy. The remaining gap is navigational: nothing distinguishes this from list_solution_subfolders or explains what a solution folder is in this product.
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 description coverage is 100%, with page, per_page, filter ('trash') and category_id all documented inline. The description's 'in a category' merely echoes category_id, so the baseline of 3 for a fully documented schema is warranted.
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 gives a verb ('List') and a resource ('the folders in a category'), so the basic operation is clear. However, it never says these are 'solution folders' or relates them to the neighbouring list_solution_subfolders / get_solution_folder / get_list_of_solution_article tools, leaving the agent to infer scope from the tool name alone.
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?
There is no guidance on when to use this versus list_solution_subfolders, get_solution_folder, or list_solution_service_categories. The only implicit hint is that a category_id is required, which the schema already states.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.