atlas7_issuer_signalSubscription-gated issuer signal by ticker or CIK.
| Name | Required | Description | Default |
|---|---|---|---|
| cik | No | Issuer CIK when ticker is not supplied. | |
| limit | No | Maximum rows to return. | |
| ticker | No | Issuer ticker, for example IREN. |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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 declare readOnlyHint, idempotentHint, and destructiveHint=false, reducing the description's burden. The description adds meaningful context about subscription-gating and lookup by ticker or CIK, which are not in the annotations. It does not cover response structure, rate limits, or error behavior, but this is acceptable given the 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?
The description is a single sentence with zero filler. It Front-loads the key qualifier ('subscription-gated') and the two input dimensions, making it concise and well-structured.
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?
Rich annotations and an output schema reduce the description's burden, but the description still lacks a clear definition of what a 'signal' is and does not differentiate from nearby siblings like deltasignal_alpha_signals or atlas7_signal_board. Given the tool's moderate complexity, this is adequate but leaves gaps around exact usage context.
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?
The input schema provides descriptions for all three parameters (cik, limit, ticker) with 100% coverage, meeting the baseline. The description's phrase 'by ticker or CIK' restates the schema's existing parameter relationships without adding new semantics, so no bonus is earned.
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 identifies the resource (issuer signal) and the two lookup keys (ticker, CIK), which makes the tool's purpose understandable. However, it lacks an explicit verb like 'get' or 'retrieve', and does not explicitly contrast it with siblings such as atlas7_issuer_identity or atlas7_explain_signal, so it falls short of a 5.
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 only notes that the tool is 'subscription-gated,' which implies a prerequisite but gives no guidance on when to use this tool versus the many sibling tools. It provides no 'when to use' or 'instead of' instructions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.