Skip to main content
Glama

list-subscriptions

list-subscriptions
Read-only

Retrieve webhook subscriptions for the current app and user, showing resource, change type, notification URL, and expiration.

Instructions

Retrieve the properties and relationships of webhook subscriptions, based on the app ID, the user, and the user's role with a tenant. The content of the response depends on the context in which the app is calling; for details, see the scenarios in the Permissions section.

💡 TIP: Lists webhook subscriptions owned by the current app/user. Returns id, resource, changeType, notificationUrl, expirationDateTime, clientState. Use $filter=resource eq '/me/messages' to find subscriptions for a specific resource. No dedicated 'Subscription.*' scope exists — the caller must already have a read permission for the subscribed resource (e.g. Mail.Read for /me/messages), which is supplied by the tool that reads that resource.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
topNoPage size (Graph $top). Start small (e.g. 5–15) so responses fit the model context; raise only if needed. Use $select to return fewer fields per item. For more rows, use @odata.nextLink from the response instead of a very large $top.
skipNoItems to skip for pagination. Not supported with $search.
countNoSet true to enable advanced query mode (ConsistencyLevel: eventual). Required for complex $filter on flag/flagStatus or contains().
expandNoNavigation properties to inline, e.g. attachments on a message or event. Only navigation properties can be expanded: expanding a non-navigation property such as a message body fails with "Parsing OData Select and Expand failed", and an unsupported value may be ignored rather than reported. Request ordinary fields with $select instead.
filterNoOData filter expression. Add $count=true for advanced filters (flag/flagStatus, contains()). Cannot combine with $search.
searchNoKQL search query — wrap value in double quotes. Cannot combine with $filter.
selectNoComma-separated fields to return, e.g. id,subject,from,receivedDateTime
orderbyNoSort expression, e.g. receivedDateTime desc
fetchAllPagesNoFollow @odata.nextLink and merge up to 100 pages into one response. Can return enormous payloads—only when the user explicitly needs a full export. Prefer a small $top first, then paginate or narrow with $filter/$search.
includeHeadersNoInclude response headers (including ETag) in the response metadata
excludeResponseNoExclude the full response body and only return success or failure indication
Behavior4/5

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

The annotations already mark readOnlyHint and destructiveHint false, so the safety profile is covered. The description adds valuable behavioral context: the response depends on calling context, the caller must already have read permission for the subscribed resource (no dedicated scope), and it lists the returned properties. This goes beyond the annotations and helps the agent understand permission requirements and variable responses.

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

Conciseness4/5

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

The description is moderately sized, with a formal opening sentence and a bulleted tip that packs useful specifics. The tip is actionable and front-loaded. It is not overly verbose, though the first sentence is somewhat generic and could be tightened. The structure is logical and scannable.

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

Completeness4/5

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

Given 11 optional parameters and no output schema, the description covers the key essentials: it states what is returned (list of fields), notes permission requirements, and gives a filter example. It does not explain every nuance (e.g., pagination behavior) but the schema already handles those. The description is sufficiently complete for an agent to call this tool correctly.

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 coverage is 100%, with each parameter having a description, so the baseline is 3. The tool description provides an example of using $filter ('Use $filter=resource eq '/me/messages'...'), which adds a practical usage hint, but it does not significantly enrich the semantics of individual parameters beyond what the schema already specifies. It stays at the baseline.

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

Purpose5/5

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

The description clearly states the action ('Retrieve the properties and relationships of webhook subscriptions') and adds specificity with the tip: 'Lists webhook subscriptions owned by the current app/user' and enumerates the exact fields returned. This distinguishes it from sibling tools like get-subscription (single) and create-subscription (new), even without explicitly naming them. The verb-resource pair is precise.

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?

The description implies when to use this tool (for listing subscriptions) and gives a filter example for a specific resource, but it does not explicitly contrast with get-subscription, create-subscription, or other alternatives. There is no direct 'when to use this vs. that' guidance, and it does not mention situations where this tool should NOT be used. The context is clear but exclusions are absent.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/A-Impact-Pavel/ms365-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server