list_subscriptionsList the caller's active subscriptions. Returns id, type, params, created_at, last_fired_at, fire_count for each. Use this to review what you're monitoring before adding more or to find an id to cancel.
| Name | Required | Description | Default |
|---|---|---|---|
| include_inactive | No | Include cancelled subscriptions in the response (default false). |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and destructiveHint. The description adds context that it returns active subscriptions by default and lists specific fields, providing behavioral clarity beyond annotations.
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?
Two concise sentences: first states purpose and output, second gives usage guidance. No unnecessary words, front-loaded with purpose.
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 single optional parameter, no output schema, and comprehensive annotations, the description is complete. It covers purpose, output fields, default behavior, and use cases.
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 coverage is 100% with a clear description for 'include_inactive'. The description does not add additional meaning beyond the schema, but baseline 3 is appropriate since schema is sufficient.
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 verb 'List' and the resource 'subscriptions', and specifies the return fields (id, type, params, created_at, etc.), distinguishing it from sibling tools like 'subscribe' and 'unsubscribe'.
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 description provides explicit usage guidance: 'Use this to review what you're monitoring before adding more or to find an id to cancel.' It clearly states when to use the tool, though it does not explicitly mention when not to use it.
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.
Several tools occupy overlapping functional space: ask_pipeworx_beta is explicitly identical to ask_pipeworx right now, and bet_research, polymarket_edges, and polymarket_arbitrage all target Polymarket opportunity detection. The detailed descriptions help, but an agent can easily select the wrong query/research or prediction-market tool.
Most names are readable snake_case and clusters like polymarket_* and pipeworx_* are internally consistent. However, the overall set mixes verb_object names (compare_entities, resolve_entity), bare verbs (forget, subscribe), and noun phrases (entity_profile, recent_alerts, top_exploited), so there is no unifying naming convention.
At 33 tools, the count exceeds the reasonable threshold for a focused server, and the problem is worse because the server is named Epss while most tools are Pipeworx data, Polymarket, memory, and subscription tools. A focused EPSS server would need only a handful of tools; this is a grab bag.
For the EPSS purpose implied by the server name, only get_epss and top_exploited exist, with no CVE search, historical score context, or vulnerability-management tooling. The unrelated research, memory, and prediction-market tools are individually fairly complete, but they do not fill the gap for the apparent EPSS use case.