List access points
The Access Point directory: every Provider in its serving role, with its member seats and roster size (current participant count), busiest first. A Provider is resolved from each seat with the precedence curated mapping (verified) → exact signing-cert O= string (unverified) → bare SeatID. Not paginated (the envelope's next_cursor is always null).
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the readOnlyHint annotation by disclosing the ordering (busiest first), the provider resolution precedence, and the lack of pagination. These are behavioral traits not conveyed by the annotation alone, providing valuable context for the agent.
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 compact yet information-dense, with every sentence serving a purpose. It is front-loaded with the core action and then provides essential details about the directory structure, ordering, and pagination behavior in a clear, structured manner.
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 lack of an output schema, the description sufficiently covers the return content (member seats, roster size), ordering, provider resolution, and pagination. It could be slightly more explicit about the exact output format, but the current level is adequate for a list tool.
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?
With zero parameters, schema coverage is trivially 100%, and the description adds meaning by explaining what the tool returns and how results are ordered. The baseline for 0 params is 4, and the description adequately compensates for any missing parameter context.
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 the tool list all access points, defining them as a directory of every Provider in serving role with member seats and roster size, busiest first. This specific verb+resource combination distinguishes it from sibling tools like get_access_point.
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 context implies this is the canonical directory for all access points, suitable when a comprehensive listing is needed rather than a single lookup. However, it does not explicitly mention alternatives or when not to use it, such as when one specific access point is required (get_access_point).
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.
Most tools are cleanly separated by resource type: participants, access points, hosts, providers, incidents, anomalies, and SLA each have their own get/list vocabulary. The main ambiguous pairs are get_provider_sla vs get_provider_sla_by_key, list_providers vs list_public_providers, and get_summary vs get_network_summary.
The overall get_/list_ verb_noun pattern is consistent and readable, and plural/singular resource names are mostly clear. There are a few exceptions: get_provider_sla and get_country_providers return collections despite using get_, and list_provider_certs is more of an aggregate posture endpoint than a simple list.
43 tools is well beyond the typical well-scoped MCP surface and will make the tool set harder for an agent to navigate defensibly. The tools are systematically grouped, but this looks like a broad REST API surface rather than a compact, purpose-fit MCP server.
For a read-only monitoring and directory domain, the coverage is unusually complete: list/detail endpoints, histories, SLA tables, churn breakdowns, anomalies, incidents, adoption aggregates, software landscape, and quality checks are all represented. The drill-down routes such as churn totals to churn participants also avoid dead ends.
