MITRE ATT&CK MCP Server

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states what the tool does at a high level without describing: what format the output takes, whether it's paginated, what happens if no groups are found, authentication requirements, rate limits, or error conditions. For a lookup tool with zero annotation coverage, this is a significant gap in behavioral context.

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 efficiently structured with a clear purpose statement followed by parameter explanations. Every sentence adds value: the first states the tool's purpose, and the three parameter lines provide essential usage information. There's no redundant or unnecessary content, though the formatting could be slightly cleaner.

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 a lookup tool with 3 parameters, no annotations, and no output schema, the description does an adequate job explaining the parameters but leaves significant gaps. It doesn't describe the return format, what 'groups' means in this context (e.g., threat actor groups), error handling, or how results are structured. For a tool that presumably returns threat intelligence data, more context about the output would be helpful.

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 description provides meaningful semantic information for all three parameters beyond the schema's 0% coverage. It explains that 'campaign_stix_id' is used to 'look up what groups have been attributed to it', specifies the three valid values for 'domain', and clarifies that 'include_description' controls 'whether to include description in the output' with its default. This fully compensates for the schema's lack of descriptions.

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 tool's purpose: 'Get groups attributing to campaign' - a specific verb (get) and resource (groups) with the relationship to campaigns. It distinguishes from siblings like 'get_all_groups' (which lists all groups) and 'get_campaigns_attributed_to_group' (which has the inverse relationship). However, it doesn't explicitly mention what 'attributing to' means in this context (e.g., attribution relationships in threat intelligence).

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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when this tool is appropriate versus other group/campaign lookup tools, or any limitations. The sibling tools include several related tools (get_groups_by_alias, get_groups_using_software, etc.), but there's no differentiation guidance provided.

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