signal_subscriptions-create
Schedule recurring signal execution for a template, domain, or list target.
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| __requestBody | Yes | Request body |
Saber
TDQS
B3.4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose a write operation (readOnlyHint=false) and non-destructive nature. The description adds that execution is recurring, but does not disclose side effects like whether scheduling begins immediately or requires a separate start step (given 'start' sibling exists). No contradiction with annotations.
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?
Single sentence, no wasted words, clearly front-loaded with the core action and target types.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is complex with nested request body and conditional requirements (listId required, frequency/cron mutual exclusion, signalTemplateId vs inline). One sentence does not explain target type 'domain' which has no corresponding schema field, nor does it mention required listId or start/stop workflow. This is insufficient for a complex creation endpoint despite rich schema.
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 descriptions cover 100% of parameters, including mutual exclusivity of frequency/cron and inline vs. existing template. The description adds no parameter-level information, so baseline 3 applies.
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?
The description clearly states the tool creates/schedules recurring signal execution, with specific target types (template, domain, list). It distinguishes from sibling create/start/stop/update operations, though 'domain' is not directly reflected in the schema, causing slight ambiguity.
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?
No explicit when-to-use or alternative guidance. The description implies usage for creating recurring signal subscriptions, but does not mention when to use signal_subscriptions-update or start instead. Only implied context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
C2.5/5.0
Disambiguation2/5
Many tools have overlapping purposes, such as signals-firmographics vs companies-enrich_firmographics, findEmail vs contacts-enrich_work_email, and monitors vs signal_subscriptions vs market_signals. While descriptions add some context, an agent could easily select the wrong tool due to the high similarity in function.
Naming Consistency2/5
Most tools use a resource_subresource-action pattern, but there are inconsistent separators: underscores within some names, hyphens in others (e.g., scoring-assignment-bulk-create), and several camelCase exceptions (findEmail, findEmailBatchGet, getContactResearchByExternalID). This mixed convention makes the tool set feel unpredictable.
Tool Count1/5
With 119 tools, this server vastly exceeds the typical well-scoped range. Even for a comprehensive B2B data platform, the sheer number creates cognitive overload and increases the risk of incorrect tool selection.
Completeness4/5
The server covers an extensive range of operations: enrichment, lists, contacts, signals, subscriptions, monitors, and scoring. Nearly every resource has create, read, update, and delete or lifecycle equivalents, leaving very few practical gaps for the intended use case.