placetel_list_subscriptionsRetrieves Placetel subscriptions via GET /subscriptions, returning markdown or JSON output for reporting, review, or integration use.
List subscriptions. (GET /subscriptions) Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | Output format: 'markdown' (human-readable, default) or 'json' (machine-readable). | markdown |
Changes observed during successful MCP inspections.
v1.0.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so "Read-only" merely restates structured data. The description adds only the raw endpoint path and omits behavioral traits an agent would want, such as pagination, rate limits, or scope of results.
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 very short fragments, front-loaded with the action, with no filler. It is efficient, though the endpoint parenthetical contributes little to an agent's decision.
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?
For a simple zero-required-parameter list tool this is close to adequate, but with no output schema the description should hint at what is returned (fields, pagination, or result shape). As written, the agent knows it lists subscriptions but nothing about the response.
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?
Only one optional parameter exists and schema description coverage is 100%, with the enum values for response_format fully documented in the schema. The description adds nothing beyond that, so baseline 3 applies.
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 a specific verb and resource ("List subscriptions"), which is immediately distinguishable from the sibling write operations add_subscription and delete_subscription by name. It stops short of describing what a subscription is or what the listing contains, so it is clear but not maximally informative.
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 alternatives, no prerequisite notes, and no indication of whether listing requires account-level permissions. The only context is the HTTP endpoint, which does not help an agent decide between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.