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 full burden for behavioral disclosure. It states this is a 'Get' operation which implies read-only behavior, but doesn't address important aspects like: what format the objects are returned in, whether this is a partial/fuzzy match or exact match search, pagination behavior, error conditions, or performance characteristics. The description is minimal beyond the basic operation statement.

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 reasonably concise with a clear purpose statement followed by parameter documentation. However, the structure has issues: the Args section incorrectly lists 'name' instead of 'content' as shown in the schema, creating inconsistency. The description could be more front-loaded with critical information about search behavior.

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?

For a search tool with 4 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what 'objects' are returned (STIX objects? which fields?), how the content search works (full-text? substring? regex?), what the output format is, or any error handling. The parameter documentation helps but doesn't compensate for the missing behavioral 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?

With 0% schema description coverage, the description compensates well by documenting all 4 parameters in the Args section. It provides clear explanations for object_type (with specific allowed values), domain (with allowed values), include_description (with default), and implies content is the search term. However, it incorrectly lists 'name' as a parameter when the schema shows 'content' - this creates some confusion about the actual parameter name.

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 objects by the content of their description' - a specific verb+resource combination. It distinguishes itself from siblings like 'get_objects_by_name' or 'get_objects_by_type' by focusing on content search rather than name or type filtering. However, it doesn't explicitly contrast with these alternatives in the description text itself.

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. With many sibling tools available for querying objects (like get_objects_by_name, get_objects_by_type, get_object_by_attack_id), there's no indication of when content-based search is appropriate versus other lookup methods. The parameter documentation implies some usage context but doesn't provide explicit guidance.

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