Skip to main content
Glama
alga-psa-mcp

alga-psa-mcp

Official
by WYRE-AI

alga_services_list

Read-only

Browse or filter services page by page by name search or category, and retrieve the service records you need from Alga PSA.

Instructions

List services, one page at a time. Use to browse or filter by name search or category.

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

Input Schema

NameRequiredDescriptionDefault
pageNo
sortNo
limitNo
orderNo
searchNo
category_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description usefully discloses paging behavior ("one page at a time"), but says nothing about default page size, whether paging is offset- or page-based beyond the word "page", or total-count behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with the core action front-loaded and zero redundant wording. Nothing in it is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a six-parameter list tool with no output schema and no parameter descriptions, the description leaves sorting, ordering, page-size bounds, and result shape unaddressed. It is enough to call the tool correctly in the simplest case but not to use the sort/limit options confidently.

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?

Schema description coverage is 0% for six parameters, so the description must carry the load. It does clarify that search matches on name and that category_id is a category filter, but sort, order, limit, and page semantics get no explanation beyond the phrase "one page at a time".

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("List services") and adds the pagination scope ("one page at a time"). It is distinguishable from siblings by resource name alone, though it never explicitly contrasts with a services search or get tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Use to browse or filter by name search or category" gives implied usage context for two of the six inputs. There is no when-not guidance, no mention of an alternative tool for lookup by id, and no note that all filters are optional and combine.

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