Intel Threadlinqs MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v8.2.1
Disambiguation2/5
The descriptions are unusually thorough, but the set is dense with overlapping families: get_threat / get_threat_enrichment / get_threat_bundle / get_threat_hunting_bundle, get_cve / get_cve_intelligence, get_actor / get_actor_intelligence, get_ioc_intelligence / get_entity_profile, and the multiple campaign tools. An agent can easily pick a differently-scoped variant and get a different result shape than expected. The detailed caveats are the only thing keeping this from a 1.
Naming Consistency4/5
The overwhelming majority of tool names follow a clear verb_noun snake_case pattern: get_threat, search_threats, list_debriefs, export_stix, generate_c2_blocklist, explain_correlation, and hunt_schema. Minor deviations like `health` and bare `hunt`, plus the alternation between get/search on very similar resources, keep it from a perfect 5.
Tool Count1/5
81 tools is far beyond a workable MCP surface; the list itself becomes the main cognitive burden for an agent. The many get_*_intelligence and bundle tools show the platform knows fragmentation is a problem, but they add to rather than reduce the raw count.
Completeness4/5
The threat-intelligence domain is covered remarkably well: threats, actors, malware, tools, campaigns, CVEs, CWEs, IOCs, detections, C2, MITRE, ATT&CK Flows, and correlation evidence all have dedicated lookup and search paths. There are only minor workaroundable gaps such as some endpoints without full pagination and some stored-only enrichment layers.
Average 4.4/5 across 81 of 81 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 16 commits in the last 12 weeks
- Last stable release on August 23, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
This server has been verified by its author.
View related servers

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds the 'coverage across the platform' aggregation scope and the tactic-filtering behavior, which adds value beyond annotations. However, it doesn't describe what 'coverage' means (e.g., counts, percentages, technique statuses) or return shape, though an output schema exists.
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?
Two short sentences, zero filler. Every word earns its place: the verb, the resource, the platform scope, and the optional filter. Highly front-loaded with the core purpose in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple filtered read with strong annotations (read-only, idempotent) and a full schema (1 param at 100% coverage) plus an output schema, the description is reasonably complete. 'Coverage' could be more explicitly defined in terms of what the agent will see, but the output schema presumably fills that gap. It doesn't differentiate from the related get_mitre_gap_analysis tool, which is a minor completeness gap.
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 description coverage is 100%, so the tactic parameter is fully documented in the schema with an example ('initial-access'). The description adds the 'optionally filter' semantic, confirming the parameter is non-required, which matches the 0 required parameter count. Baseline 3 is appropriate since the schema already covers parameter meaning fully.
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 verb ('Get') and resource ('MITRE ATT&CK coverage across the platform'), which is distinct from siblings like get_mitre_technique (specific technique) and get_mitre_gap_analysis (gap analysis). The 'across the platform' scope helps differentiate it, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Optionally filter by tactic' which gives some context, but provides no guidance on when to use this vs get_mitre_technique, get_mitre_gap_analysis, or predict_mitre_transitions, which are all MITRE-related sibling tools. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is fully covered by structured data. The description adds the 20-item cap and the return shape {cves, missing, count}. The 'missing' field implies that some requested IDs may not be found, which is useful behavioral context the annotations don't capture.
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?
Two sentences with zero waste. The first sentence states the action and cap, the second states the return shape. Everything earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is an output schema present, so return values are documented there. The description covers the key behavioral notes (20 limit, enriched data, missing handling). For a simple 1-parameter, read-only tool with good annotations and full schema coverage, this is essentially complete. Minor gap: doesn't specify what 'enriched' means relative to the singular get_cve.
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 description coverage is 100%, so the schema already documents the cve_ids parameter fully ('CVE IDs (max 20)'). The description adds the return-format detail but not new parameter semantics beyond what the schema provides. Baseline 3 is appropriate since the schema carries the parameter documentation burden.
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 'Fetch up to 20 enriched CVEs by ID in one call' — a specific verb (fetch), resource (CVEs), and scoping constraint (by ID, up to 20, in one call). It distinguishes from the sibling get_cve (singular) and bulk_get_threats by specifying the resource type and batch limit. Returns structure is also noted, adding clarity.
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?
The description implies usage — use this when you need multiple CVEs in one call rather than calling get_cve repeatedly. However, it does not explicitly state when NOT to use it or name alternatives (e.g., when you need fewer than 20, or when get_cve is preferable). The sibling differentiation is implicit via the bulk/batch framing but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well-covered by structured data. The description adds the scope of what counts are returned (threat, detection, IOC, MITRE, actor) but doesn't disclose aggregate semantics like whether counts are deduplicated, time-bounded, or filtered, which would add value 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that enumerates the five data categories with zero wasted words. It front-loads the key action term and is perfectly sized for a zero-parameter aggregate endpoint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 0 parameters and annotations declaring it read-only, idempotent, and non-destructive, the description covers the primary behavioral aspects adequately. An output schema exists to explain return structure. However, the description could note whether counts are global/total versus time-windowed, which would improve completeness for a stats endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters and schema coverage is 100%, so there are no parameter semantics to explain. The description appropriately focuses on what data the tool returns rather than parameter behavior, which is the correct compensation given the empty schema.
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 uses a specific verb+resource ('Get aggregate platform statistics') and enumerates the specific data categories included (threat, detection, IOC, MITRE technique, actor counts), clarifying scope. However, it doesn't explicitly distinguish from sibling tools like get_enrichment_overview or get_landscape_briefing, which could overlap conceptually.
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?
The description implies this is a high-level overview tool, but it doesn't state when to use it versus sibling alternatives like get_enrichment_overview or get_landscape_briefing. There's no explicit exclusion or alternative guidance, making usage context clear-ish but not differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the behavioral detail that the tool internally resolves the most recent date, which is genuinely useful beyond annotations. With readOnlyHint=true, idempotentHint=true, and destructiveHint=false already declared, the safety profile is well covered. The description doesn't mention return format, but an output schema exists, lowering the burden.
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?
The description is a single, efficient sentence that covers purpose, the automatic date resolution behavior, and output detail level ('full detail'). Zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only, idempotent tool with an output schema present, the description is sufficiently complete. It conveys what it returns ('full detail'), how the date is handled, and the safety profile is covered by annotations. Minor gap: it doesn't note what time period the 'latest' refers to, but this is a minor omission for a straightforward fetch tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so there are no parameters to document. With schema description coverage at 100% (vacuously, since there are no parameters), the baseline would be 4 for zero-parameter tools. The description correctly confirms no inputs are needed by stating it resolves the date for you.
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 verb+resource: 'Get the most recent daily intelligence debrief in full detail.' It adds the useful nuance that the tool resolves the latest date for the agent, distinguishing it from a debrief tool requiring an explicit date parameter. It doesn't explicitly name a sibling alternative, but the 'resolves the latest date for you' clause differentiates it from other debrief-related tools.
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?
The description implies the use case (when you want the latest debrief without knowing/specifying a date), which provides reasonable context. However, it doesn't explicitly state when NOT to use it or name an alternative (e.g., a date-specific debrief tool if one existed). The implied usage is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds that the value is 'computed' and 'current', implying it's a derived metric. Beyond that, it doesn't disclose behavior like caching, refresh semantics, or what 'computed' entails, though this is minor for a read-only getter.
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?
A single sentence that efficiently states the purpose and output format with zero waste. It includes the meaningful detail of the 0-25 range to set expectations. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is an output schema present, so return-value documentation is covered. For a zero-parameter read-only getter with good annotations and a defined output schema, the description is reasonably complete. It could arguably add what 'threat-landscape' encompasses, but the output schema likely covers the structure. The single-sentence description is adequate for this tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, making parameter semantics largely moot. With schema description coverage at 100% and no parameters, the baseline of 4 applies. The description goes slightly beyond by explaining the output is a 0-25 rating, which clarifies what the returned value represents.
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?
Description states a specific verb+resource: 'Get the computed current threat-landscape level'. It even clarifies the output is a 0-25 rating of overall posture. However, among many sibling tools (get_landscape_briefing, get_threat_level vs get_recent_threats, etc.), it doesn't explicitly differentiate from alternatives beyond the narrow scope of 'current' stated level.
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?
The description implies usage via 'computed current threat-landscape level' — this is a snapshot of present posture, distinct from briefing-style or historical tools. However, there's no explicit when-to-use or when-not-to-use guidance, nor naming of alternative tools for comparison, which is notable given 70+ siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true and destructiveHint=false annotations already establishing safety, the description adds valuable behavioral context: the has_more semantics, the limit cap, and the critical note that offset isn't honored (so paging won't work). This functional caveat is genuinely useful behavioral disclosure beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Compact two-sentence description, front-loaded with purpose. The parenthetical about the offset limitation is efficiently integrated rather than a separate paragraph. Slightly dense but every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema is present and a 3-param tool with 100% schema coverage, the description covers purpose, filtering modes, limit behavior, and the unusual offset caveat. The sibling landscape has many IOC-adjacent tools, so explicit guidance on when to use this vs search_xscan_indicators would push it to 5, but for its complexity level the completion is strong.
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 coverage is 100%, so the baseline is 3. The description adds the note on narrowing with more specific substrings instead of paging, which adds a bit of guidance, but the description largely restates what schema already documents (type/value/limit defaults). No new semantic detail beyond defaults and pagination caveat.
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?
Clear verb+resource: 'Search indicators of compromise' with specific types listed (IPs, domains, hashes, URLs). Distinguishes from siblings like search_vulnerabilities and search_threats by naming the IOC domain, though it doesn't explicitly name sibling alternatives.
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?
States filtering modes (value substring and/or category) and the limit behavior with the has_more flag. However, it doesn't explicitly say when to choose this over search_xscan_indicators or get_ioc_intelligence, which are nearby siblings operating on IOCs. The note about offset not being honored provides usage constraint context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior, so the safety profile is clear. The description adds that the data is 'precomputed' and that 'overview' is a rollup across engines, which is useful behavioral context beyond annotations. It doesn't describe the response envelope, but an output schema exists and the parameter schema covers summary/paging behavior.
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?
Two tight sentences. The core purpose ('Read precomputed cross-dataset correlations') is front-loaded, followed by the engine list and the drill-down workflow. No filler or repetition of structural data.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a three-parameter read tool with full schema coverage and an output schema, the description supplies the missing conceptual layer: what the engines are and the recommended access pattern. It feels complete enough for correct invocation, only lacking any comparative positioning against sibling correlation tools.
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 description coverage is 100%: all three parameters (limit, engine, offset) have detailed descriptions including enums and paging notes. The description adds strategy ('use overview first') but not parameter meaning beyond the schema, so baseline 3 is appropriate.
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 names a clear verb ('Read') and a clear resource ('precomputed cross-dataset correlations'), and enumerates all engine choices. It does not explicitly contrast itself with the many correlation-related siblings like get_correlation_path or explain_correlation, so it stops short of a full sibling-differentiation 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete guidance: use 'overview' first, then drill into a specific engine. This is useful, explicit, intra-tool routing. However, it does not tell an agent when to choose this tool over the many sibling correlation tools, so it misses exclusion/alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a safe, idempotent read operation. The description adds behavioral nuance by distinguishing 'last real assessment' from 'last nightly intake,' and revealing it exposes research backlog/contradictions. This goes beyond basic read-only semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence covering many output components. It is compact but somewhat run-on; it could be front-loaded and broken into clearer phrases. Still, no waste words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the key data dimensions (breakdowns, backlog, contradictions, top actors, research clock) and annotations/output schema handle safety and return format. Missing is any explanation of the optional actor parameter or the 'recent' list it scopes, which is a gap relative to the 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?
The schema fully documents the one optional parameter (actor) with a clear description, so baseline is 3. However, the tool description never mentions the 'recent' list that the parameter refers to, creating a slight disconnect between the description's corpus-level scope and the parameter's scoping behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool as providing corpus-level attribution coverage metrics, distinguishing between genuinely assessed, actor-labelled, and uncovered threats. This differentiates it from sibling tools like get_attribution_evidence, which focuses on evidence for a specific entity.
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?
The description implies use for understanding overall attribution quality but does not state when to use it versus alternative tools or explicitly mention the optional actor filter. No exclusion criteria or alternative tool names are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable caveats beyond annotations: it explicitly warns that betweenness is an 'ego-bridge heuristic, not exact Brandes' and instructs not to present results as exact betweenness, noting the response carries this in `note`. This is genuine behavioral disclosure well beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, efficient and front-loaded. The first sentence establishes what the tool returns and the ranking; the second delivers the critical caveat about betweenness. No wasted words. It loses one point because the caveat is placed at the end, slightly reducing the immediate clarity of the safety-critical warning, though the structure is overall tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (so return values need no description), two simple parameters, and rich annotations covering read-only/idempotent/destructive profile. Given this context, the description adequately explains the ranking semantics and the heuristic caveat. It's complete for a read-only ranked-list tool; a minor gap is not explaining the node_type filtering behavior in the description.
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 description coverage is 50%, meaning the limit parameter is described (default 25, max 100) in the schema while node_type is described only via its enum values. The description doesn't add parameter-level detail beyond the schema — it doesn't explain how node_type filters results or how limit interacts with ranking. With 50% coverage, the description carries some compensation burden but mostly remains silent on parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'the hubs and bridges of the intelligence graph' ranked by 'weighted degree and approximate betweenness.' It uses a specific verb (get) plus a well-defined resource (pivotal entities = hubs/bridges) with explicit ranking criteria. This meaningfully distinguishes it from siblings like get_infrastructure_pivots or get_correlation_path.
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?
The description implies usage: to identify high-coverage nodes in the intelligence graph where a detection buys maximum coverage. It frames the 'when to use' clearly ('where a single detection buys the most coverage'), but it does not explicitly say when NOT to use it or name alternative tools for specific scenarios. The node_type parameter suggests filtering by entity type, but the description doesn't guide which type to pick.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe read-only nature is fully covered by structured data. The description adds modest value by noting 'No API call' — implying it's offline/local — but lacks detail on what the return payload looks like, size of the catalog, or how much guidance is included. With strong annotations, a 3 is appropriate.
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?
Two concise sentences with zero waste. The 'Start here' opener front-loads the critical instruction, followed by a clear description of return contents and the 'read before using' directive. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 0-parameter, read-only catalog tool with an output schema present and strong annotations, the description is complete. It covers what's returned, the prerequisite guidance, and the non-API nature. It doesn't detail output size or categories, but the presence of an output schema lowers that burden. It's sufficient for an agent to correctly select and invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema coverage, there are no params to document. The description appropriately focuses on what the call returns rather than parameter constraints. The baseline for a 0-parameter tool is 4, and the description adequately conveys the tool's contract without needing parameter explanations.
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's purpose: 'Returns the Threadlinqs Intelligence tool catalog, categories, tiering, and usage guidance.' It uses specific verbs and resources, and the 'Start here' framing distinguishes it as an onboarding tool. However, it could more explicitly separate itself from sibling onboarding tools like get_roadmap, though the catalog/usage-guidance scope is fairly distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'read this before using other tools,' providing clear when-to-use guidance. It also notes 'No API call,' which signals it's a local/metadata read. It doesn't explicitly name exclusion criteria vs alternatives, but the 'start here' instruction effectively orients the agent toward correct usage before consulting siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, idempotentHint=true, destructiveHint=false, which fully cover the safety profile. The description adds value by specifying the returned content depth (complete query text, metadata, threat mapping) beyond simple read semantics. However, it doesn't discuss behaviors like what happens with an invalid/unknown detection_id, rate limits, or whether the full query text is ever truncated.
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?
One tightly-written sentence that covers purpose, scope, and returned content without waste. Every element earns its place — the query-format enumeration (SPL/KQL/Sigma) is valuable detail packed into few words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, extensive annotations, and a single well-documented parameter, so the description's job is modest. It competently communicates what's returned (full query text, metadata, threat mapping). Minor gap: no mention of how a missing/unknown ID is handled or fallback behaviors, but for a read-only single-fetch tool with strong structured metadata, this is largely sufficient.
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 coverage is 100% and the single parameter detection_id is simply documented as 'Detection ID'. The description reinforces the parameter's role (the ID of the detection to fetch) but adds no format, source, or usage detail beyond what the schema provides. With full schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches full detail for a single detection rule by ID, enumerating specific content included (query text in SPL/KQL/Sigma, metadata, threat mapping). The verb 'Get' plus resource 'detection detail' is specific and distinct from siblings like get_detections (which lists detections) and search_detections (which searches).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for retrieving a single detection when you have a specific ID in hand, contrasting implicitly with get_detections (bulk listing) and search_detections (searching). It doesn't explicitly name alternative tools for when NOT to use it, but the single-ID parameter and 'full detail' framing make context reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With strong annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false), the safety profile is fully covered by structured data. The description adds meaningful behavioral context beyond that: the keying on community tags rather than malware family, the data source provenance (tweetfeed.live, CC0), and the population caveat (<1% of upstream rows). This gives the agent a realistic expectation of data sparsity that annotations can't convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact given the breadth of data dimensions it names, and the critical distinguishing detail (corpus join, tag keying) is front-loaded near the start. The parenthetical sourcing note is efficient. It could save a few words on enumerating every data dimension, but it's an appropriately dense single block.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a read-only aggregate view with an output schema present, so the description doesn't need to enumerate return fields. The description explains the data's source, its unique value proposition, and important caveats about tag population. For a no-parameter read tool, this level of contextual depth is adequate and complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema coverage (empty schema), so there are no parameter semantics to document. The description instead provides rich context about the returned data dimensions (corpus coverage, early warning lead-time distribution), which substitutes for the parameter guidance that would normally be needed. With 0 params, the baseline is 4 per rubric.
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 identifies the tool as a community-driven trends view ('what the security community is surging on'), with specific data dimensions named (trending tags, TLD distribution, novelty, top producers, daily volume). The verb 'get' plus the resource 'trends' is specific, and the niche framing ('joined against our own corpus coverage,' 'exists nowhere else') helps differentiate it from siblings like get_platform_stats or get_landscape_briefing. However, the distinction from platform/landscape stats siblings is implicit rather than explicitly contrasted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives strong contextual guidance on what makes this tool unique ('the corpus join exists nowhere else') and clarifies important semantics ('Keyed on community TAGS, not malware family'). It tells the agent this covers a specific niche that other tools don't. However, it doesn't explicitly say when NOT to use it or name alternative tools for users wanting coverage-gap or lead-time reads in isolation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds behavioral value by clarifying what is returned per format flavor (raw query text vs. full object), which is useful beyond the annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste, front-loaded with the core purpose. It's efficient and every clause earns its place. Slightly more could be added about detection_id semantics but not required.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, both required, no nested objects) and has an output schema plus strong annotations. The description explains the format value semantics adequately. Could mention what formats are unsupported or typical file extensions, but for the simplicity level this is complete.
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 coverage is 100%, so the schema already documents both parameters. The description adds the interpretation of the format values (spl/kql/sigma = raw text, json = full object), which is a genuine enhancement, though light. Baseline 3 is appropriate given high schema coverage and the modest added meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (export) with a specific resource (one detection rule) and specifies the format dimension, distinguishing it from sibling tools like get_detections and export_stix. The scope ('one detection rule') is clearly delimited against bulk-export siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly explains the format parameter semantics, distinguishing raw query text (spl/kql/sigma) from the full object (json). It doesn't explicitly name alternatives like export_stix or get_detections, but the format-flavor distinction gives strong usage context for when this vs. other export/get tools is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds meaningful behavioral details beyond annotations: upstream proxy failure returns community_error instead of erroring, and cluster labels are upstream AI output rather than Threadlinqs attribution. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no redundant content. Each sentence earns its place: first lists the contents, second clarifies data provenance, third explains error handling. Very concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values are documented. The description covers purpose, data source, content fields, provenance caveat, and error behavior. Only missing explicit alternative tool comparisons, which for a simple read-only list tool is an acceptable gap.
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 has 100% coverage for the single parameter 'limit' with its description (default 15, max 50). The tool description adds no further information about parameter usage, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly identifies what is returned (campaign clusters from community OSINT layer) and lists specific fields (cluster name, confidence, targeted brand, first/last seen, indicator count/types, tags, reporters). It distinguishes from siblings by naming the source (tweetfeed.live, CC0) and explicitly stating that cluster labels are upstream AI output, not Threadlinqs attribution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage context is strong: the tool provides community-layer campaign data, and the description gives guidance on how to interpret labels (do not present as our assessment) and how to handle errors (report 'community feed unavailable' rather than 'no campaigns'). However, no explicit alternative tools or when-not-to-use scenarios are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds meaningful behavior: it explicitly discloses the found:false return shape with the reason distinction (no edges vs different components) rather than an empty array, which is valuable behavioral context beyond annotations. Missing some context like hop semantics or path weighting, but no contradictions.
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?
Two sentences, zero filler. The first sentence delivers the core value in one flowing clause, and the second sentence proactively handles the negative-return case. Every clause adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values are documented separately. Both parameters are documented, annotations cover the safety profile, and the description handles the edge case (found:false) and the interpretation guidance (weakest-link strength, connectedness question). This is complete for a read-only graph-query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for to, from, and max_hops (including the 1-8 range and default 6). The description reinforces path semantics (hop count, weakest-link strength) that map to max_hops usage. It adds value by explaining what the path represents per hop, but relies largely on the schema which already documents all three parameters well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb-plus-resource ('Shortest evidence path between two threats across the similarity graph'), specific scope, and explicit answer to the analytical question ('is this incident connected to that campaign, and through what'). The output content is enumerated (intermediate threats, per-hop signal, weakest-link strength), which thoroughly distinguishes this from siblings like get_similar_threats or explain_correlation.
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?
The description implies the tool answers connectivity questions between two threats but does not explicitly say when to prefer it over explain_correlation or get_correlation_subgraph, which appear as siblings and sound adjacent in purpose. No explicit when-not/alternative guidance, though the purpose statement ('Answers is this incident connected to that campaign') provides reasonable implied context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: the 200-object/80KB cap with a note object on truncation, the trust flag 'community-unverified' for OSINT data, and the return structure with specific object types. It doesn't detail auth/permission requirements, but annotations cover the mutation-safety aspect well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense paragraph with no wasted words. Every sentence carries meaningful content: purpose, parameter requirement, output structure, OSINT option semantics, and truncation behavior. It could be slightly more structured (e.g., separating return format from option behavior), but it is appropriately compact for the richness it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and annotations are strong (readOnly, idempotent, non-destructive), the description fully covers the remaining contextual needs: return object structure, option semantics with trust implications, truncation limits, and the at-least-one-input requirement. This is complete for a moderately complex tool.
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 description coverage is 100%, so all 4 parameters are documented in the schema. The description adds context that 'at least one' identifier is needed and explains the include_osint side-effect (adds sighting SROs with a community trust flag), which goes slightly beyond the schema. This is a solid baseline-plus scenario where schema handles most of the lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb+resource (export a threat/actor/CVE as STIX 2.1 bundle) and the audience purpose (ingestion into TIP/SIEM). It distinguishes from siblings like export_detection and get_threat_bundle by specifying the STIX 2.1 format and detailed object composition, which are unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the requirement of 'provide at least one of threat_id, actor, or cve_id' and explains the optional include_osint behavior with its caveats. However, it does not explicitly say when NOT to use this tool versus alternatives like export_detection or get_threat_bundle, though the STIX format and TIP/SIEM ingestion purpose imply differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which broadly cover the safety profile. The description adds meaningful value beyond annotations by disclosing the distinct `state` field semantics and the fact that this tool reveals attribution depth (researched vs intake stub) — genuinely useful behavioral context about what the returned data represents.
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?
Two sentences, zero waste. The first sentence enumerates the data fields returned; the second delivers the crucial differentiator (`state` and what it means). Every clause earns its place, and the example format mention adds concrete value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single required parameter, a high-coverage schema, full annotations, and an output schema present, most of the burden is already handled structurally. The description covers the key addition (state field semantics). It's a complete description for a focused, single-parameter lookup tool, though it could mention the output format/pagination slightly.
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 coverage is 100% and the description clearly explains what the returned data will contain, which helps the agent understand what it's getting. The single parameter threat_id is fully documented in the schema with an example. With full schema coverage and one simple parameter, the description adds no additional parameter semantics needed beyond what's already provided, warranting the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool returns the attribution evidence for a threat: verdict, canonical actor, confidence, scope, evidence chain, signals, alternatives, and analyst reasoning. It explicitly distinguishes its purpose from siblings like get_threat by highlighting that it reports `state` (researched vs unresearched intake stub) which threats.threat_actor alone cannot convey.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that this tool reveals whether an attribution is a researched assessment or an unresearched stub — useful context for when to trust the output. However, it doesn't explicitly name when-not-to-use or point to alternative tools for getting the threat actor, leaving the when/alternative guidance implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description adds valuable behavioral nuance: it explains the authoritative join on cve.threat_ids, the reconciliation of attributed actors and techniques, and the corpus-relative weaponization rank. This clearly matches the non-destructive read annotation with no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the high-level concept 'Composite CVE dossier in one call' and then enumerates the contained components. It is dense and somewhat list-like, but every component listed contributes to understanding what the tool provides.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one required parameter, an output schema, and read-only/idempotent annotations, the description is complete. It clearly communicates the full scope of the returned intelligence including threats, actors, techniques, velocity ranking, sibling CVEs, and detections, so an agent is well-equipped to select and invoke it correctly.
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?
The input schema already fully documents the single cve_id parameter with an example, so schema coverage is 100%. The description adds no additional parameter-level meaning, making the schema-based baseline of 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Composite CVE dossier in one call' with a detailed inventory of what it returns. This clearly distinguishes it from singular tools like get_cve or get_cwe by emphasizing the aggregated, cross-referenced payload.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Composite CVE dossier in one call' gives clear context for when this tool is appropriate: when you need a broad CVE intelligence bundle rather than a single detail. It does not explicitly name alternative tools or exclusion conditions, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is established. The description adds valuable behavioral context: pagination mechanics (has_more, next_cursor reusable as offset/cursor) and the specific precedence rule (cursor ignored when offset given). This enriches the annotation-based safety signals with concrete runtime behavior.
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?
Three efficient sentences with zero wasted words. Front-loads the core purpose, then filters, then pagination mechanics. Every clause adds information that isn't elsewhere, and the structure logically groups listing behavior, filtering, and pagination in order of importance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, which relieves the description of explaining return values. With 5 parameters, no required fields, pagination mechanics explained, and read-only idempotent semantics assumed from annotations, this is reasonably complete. Minor gap: doesn't name sibling alternatives (search_detections) for when broader search is needed, but the complexity is low enough that the description suffices.
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 coverage is 100%, so all five parameters are documented in the schema. The description adds the relationship between cursor and offset (cursor decoded to offset, ignored when offset given), which is genuinely helpful beyond the schema. However, the individual parameter descriptions in the schema are already thorough; the description's contribution is mainly the cursor/offset interaction nuance, warranting baseline 3 rather than higher.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb+resource ('List detection logic') and enumerates the content formats (Splunk SPL, Microsoft KQL, Sigma). It distinguishes from siblings like search_detections (which implies a search action) and get_detection_detail (singular detail) by specifying this is a listing operation with filters. Clear differentiation from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clarifies pagination behavior and mentions optional filtering by threat_id or type, giving clear usage context. However, it doesn't explicitly contrast with search_detections or get_detection_detail, nor state when to prefer this over those alternatives. The pagination guidance is strong but sibling differentiation is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds useful interpretation context: flow-derived findings only apply to the covered portion of the corpus, and clarifies the special gate semantics, which is beyond annotation content.
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?
The description is compact and front-loaded about the returned information; the second sentence provides the operational instruction. There is no redundant wording or unnecessary schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-input, read-only tool with an output schema and annotations, the description provides enough context about what coverage means, how it is split, and when to call the tool. No essential guidance is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description is not expected to document parameter semantics. Schema already covers the entire parameter surface.
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 what the tool reports: corpus-wide ATT&CK Flow coverage split by provenance, plus totals for nodes, transitions, and path similarity, and the coverage-gate status. It is specific and reader can distinguish it from siblings like get_attack_flow and get_mitre_coverage, though it doesn't explicitly name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to call this tool before reasoning over flow data so that findings are correctly interpreted against the covered slice. It gives clear usage context, but it does not state explicit when-not-to-use conditions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is established. The description adds the composite-content framing and that it returns 'full story' in a single call, which is marginally useful context. It doesn't note rate limits, data freshness, or what happens for unknown indicators, but with strong annotations the bar is met at a moderate level.
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?
Two sentences, both earning their place. The first states what the tool returns; the second gives routing guidance with a sibling alternative. Zero filler, front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value explanation isn't needed. With strong annotations (read-only, idempotent), strong schema (100% coverage), and one simple parameter, the description covers the essential context. It could potentially mention what happens with an unrecognized indicator, but for a single-param read-only dossier tool, this is sufficiently complete.
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 description coverage is 100%, so the schema already documents the 'value' parameter as an exact indicator value (IP, domain, hash, or URL). The description reinforces that a single exact indicator is expected, which aligns with the schema. Since the schema does the heavy lifting, baseline 3 is appropriate; the description adds little beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get'), resource ('composite intelligence dossier'), and scope ('for one indicator'), then enumerates contents: linked threats, actor attribution, related IOCs, and enrichment context. It also distinguishes itself from the sibling search_iocs by clarifying it works with an exact indicator value. This is a specific, well-defined purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly directs to prefer this over search_iocs when an exact indicator value is available and full context is needed. This implies search_iocs is for broader/fuzzy searches. Naming the alternative tool with a clear when-to-use rule is exactly what dimension 2 rewards.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior, so the description does not need to repeat those guarantees. It adds behavior context by stating the latest-day default, the date override behavior, and the aggregate contents returned in the bundle. This is useful supplementary context and is fully consistent with 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted text, and it front-loads the tool's core purpose and composition. The second sentence is a high-value routing signal that helps the agent decide what to do after receiving the bundle. Every part of the description earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero required parameters, a rich output schema, full schema description coverage, and read-only/idempotent annotations, the description is sufficiently complete. It explains what the response will contain, how to customize it via date, and what to do next for more detail on a threat.
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?
The schema already describes both parameters with 100% coverage, so the description only needs to add marginal semantic value. It adds 'latest by default, or pass date' for date and summarizes top_n as 'top threats as LEAN summary rows,' but this mostly restates default semantics that a capable agent can already derive from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a one-shot aggregate 'what happened' bundle composed of a debrief, platform stats, top recent threats, and correlations. It names a concrete resource category that an agent can distinguish from single-purpose sibling tools like get_debrief or get_correlations, and it even points to a complementary sibling, get_threat, for drill-down.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'One-shot what happened bundle' gives a clear contextual use case: use this for a consolidated daily situational snapshot in a single call. It does not exhaustively contrast this with similar aggregate siblings such as get_landscape_briefing or get_threat_bundle, but it does provide useful routing guidance by saying to use get_threat(id) when more detail on a listed threat is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnly, idempotent, and non-destructive behavior, so safety is covered. The description adds valuable context about the output structure (posture summary, themes, threats grouped by severity, etc.), which is not redundant 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?
Two sentences deliver the core purpose, output contents, and a prerequisite instruction. No redundant wording; highly efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and annotations cover safety, the description is complete for an agent to invoke. It lists the debrief sections and the necessary prerequisite step, making it sufficient for correct use.
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?
The input schema fully documents the date parameter with format and example (100% coverage). The description only repeats the YYYY-MM-DD format, adding no new semantic information beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a full daily intelligence debrief for a specific calendar date, listing its contents (posture summary, themes, threats, etc.). It differentiates from sibling tools like list_debriefs and get_latest_debrief by emphasizing 'specific calendar date' and referencing the prerequisite list_debriefs call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly directs users to first call list_debriefs to find available dates, providing a clear usage guideline. It does not enumerate all alternative tools, but the instruction implies this is the tool for a specific date rather than the latest debrief.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds meaningful behavioral detail beyond annotations: the scoring algorithm, the ATT&CK Flow transition concept, and the expectation that it returns inspectable shared transitions like 'T1003>T1021'. 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?
Every sentence earns its place: the core operation, the uniqueness explanation, the return contract, and the independence from get_similar_threats. It is front-loaded with the primary verb and resource, and there is no padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With the output schema present, parameter meanings fully documented, and annotations covering side effects, the description is complete enough for an agent to successfully call this tool. The remaining constraints like min_score and limit are already captured in the 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 description coverage is 100%, with meaningful definitions already provided for threat_id, limit, and min_score. The description does not need to restate parameter details, and it does not meaningfully expand beyond what the schema says. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the specific action: finding threats that share a causal SEQUENCE of techniques, using ordered-bigram cosine over ATT&CK Flow transitions. It also distinguishes this tool from the sibling similarity tool by explicitly stating its score is NOT folded into get_similar_threats' blended score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context on when this tool is valuable: when attack ORDER matters and flat-set similarity signals are insufficient. It names get_similar_threats as the alternative and contrasts its blended scoring, but it stops short of explicitly listing when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds meaningful context beyond these annotations: it clarifies that the data is 'previously resolved and cached' and explicitly flags that this is NOT a live lookup — a key behavioral caveat not captured by any annotation. Minor deduction for not describing the output format beyond 'reverse-IP and subdomain records.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences and tightly written with zero filler. It front-loads purpose in the first sentence, adds the critical non-live caveat in the second, and points to the alternative in the third. Every sentence earns its place. Minor deduction only because the parenthetical 'reverse-IP and subdomain records' could arguably be integrated more cleanly, but this is essentially optimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple single-parameter read operation with comprehensive annotations (readOnly, idempotent, non-destructive) and an output schema present, the description is largely complete. It covers the stored-vs-live distinction, the input scope, and points to the richer sibling. Context signals show only 1 parameter, 100% schema coverage, and presence of an output schema, all of which reduce the descriptive burden. Could add pagination/limits info for many-record DNS results, but that's speculative.
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 description coverage is 100%, and the single required parameter 'value' has a clear description ('IP address or domain'). The main description reinforces the acceptable input types. Since the schema already documents the parameter fully, the baseline of 3 applies — the description adds slight value by phrasing it as 'stored DNS enrichment lookup' but not much beyond schema. There's only 1 parameter, so there's little semantic ambiguity to resolve.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'Return stored DNS enrichment for an IP or domain indicator.' It specifies the resource (stored DNS enrichment), the scope (IP or domain), and explicitly differentiates from siblings ('Use get_ioc_intelligence for the full stored dossier'). The verb 'Return' plus resource is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes this is a read of stored/cached data, NOT a live lookup at call time, which prevents misuse. It also names the alternative get_ioc_intelligence for a fuller dossier, giving clear when-to-use vs when-not guidance. This is exceptional usage guidance for a retrieval tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, and non-destructive behavior. The description adds valuable details beyond that: the ranking formula, that tactic matching is spelling-insensitive, and that summary.gaps/coverage_pct describe the filtered corpus rather than the returned page, which is an important caveat.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized for the subtleties involved: it defines the ranking, the filtering behavior, and the summary caveat in two sentences. It is a bit dense with the formula, but every component is useful rather than redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema and only two optional parameters, the description covers purpose, ranking, filtering, limit semantics, edge-case behavior for unmatched tactics, and a confusing summary nuance. It could be even stronger if it explicitly contrasted this tool with get_mitre_coverage or get_technique_rules, but it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema itself documents both parameters. The description still adds value by clarifying that tactic filtering is case/spelling-insensitive, including variants like 'Execution (ICS)', and that limit=N-N maps directly to debt_score-descending top N rows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns a prioritized list of MITRE ATT&CK techniques with the weakest detection coverage, ranked by debt_score. It goes beyond the title by defining what gap analysis means here and clearly distinguishes this from sibling coverage/technique tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear operational guidance: filter by tactic, use limit as a cap, and understand that limit=N yields the top-N worst. It does not explicitly name alternative tools or state when not to use this, but it gives solid context for normal invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds value by revealing return behavior: evidence per link, score breakdown, dominant signal, shared indicators, and quality flags for stale or high-confidence-low-evidence links. This gives an agent useful expectations beyond the schema.
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?
Two dense, front-loaded sentences. The first sentence immediately states what the tool returns and the key evidence qualities; the second routes to the related correlation tool. No filler or repeated annotation content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, idempotent, two-parameter tool with a complete schema and an output schema, the description sufficiently explains the purpose and result shape. It also tells the agent where to go for the deeper follow-up task, so nothing essential is missing.
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?
The input schema already documents both parameters fully, including an example ID and the limit cap. The description adds no new parameter-level meaning, but because coverage is 100%, the schema carries the burden and the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific resource (threats similar to a given threat) and explains what the results contain: evidence, per-channel score breakdown, dominant signal, shared techniques/IOCs/CVEs, and quality flags. It also names explain_correlation as a related but distinct tool, which prevents confusion with sibling tools such as get_flow_similar_threats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is for finding and comparing multiple similar threats, and explicitly says to use explain_correlation when you need a full decomposition of one specific pair. It does not enumerate every sibling alternative or say when not to use it, but the primary alternative is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that the tool is read-only, idempotent, and non-destructive. The description adds useful behavioral context by noting that key validity is checked and that platform counts plus the latest debrief date are returned. There is 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?
The description is a single, well-front-loaded sentence that conveys the tool's purpose, scope, and outputs without filler. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, rich annotations, and an output schema, the description is complete for a health-check tool. It tells the agent what the call verifies and what data comes back, and nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there are no parameter semantics for the description to clarify. The schema is already fully straightforward, giving a baseline of 4; the description does not need to compensate for any missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific purpose: it is a lightweight liveness probe that confirms API reachability and key validity, and it names what it returns (platform counts and latest debrief date). This clearly distinguishes it from the many data-retrieval sibling tools.
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?
The description implies usage as a lightweight connectivity and credential check, but it does not explicitly say when to prefer this over siblings like get_platform_stats or get_latest_debrief, nor does it state when not to use it. The guidance is inferred rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds non-obvious behavioral detail beyond those: score is per technique accounting for corpus threats, ranking is within a tactic, the layer is capped at 600 techniques and may carry a 'truncated' entry, and ATLAS/non-enterprise IDs are excluded. These are important for correct interpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and front-loaded with the primary purpose, but includes a full returned-structure list that duplicates the output schema. That sentence is slightly redundant, but otherwise every sentence earns its place and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given branch annotations and output schema exist, the description completely covers non-obvious behavioral details: the meaning of 'score', how the two modes differ, truncation behavior, exclusions, and the exact matching between parameters and use cases. Nothing critical is missing.
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 description coverage is 100%, so the schema already documents both parameters. The description largely mirrors that information and adds only a scoring context rather than substantially enriching individual parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Export a MITRE ATT&CK Navigator layer (enterprise-attack) for visualization.' It clearly distinguishes this tool from siblings like export_stix or get_mitre_coverage by naming the exact artifact and domain scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent to 'pass actor=<name>' for actor-level coverage or 'all=true' for platform-wide coverage, which is clear usage guidance for the two parameters. It does not explicitly enumerate when not to use this tool versus neighboring export/get_mitre tools, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, non-mutating operation. The description adds useful context about the output being deduplicated network indicators and firewall-ready format, but doesn't disclose additional behavioral traits beyond that (e.g., recency window, format specifics, or staleness policy). With annotations covering the safety profile, adding the dedup/actionable context earns a moderate score.
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?
Two sentences, front-loaded with the core purpose, and the second sentence provides the alternative-tool guidance. Every clause earns its place with zero filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters, an output schema exists, and annotations fully declare the behavioral safety profile. The description covers purpose, output format, and alternative tool selection. The only minor gap is not clarifying the exact recency window or time range of 'recently observed' indicators, but with an output schema present, the return format doesn't need description. This is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema description coverage is trivially satisfied. The description does not need to explain parameters because there are none. A baseline of 4 is appropriate for a zero-parameter tool where there is nothing to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: compiles a firewall-ready C2 blocklist of active IPs, returns deduplicated indicators ready for a denylist. It distinguishes itself from sibling get_c2 by specifying when to use each ('use get_c2 with view="beacons" when you need the underlying beacon detail'). Specific verb (compile/generate) + specific resource (C2 blocklist) makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Use this for actionable blocking') and names the alternative (get_c2 with view='beacons') for when beacon detail is needed. This is an explicit when/when-not pairing with a sibling named directly, satisfying the highest bar for usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent hints, the description discloses exactly how attribution is filtered and ranked: only shared entities whose actor list includes this actor or its aliases, with shared malware/infrastructure ranked above commodity TTPs. This adds meaningful behavioral context that annotations do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences carry the full message: the core purpose is front-loaded, followed by scope and ranking details. It is somewhat dense with parentheticals and capitalized emphasis, but every phrase adds value without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return details need not be described. A single required parameter is fully documented in the schema, and the description covers filtering, ranking, and intended use, making the tool callable without ambiguity.
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?
The schema already fully covers the single 'name' parameter with its type and example. The description does not add parameter-level detail, but with 100% schema coverage, the baseline applies without requiring compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific composite intelligence picture for a threat actor with an enumerated scope: profile, actor_relationships baseline, and cross-actor attribution. It distinguishes itself from simpler siblings like get_actor or get_actor_relationships by emphasizing the cross-actor attribution component.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly frames the use case: "Use it to answer 'who else does this actor overlap with, and on what evidence'." It also explains scope boundaries, but does not name alternative tools or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds meaningful behavioral context by explaining the output categories (dedicated/mixed/shared fidelity, compromised flags) and the underlying reverse-DNS approach. It does not contradict any 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?
Two concise sentences, front-loaded with the core purpose. The second sentence adds actionable guidance on filtering. No filler or redundant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and annotations covering safety, the description fully explains the tool's purpose, key filters, and output nature. It does not address pagination or edge cases, but these are not critical for a read-only get tool with schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers limit and compromised descriptions; description reinforces fidelity filtering and compromised-host flags, giving tactical meaning beyond the enum. Limit's default/max is already in the schema, so no duplication needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource: 'Reverse-DNS unmasking of C2 beacon infrastructure' and explicitly states what it returns (domains per IP, fidelity, compromised-host flags). It clearly distinguishes this from sibling tools like get_c2 or get_ioc_dns by focusing on infrastructure fidelity and shared-hosting separation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: 'Answers "what else lives on this C2 infrastructure"' and instructs to 'Filter by fidelity to separate adversary-owned infrastructure from shared hosting.' It does not explicitly name alternative tools, but the guidance is sufficient for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the readOnlyHint/idempotentHint annotations by explaining subtle behaviors: the threat_ids field is a live join from threats.cve_list, stale derived-index disagreement is surfaced via threat_ids_note and threat_ids_derived_only, pre-release CPEs are collapsed into ranges, and blank CVSS/EPSS values mean NOT MEASURED. This is exactly the kind of behavioral context an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but each sentence earns its place by adding non-obvious operational details (live join, derived-only fallback, CPE collapsing, enrichment_status semantics, sibling routing). The core lookup purpose is front-loaded. It is somewhat long, but the complexity of the behavior justifies the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a small, single-parameter tool, this description covers all needed non-obvious context. The output schema can document the return structure, so the description correctly focuses on semantics that would otherwise be a surprise: linkage provenance, stale index handling, collapsed counts, and the meaning of absent metrics. Nothing critical appears missing.
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?
The input schema already documents cve_id with an example (CVE-2024-3400), and schema description coverage is 100%. The description repeats the same parameter guidance without adding new syntax, formatting, or validation details, so it provides no extra meaning beyond the schema. A baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: looking up a CVE by identifier and enumerating the specific data returned (description, CVSS, EPSS, KEV, weaknesses, products, references, threats). It also distinguishes itself from get_cve_intelligence by noting when that richer tool is preferred.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit routing recommendation: prefer get_cve_intelligence when linked threats need titles, actors, detections, or velocity in one call. It also explains important interpretation context for enrichment_status and collapsed CPEs. It does not mention other sibling alternatives like bulk_get_cves, but for a single-CVE lookup the guidance is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive. The description adds genuinely useful behavior beyond those annotations: NPMI edges carry raw pmi/co-occurrence/marginal values, rarity is defined in terms of corpus_df vs corpus_n, and top_neighbors_truncated can hide low-fidelity neighbors unless limit is raised. This is transparent about an easy-to-misread response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded and information-dense: the first sentence defines the core purpose, and the following sentences add high-value details like the NPMI payload, rarity semantics, and truncation caveat. It is somewhat long and technical, but no sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, annotations, a moderate parameter list, and strong parameter descriptions, the description supplies the missing context about return content, edge fields, rarity interpretation, and pagination/limit caveats. For a complex intelligence-graph endpoint, nothing essential for correct invocation appears to be missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, with node_id and limit already described, and node_type sufficiently conveyed by its enum. The description adds real parameter value: it explains how limit interacts with fidelity ordering, which matters because low-fidelity edges are the first dropped. It also contextualizes the node_id values across node types. This exceeds the baseline without fully replacing the schema's per-parameter detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a one-call dossier for any intelligence-graph node, naming the supported node types (threat, technique, actor, IOC, CVE). It distinguishes itself from the many sibling getters such as get_threat/get_actor/get_cve by claiming to replace five or six separate lookups, so an agent can select it with confidence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use it: when a consolidated overview with neighbors, rankings, and type-specific rollups is needed, and that it is the best token-per-call option in the graph family. It also gives practical guidance about checking top_neighbors_truncated and raising limit before concluding a neighbor is absent. It does not explicitly name alternatives or give when-not-to-use conditions, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds value beyond annotations by warning that a cluster of one event documented multiple times can look identical to a real multi-event campaign until the agent reads the duplicate_risk evidence fields (distinct_member_dates, date_span_days, shared_title_tokens). That is non-obvious behavioral context which prevents an agent from misinterpreting results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core identity of the tool is front-loaded ('Campaign clusters the engine assembled from the similarity graph'), and the differentiation from sibling tools comes in a clearly marked second sentence. The first sentence is dense with enumerations, but each item corresponds directly to actual return fields, so there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one documented parameter and an output schema, the description fully explains the resource's origin, content, cluster semantics, the duplicate_risk caveat, and the naming neighbor tools. No information needed to call it correctly or interpret its output is missing.
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 description coverage is 100% — the only parameter, limit, already carries a full schema description (default 15, max 50). The description adds nothing parameter-specific, but it does not need to; the schema fully documents the single input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a precise verb ('reports') and a well-scoped resource: campaign clusters the engine derived itself from the similarity graph (connected components + label propagation), with an explicit list of contents (label, cohesion, actors, techniques, IOCs, nation-states, per-member fields). It also differentiates itself from get_campaign_intelligence and list_campaigns, making the tool distinguishable from its closest siblings without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit routing rules: use get_campaign_intelligence when looking up a NAMED campaign from threat text, use list_campaigns for the roster of named campaigns, and use this tool for the clusters the engine derived itself. Each alternative is named with a criterion that selects it, leaving the agent with no inference to make.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering the safety profile. The description adds meaningful value by explaining pagination behavior — that next_cursor is opaque, reusable as offset/cursor, and that offset/cursor interplay ('ignored when offset is given') — which goes beyond what annotations provide.
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?
Two sentences, zero wasted words. The description front-loads the core purpose in the first clause, then packs the pagination contract concisely. Every phrase ('opaque', 'reusable as offset/cursor') earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a valid output schema, high schema coverage, and strong annotations, the description is nearly complete. It explains the essential pagination contract clearly. The only minor gap is not naming alternatives explicitly, but for a paginated list tool this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are fully documented in the schema. The description adds value by clarifying the relationship between cursor and offset (cursor decoded to offset, ignored when offset given) and describing the has_more/next_cursor return format, which compensates meaningfully beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb+resource ('List the most recently published threats') and adds the pagination scope detail. It distinguishes from siblings like get_threat (single), search_threats (search filter), and get_similar_threats (similarity) by emphasizing 'recently published' ordering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description and parameter docs explain pagination mechanics (limit, offset, cursor, has_more, next_cursor). It doesn't explicitly state when to prefer this over search_threats vs get_threat, but the 'most recently published' framing and pagination semantics give clear usage context without naming alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, so the safety burden is covered. The description adds valuable behavioral nuance beyond annotations: the meaning of 'grounded' vs 'threat_record' and the critical 'unmapped' warning that 'not mapplied ≠ not target'. This is genuinely useful, though some runtime details (e.g., error handling of invalid ID) could still be expanded.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: the first structures the resource, the second gives the sibling-guidance, and the third gives an important caveat about the 'coverage' field. Each sentence carries weight without going too long; the description is dense but every inline list member affects what the agent needs to know about the response.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-ID, read-only, idempotent tool with an output schema present, the description covers the whole decision context: when to call it, what it returns, how to interpret coverage values, and the false-negative trap of 'unapped'. It grounds the awkward "empty array" case up front, giving an agent everything needed to make a correct call and correct interpretation.
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?
The schema description coverage is 100%, and the schema already says the id is a Threat ID with an example. The description merely repeats that it's by ID and adds no additional parameter syntax, constraints, or format. Therefore a baseline 3 is appropriate since the schema carries the parameter-semantic burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific resource and verb: 'Reference-grounded enrichment for one threat by ID', then enumerates exactly what is returned (malware families, tools, sectors, OS, campaigns, ATLAS techniques, mitigations). It also clearly separates this tool from get_threat by naming the difference between its full-fields view and get_threat's overview/MITRE/IOCs/detections. This leaves no ambiguity about what the tool does or how it differs from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to call this tool: 'call this for the "what malware/tools were used and who was targeted" view', and names get_threatest as the complement. It also gives conditional guidance for reading the 'coverage' field, which is a direct interpretation rule that prevents misreading empty arrays.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds genuinely useful behavioral context: the bundle is composed server-side, every section is bounded so the response fits in one call, and limits can be raised or fallback tools used. It does not mention latency or payload-size expectations, but it goes well beyond 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences; the first explains composition, the second gives the primary use case, and the third explains limits and when to use alternatives. Every sentence earns its place, and the description is front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-call bundle tool with an output schema and 100% parameter schema coverage, the description covers what the bundle contains, why and when to use it, how to control response size, and what to call instead for full lists. Nothing needed for correct selection or invocation is left out.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are already well documented. The description adds extra value by explicitly tying simulation_limit and pivot_limit to the bounded-list behavior and by naming the fallback tools to get complete lists. This is more than the baseline, though each parameter's precise meaning still comes from the schema.
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 names a specific verb and resource: a one-call hunting dossier that composes threat detail, similar threats, simulations, and infrastructure pivots server-side. It clearly differentiates from get_threat and get_infrastructure_pivots via the fallback note, but it does not explicitly distinguish from the closely titled sibling get_threat_bundle, so it misses full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says this is the best single tool to scope a hunt around one threat and gives concrete when-not usage: raise simulation_limit/pivot_limit, or call get_infrastructure_pivots and get_threat directly when full lists are needed. This is clear, actionable selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value beyond annotations by disclosing the semantic nature of the returned data: provenance, not analysis, and stubs rather than prose. This corrects a realistic misreading of the tool name (transcripts as analyst discussion) and tells the agent what not to expect from the output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the key distinction (provenance vs. analysis), then enumerates the useful return components, then gives the caveat and routing guidance. It is slightly dense — the full enumeration of the 7 phases and gate metrics could be trimmed — but every clause earns its place, as it shapes an agent's expectations about content the name misleadingly implies.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return-value mechanics are covered structurally. For a one-parameter read-only tool, the description is complete: what it returns, what it does not contain, how the parts fit together (phases, gates, score, handoff log, correlation highlights), and how to choose among siblings. Nothing an agent needs to call it correctly is missing.
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 coverage is 100% with the single threat_id parameter fully documented (type, description, example 'TL-2026-0042'), so the schema does the heavy lifting. The description does not add parameter-specific semantics beyond the example already in the schema, which is acceptable at full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States precisely what is returned: the 'PIPELINE PROVENANCE record,' and immediately disambiguates it from analysis with 'how its profile was produced, not analysis of the threat itself.' The description names the resource (pipeline phases, quality gates, handoff log) with enough specificity that an agent can distinguish it from get_threat, get_threat_enrichment, and get_attribution_evidence without opening their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is given: 'Use this to judge how thoroughly a threat was worked and to find its related-threat/IOC leads,' followed by named alternatives with their purposes ('use get_threat or get_threat_enrichment for the analysis, and get_attribution_evidence for why it is attributed'). The description also sets a negative expectation — handoff messages are routing stubs, not analyst prose — preventing a likely misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains what the tool returns in detail (channels, dominant channel, artifacts, signal count, quality flags) beyond what output schema could convey. It also discloses the 404 behavior when no edge exists, which is useful behavioral context. The readOnlyHint=true and idempotentHint=true annotations are consistent with the description's read-operation framing, so there is no contradiction. The 404 disclosure adds genuine value not present in 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?
Two dense sentences with zero wasted words. Every clause carries informational weight - the return contents, the intended usage trigger, the order-independence note, and the 404 case. Front-loaded with the primary purpose, followed by usage context. This is exemplary conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema present, so return value documentation is handled there. The description covers the essential behavioral surface: what it computes, what it returns, when to use it, how parameters relate (order-independent), and the error case (404). For a relatively simple two-parameter correlation explanation tool with annotations and output schema supporting it, this description is complete.
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 coverage is 100% and both parameters are self-documenting ('First threat ID' / 'Second threat ID'). The description adds one meaningful detail beyond the schema: the pair can be passed in either order (order independence). With complete schema coverage, baseline 3 is appropriate, and the order-independence note justifies not docking further but doesn't elevate beyond 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource structure ('explain correlation') with detailed scope: the per-channel similarity decomposition, dominant channel, shared artifacts, signal count, and quality flags. It clearly distinguishes this tool from the sibling get_correlation_path, get_correlation_subgraph, and get_similar_threats by focusing on the evidence/explanation behind a similarity score rather than the path or subgraph.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Use when get_similar_threats gives a score and you need the evidence behind it'), naming the predecessor tool by name. It also addresses invocation details ('Pass the pair in either order' - order independence) and the 404 error case when no edge exists. This is model usage guidance with explicit trigger conditions and alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/idempotent annotations by explaining the deterministic nature of the projection, the 197-of-1,891 coverage rate, the 200-with-empty-mappings case, why that absence is not an error, and when a 404 is actually returned. This is exactly the behavioral nuance an agent needs 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence in the description carries load: the core purpose, the coverage limitation, the empty-vs-notch response, and the interpretive caveat. The COVERAGE and IMPORTANT markers make the longer text easier to parse, and the most actionable guidance appears first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one required param and a complete output schema, the description still covers the full behavior: the default result, rare-empty state, the 404-only condition, and the fatal conclusion. There is no ambiguity left for an agent in interpreting either a result or an error from this tool.
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 description coverage is 100%, and the schema already documents threat_id format and limit's default, max, and behavior. The description adds no new parameter-level meaning, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get') and a concrete resource: the defensive twin mapping from ATT&CK technique to artifact to D3FEND countermeasure, with coverage by defensive tactic. The scope is unique among the sibling tools and directly answers 'what would have stopped this'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use it for 'what would have stopped this' and gives clear behavior expectations: absence of a mapping is common and not an error, and countermeasure overlap must not be treated as correlation evidence. It does not name any alternative sibling tool, so the 'vs alternatives' guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses subtle behaviors that annotations cannot capture: tags are recomputed live, tags_source distinguishes live/snapshot/none, and the theme sentence may be generated before ingest finishes, making snapshot_threat_count and theme_note potentially inconsistent. It also gives trust guidance: when they disagree, trust tags. This exceeds the baseline provided by 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?
Three dense, purposeful sentences each deliver a distinct semantic point: the core data scope, the live/snapshot/no-tag distinction, and the stale-theme caveat. The most important information is front-loaded first and the description contains no wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-argument read tool, the description covers ordering, time horizon, ranking rules, tie-breaking, field provenance, staleness, and a trust heuristic, leaving no call-critical question unanswered. The output schema can fill in exact field names, so no missing return-value explanation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters, so there is no input-schema ambiguity for a description to resolve. The description appropriately devotes its space to output semantics rather than parameter details, matching the baseline for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Begins with a concrete verb and resource: 'Get the recent daily landscape themes', immediately scoped by 'newest first, 14 days' and 'top 6 threat tags'. This makes the tool's identity and output unmistakable and clearly differentiates it from other daily-intel sibling tools.
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?
The intended use is strongly implied: call this when you need recent daily landscape themes with associated threat tags. However, it does not explicitly say when to prefer this over similar intel-read siblings such as get_landscape_briefing or get_daily_intel_bundle, so there is no direct alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare the operation readOnly and idempotent, but the description adds significant non-obvious behavior: failed hourly runs still write a one-bullet posture stub, the newest row is usually not a genuine synthesis, and fallback status is exposed through fields like latest_is_fallback and narrative_ok. This is exactly the kind of appendix the model runtime an agent would never infer from annotations alone.
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?
The first sentence delivers the core purpose, and the following sentences provide only high-value caveats and field names. Each piece adds actionable detail — the fallback condition, the fields that detect it, and the invariant that briefings[0] is the newest row. There is no filler and no duplication of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with no parameters and an output schema, the description covers the entire important decision surface: what the tool returns, when the newest row is unreliable, what fallback indicators exist, and how to determine whether the newest narrative is real. Nothing material is missing for correct invocation and interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics for the description to elaborate. Schema coverage is effectively 100% and the 0-parameter baseline applies. The description correctly spends its limited length on response semantics rather than inventing parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Get the latest threat-landscape briefing' and defines it as 'a synthesized posture summary of recent threat activity.' It also clearly distinguishes the tool by explaining that the latest returned row is usually a fallback stub, not a real summary, which separates this tool from simpler briefing fetchers.
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?
The description implies usage when a latest landscape briefing is wanted and goes into depth about how to interpret the response. Nevertheless, it does not explicitly compare with related sibling tools such as get_latest_debrief or get_daily_intel_bundle, nor does it state when this tool should be preferred or avoided. Usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds substantive context: index freshness, coverage of the grammar, and a stable 'call once' nature. No contradiction exists between the description and 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?
Two tight sentences contain no filler. The content inventory is front-loaded and the usage instruction is direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what the tool returns, when to call it, and how often. Combined with strong annotations and an output schema, an agent has everything needed to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and schema coverage is complete, so the description does not need to explain parameters. The content description is relevant and sufficient for a no-argument schema reference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as the authoritative source for the hunt query grammar, enumerating exactly what it contains: fields, aliases, operators, stats-pipe form, examples, and index freshness. This distinguishes it from the sibling hunt tool and other data-retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Call once before writing a hunt query' gives explicit when-to-use guidance and implies the result can be cached. It does not name alternatives or exclusions, but the tool is a targeted reference with no obvious alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state readOnlyHint, idempotentHint, and destructiveHint. The description adds important nuance: 'newest first', the presence of has_more when the page is full, that offset is not honored, and that mitre_techniques_sample is a 'NOT AMAN' first-10 alphabetical list rather than a top-10. This goes well beyond the annotations and prevents an agent from making incorrect assumptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is packed with useful behavioral context, but it also enumerful detail of the output fields (new/updated threats, theme, categories, actors, severity counts, and more) even though an output schema exists. Those are not strictly needed and make the description longer to parse, though it remains well-structured and legible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even with an output schema and simple parameter, the description supplies all key contextual steps: the listing purpose, the sibling routing, the has_more pagination flag, the offset limitation, and the ordering. An agent can confidently decide to call the tool and interpret its lack without extra refinement.
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 coverage is 100% and the single parameter limit is already documented with its default and max in the parameter description. The tool description merely repeats that ('Pass limit (default 30, max 100)') without adding any new meaning. Baseline for full schema coverage applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with a clear resource ('recent daily intelligence debriefs') and states that results are 'newest first'. It also explicitly contrasts itself with get_debrief, distinguishing the tool from its closest sibling and making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool ('Enough to pick the day worth drilling into') and when to use the alternative ('use get_debrief for a date's full details'), and describes the limitation that offset is not honored. The instruction is clear and directly names the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the return contract (canonical reference form + stable UUID) and the type-narrowing behavior. It doesn't describe edge cases like unmatched names, but with strong annotations plus stated return contract, a 4 is appropriate.
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?
Two dense sentences with zero waste. Every clause earns its place: the normalization behavior, the example, the explicit call sequencing, and the type note. Ideally front-loaded and highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, 1 required), has an output schema (so return format is documented elsewhere), has high schema coverage, and strong annotations. The description covers purpose, usage context, return type, and specific integration points. There is genuinely nothing missing for an agent to correctly invoke this tool.
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 coverage is 100% — both parameters (name, type) are described in the schema. The description adds the type enum semantics ('Optional type narrows the lookup') which supplements the schema's type list. Parameter info added beyond schema is present but minimal, so baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Normalize') with a clear resource (entity names/aliases to canonical form + UUID), provides a concrete example ('fancy bear' → 'APT28'), and explicitly differentiates it from get/search tools. Purpose is unambiguous and distinct from all siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call this tool ('BEFORE pivoting to get_actor / get_malware_intelligence / get_tool_intelligence / search_threats when unsure of the canonical name'). This gives crystal-clear sequencing guidance and names the exact alternative tools it pairs with, exceeding a simple when-to-use statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered by structured data. The description adds genuine value beyond annotations: it discloses the AI Search binding dependency, rate-limiting behavior, and crucially that a 503 means index unavailability rather than no match — an important interpretive insight for agents handling errors.
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?
Three sentences, zero filler. The opening sentence states purpose and output, the second provides usage guidance, and the third covers dependencies and error interpretation. Every sentence earns its place with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a single-param tool, it's sufficiently complex (retrieval strategy, ranking, dependencies, rate limits, error semantics) and the description covers all of these dimensions. With an output schema present, return-value explanation is unnecessary. The description is complete for an agent to select and invoke this tool correctly.
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 coverage is 100% — the single query parameter is documented in the schema as 'A natural-language question or concept.' The description reinforces this with 'Vector + rerank' language and returning 'ranked source cards,' but doesn't add significant format or syntax semantics beyond what the schema already provides. Baseline 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource+mechanism ('Vector + rerank retrieval over the whole corpus, returning ranked source cards'). It clearly distinguishes itself from sibling search_threats, which is described as 'boolean/exact over structured filters,' providing a strong sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('conceptual or paraphrased questions where the exact terms do not appear in the text'), when not to use ('when keyword search fails' implies use alternative first), and names the exact alternative (search_threats). This is textbook explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is already covered. The description adds value beyond annotations: it discloses pagination behavior (limit default 25/max 200 via offset) and the filter semantics. It doesn't describe the return format, but an output schema exists which covers that. Reasonable balance given the strong annotation coverage.
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?
Two sentences, front-loaded with the core purpose, and packs significant information: search domain (SPL/KQL/Sigma), search dimensions (rule text/technique/threat), filters (type/severity), and pagination (limit default/cap, offset). Zero filler or redundant restating of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with an output schema, 100% parameter schema coverage, and strong annotations (readOnly, idempotent), the description is complete. It specifies search domains, filters, pagination defaults/caps, and scope. The output schema handles return-value documentation. Nothing meaningful is left unspecified for an agent to execute a correct search.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters. The description adds value by enumerating the filter dimensions (type, severity, pagination with defaults) and search scope (rule text, technique, threat), providing semantic context like 'keyword search' that ties the parameters together coherently. It slightly exceeds the baseline 3 by framing how type/severity combine with the query.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Keyword search across detection logic (SPL/KQL/Sigma) by rule text, technique, or threat.' It clearly distinguishes from siblings like search_vulnerabilities, search_threats, search_iocs, and get_detections (which likely returns all detections without search). The scope (rule text/technique/threat) and optional filters (type, severity) are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: search across detection logic by rule text/technique/threat. It doesn't explicitly name sibling alternatives to contrast against, but the type filter (spl|kql|sigma) and severity option provide clear when-to-use context. It doesn't explicitly state when NOT to use it (e.g., use get_detections for unfiltered listing), but siblings with distinct names make this largely inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds valuable behavioral context beyond annotations: the tool is deterministic, returns LEAN summary rows (not full records), and discloses pagination mechanics (total, has_more, next_cursor, cursor vs offset precedence). This is genuinely useful behavioral disclosure over and above what annotations provide.
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?
Three dense sentences that each earn their place: the first defines output fields and full-detail redirect, the second explains filter combination semantics with a concrete example, the third covers pagination. No filler, no repetition of schema content, and result fields are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, an output-bearing description is not strictly required, yet it still names the exact fields. The description covers output shape, filter semantics, pagination, deterministic behavior, and the full-detail alternative. For a 23-parameter filtered-list tool with rich annotations and output schema, nothing material is left unexplained.
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 coverage is 100%, so all 23 parameters are documented in the input schema, making the baseline 3. The description adds meaning around combine semantics (AND-combining of all filters) and cross-references the category parameter to list_threat_categories, which goes slightly beyond the schema. However, most parameter behavior is already well-covered by the schema, so the description doesn't need to compensate much.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is a deterministic threat-catalog query tool that returns LEAN summary rows, explicitly listing the exact fields returned. It distinguishes from siblings by noting 'call get_threat for full detail on a specific id' and contrasts with search_vulnerabilities (different resource). The specific verb 'search/query' plus the deterministic qualifier and resource (threat-catalog) make the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains how filters AND-combine with a free-text query, provides a concrete multi-filter example ('query="supply chain" + threat_actor="TeamPCP" + category="SUPPLY_CHAIN"'), and directs the agent to call get_threat for full detail — clear when-to-use and when-not-to-use guidance versus its sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though readOnlyHint and idempotentHint already establish the operation is a safe lookup, the description adds important non-obvious behavior: CWE has no CVSS severity, likelihood_of_exploit is the ontology's own rating, related_cves is limited to top 20 with related_cve_count as the true total, and related_cves may be null when the join fails. This volume of field-level caveats goes well beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense with useful information and has no filler, but it is written as a long run-on paragraph with many embedded caveats, making it harder to parse than it needs to be. It is front-loaded with the core action and purpose, but the structure could be improved with short clauses or separation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only lookup with one parameter and an output schema, the description covers everything an agent needs: input format, available fields, related-tool routing, the CWE-vs-CVE severity distinction, and exceptional return values. No obvious behavioral gap remains.
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?
The parameter cwe_id is already fully documented in the schema with the exact format ('CWE identifier (e.g. CWE-79)'), and the description only repeats that same format without adding normalization rules or boundary cases. Since schema_description_coverage is 100%, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise directive — 'Look up a CWE by identifier' — and distinguishes this from CVE-related tools by explicitly noting that CWE has no CVSS severity and directing severity-seeking callers to related_cves or get_cve. It also names the sibling search_vulnerabilities for a fuller CVE list, so the tool is clearly scoped among its siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives actionable routing guidance: use this tool for CWE details, switch to get_cve for scored severity, and use search_vulnerabilities with cwe=<id> for the complete list of related CVEs. These explicit alternatives and conditions leave little ambiguity about when to select this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds rich behavioral context beyond these: deprecation and data availability, corpus-wide vs page-scoped counts, correlation block scope, the default-off facet payload, and pagination using has_more/next_offset. This far exceeds what the annotations alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured, front-loading the critical DEPRECATED warning and then layering pagination, correlation, and replacement guidance. It is longer than average, but the length is justified by important behavioral caveats; mild redundancy appears around the max 200 stating that limit, but not enough to obscure the value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool of this complexity, the description covers all needed invocation context: deprecation status, what the columns mean, pagination mechanics, scope-scaling behavior, optional payload size, and the preferred replacement tools. With an output schema also present, the agent has everything needed to call this tool correctly.
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?
The schema has 100% description coverage for limit, offset, and include_facets, and the description largely repeats those details, such as default 50 and max 200. It does add minor new meaning about facets containing 'actor/nation/category strings', but overall it does not significantly enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List adversary-emulation simulation scenarios across the platform (atomic test commands grouped by threat)'. It also clearly distinguishes this tool from related siblings by explicitly naming get_flow_coverage and get_attack_flow, and marking the tool as DEPRECATED, so an agent can tell exactly what this tool does and why it differs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-not-to-use guidance by declaring the tool deprecated and stating that 'Prefer get_flow_coverage and get_attack_flow — ATT&CK Flows replaced simulations'. It also explains the archived-rows-only nature, making the alternative recommendation clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds genuine value: states data is 'validated against CVE.org and enriched', reveals the COMPACT card return shape, and notes the default sort='trending'. Slightly less on pagination/rate limits but the compact-return disclosure is a strong contribution 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly-packed sentences with zero filler. All heavy detail is front-loaded in the first sentence. Slightly dense—the second sentence lists many filter options that partially duplicate the schema—but no wasted words. The return-format disclosure in the description is genuinely additional value, not repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only search tool with 100% schema coverage, an output schema, and full annotation coverage, this is complete. The description explains data provenance, enrichment sources, all filter dimensions, sort modes, defaults, and the compact return shape—plus points the agent to get_cve for more detail. Nothing material is left undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters, so baseline is 3. The description adds meaning beyond the schema: explains the card fields (cve_id, severity, cvss, epss_percentile, is_kev, etc.), reveals the default sort behavior, and explains that free-text query 'matches id + description'. This value-add justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource: 'Query the real-time CVE feed' with explicit sourcing (CVE.org, CVSS, EPSS, CISA KEV, PoCs, nuclei). Distinguishes from siblings: notably get_cve is referenced as the companion for full detail, and search_threats/search_iocs are different resource types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Extremely explicit: names all sort modes, filter dimensions, and return format. Explicitly says 'call get_cve(id) for full detail', providing a clear when-to-use-alternative instruction. Enumerates every available filter so the agent knows exactly what this tool supports.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description goes well beyond that by disclosing canonicalisation of tactic keys, DISTINCT technique counting, the 60-cap on mitre.technique_ids, relationship re-derivation, and the meaning of empty relationship lists. These are non-obvious behaviors an agent needs to understand the output.
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?
Though long, every clause carries semantic weight: the output inventory is compact, edge-case behavior is stated directly, and follow-up routing is front-loaded. The long sentence is dense but not bloated, and important caveats are placed ahead of alternatives.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description need not re-specify return shapes. It covers the response's semantics, known data-quality quirks, the coverage caveat for relationships, and alternative tools for heavier detail. Nothing needed to invoke or interpret this tool correctly is missing.
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 description coverage is 100% and the schema already documents name as 'Actor name or alias (e.g. 'APT29', 'Lazarus Group')'. The description's 'by name or alias' repeats rather than extends this. No additional parameter-level semantics are contributed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get a lean threat-actor profile by name or alias.' It enumerates the exact contents (metadata, attribution counts, MITRE rollups, IOC category counts, summaries, relationships), which clearly distinguishes it from siblings like get_actor_intelligence and get_threat.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'For heavy detail use the follow-up tools' and names get_threat, search_detections, get_detection_detail, search_iocs, and get_infrastructure_pivots. It also warns that an empty actor_relationships means 'UNRECORDED' rather than 'unrelated,' giving the agent interpretative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and idempotent, and the description adds substantial behavioral context: the distinction between data and tag_pairs, the field names and ranking order, the single_observation:true flag, and the data-quality caveat about 106 total pairs. This goes well beyond 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence provides operational value: scope, data field meaning, ranking, the small-n warning, and threshold semantics. It is structured logically and front-loaded with the core resource and purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only two parameters and an output schema, this description is unusually complete. It covers the data-quality caveats, field semantics, ordering, and interpretation warnings that an agent needs to correctly use the results. Nothing functionally important is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes both parameters at 100% coverage, but the description adds important semantics for min_cooccurrence: default 2 means the honest set, setting 1 includes single-observation pairs, and those rows should not be treated as true associations. This extra meaning goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('returns pairs'), a specific resource (MITRE ATLAS technique co-occurrence), and the scope (threats that attack AI/ML systems). It also explicitly distinguishes ATLAS techniques from free-text publish tags, so an agent can tell it apart from general MITRE or threat-search siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear on how to interpret results, especially the small-n warning: it tells agents not to report single-observation pairs as associations and that min_cooccurrence=2 is the honest default. It provides clear dataset context, though it doesn't explicitly name alternative sibling tools or when to use them instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior, so the description adds more useful behavioral context. It explains how to interpret the 'generator' field and asserts that 'derived' ordering must not be read as causality, which is valuable beyond what annotations or schema provide.
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?
Three focused sentences, each carrying necessary information: what the tool returns, an important causal interpretation caveat, and an alternative tool for similar causal sequences. No filler is present, and the most relevant definitions come first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich annotations, full parameter coverage, an output schema, and a detailed semantics explanation, the description fully equips an agent to understand what the tool returns and how to interpret it. The alternate tool reference adds extra context for when this tool is the wrong choice.
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 description coverage is 100%, so the parameters and their differences are already well documented. The description does not add much parameter-level detail, but it does clarify the semantic meaning of the returned data. With a high-coverage schema, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('get the analyst-authored MITRE ATT&CK Flow for a threat') and defines the result as a causal DAG of actions, conditions, operators, and assets. It explicitly contrasts itself with a flat technique list, which makes its purpose clear and distinguishes it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance by stating the tool returns asserted causality rather than a flat technique list, and warns against misreading 'derived' timelines as causal. It also names get_flow_similar_threats as the alternative for finding threats sharing a causal sequence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond that: it positions the data as 'live', names the default view as 'beacons', and clarifies that the tool returns raw records rather than transformed blocklist output.
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?
The description is compact: one sentence states the main purpose, one enumerates the views with useful semantics, and one names the alternative tool. Every section earns its place and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 100% schema coverage, an output schema, and robust annotations, the description only needed to add purpose, view semantics, and sibling differentiation — all of which it provides. The missing details such as exact default limits and the offset caveat are present in the input schema, so nothing essential is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline starts at 3. The description goes beyond the schema by clarifying what each view means — for example, 'watermarks' is a Cobalt Strike watermark index and 'correlations' contains cross-C2 correlations — which makes the enum values more interpretable for an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as querying the live C2 intelligence center and enumerates seven concrete views with short parenthetical definitions. It also distinguishes itself from the sibling generate_c2_blocklist by contrasting raw records with firewall-ready output, so an agent can pick the right tool without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains the available data views and names the alternative generate_c2_blocklist for firewall-ready output. This gives the agent concrete when-to-use and when-not-to-use guidance rather than leaving that to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond annotations by explaining how membership is computed (the lightweight UNION of curated references and threats matching by title), warns that the curated table is thin, names the `matched_via` field values, and tells the agent to treat title-matched rows as leads. This is excellent behavioral disclosure.
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?
The description is dense but every sentence serves a purpose: core action, output contents, membership source, and important caveat about trustworthiness. The warning about title rows is essential and the ClickFix example justifies why the union is needed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A given output schema handles return shape, and the description fully covers what the tool does, how membership is sourced, and how to treat results. Nothing important needed by an agent deciding to call or trust it is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the schema already documents the name parameter. The description adds extra value through concrete examples like 'Snowflake campaign' and 'ClickFix' and clarifies that title-based matching also matters, helping the agent pick a good input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Pivot on a named campaign / operation by name'. It lists concrete returns — threats, actors, prevalence, ATT&CK techniques — so an agent knows exactly what intelligence it will get for a named campaign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is clear: call this when you have a campaign name like 'Snowflake campaign' or 'ClickFix'. There is no explicit mention of when not to use it or comparison to sibling tools like list_campaigns or search_threats, so it does not reach 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that this is a hand-maintained release feed, not a deploy log, that it stopped being written in Feb 2026, and that the response carries latest_entry_date, stale_days, and a warning. This is valuable behavioral context well beyond what the idempotent/read-only annotations provide.
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?
Every sentence earns its place: the resource and ordering constraint, the parameter guidance, and the critical staleness warning with alternatives. The most decision-relevant caveat is front-loaded and clearly formatted with NOTE.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with an output schema, the description is fully sufficient: it explains the data source, staleness, expected response markers, and directs the agent to the correct sibling tools. Nothing needed for correct invocation is missing.
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?
The schema already documents limit with default and max values, and schema description coverage is 100%. The description restates 'Pass limit (default 20, max 100)' but adds no new semantic meaning beyond reinforcing that the parameter is optional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool returns the platform changelog — new threats, detections, and features — ordered strictly newest-first by date. It goes beyond a mere restatement of the name by specifying the content scope and ordering behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to avoid relying on this tool: for current platform state, use get_platform_stats or get_engine_status instead. It also warns not to answer 'what changed recently' from this feed alone, giving clear routing guidance relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is established. The description adds value by disclosing the tool is a status/health read that returns state rather than data, and enumerates the derived statuses (ok/stale/empty) and pipeline metadata that compose the response. This complements rather than duplicates 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler. The first sentence densely enumerates the return payload using semicolon-separated clauses, and the second gives one actionable directive. Every word earns its place with no rhetorical padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, read-only status tool with no nested objects, an output schema, and full annotations, the description is complete. It not only lists the payload categories but also the derived status vocabulary and the use-case context. There is an output schema to define return structure, so the description need not duplicate field details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4 per the rubric. The description appropriately focuses on describing what the tool returns instead of parameter usage, which is the correct approach for a parameterless tool. No parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific interrogative about pipeline health and enumerates exactly what is covered: per-engine row counts, last-compute times, ok/stale/empty status, nightly graph pipeline progress/stage/degraded flag, recent failures, and latest AUC eval. It clearly distinguishes from siblings like health and get_platform_stats by specifying the concrete data points returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The final sentence gives explicit guidance: 'Check this before reasoning over correlation output if freshness matters.' This is a clear when-to-use directive tied to a specific downstream workflow (correlation reasoning). Though it does not name alternative tools, it provides actionable context for when this check is warranted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already state that this is read-only, idempotent, and non-destructive. The description adds meaningful behavioral context beyond those annotations: the output is a nightly snapshot, the data is grouped into specific lanes, coverage_basis distinguishes 'measured_zero' from 'not_measured', and c2_intel's 0% is explained as a true omission rather than a measurement artifact. This is exactly the kind of interpretive detail an agent needs to avoid misreading the data.
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?
The description is information-dense but every sentence earns its place: the row set, the non-lane caveats, the hit_rate caveat, the measured-zero explanation, and the freshness warning. It is front-loaded with the main purpose and then adds necessary exclusions and interpretation guidance. There is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, output-driven tool, this description covers all the essential context an agent needs: what the overview reports, how the rows/lines are defined, what fields like hit_rate and coverage_basis actually mean, and how to check freshness. The output schema is already available, so the description does not need to re-list the return shape. No important usage aspect seems missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no schema surface for the description to clarify. The description instead clarifies the semantics of the returned object, which is more than enough for an empty input schema. Since there are no parameters to describe, the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a very specific resource: 'Health and coverage of the enrichment LANES feeding the platform,' and immediately enumerates the exact rows/groups the tool returns. It also clarifies what is not included (EPSS and KEV are fields inside cve_details, not separate lanes), which removes ambiguity an agent would otherwise have when deciding whether this matches the user's request.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives strong context on how to interpret the result: values like coverage_basis have special meanings, hit_rate definitions vary by lane, and c2_intel's 0% is a true measured zero. It also cautions the agent to read as_status/stale_hours because this is a nightly snapshot. It does not explicitly name alternative sibling tools or a when-not-to-use condition, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare a safe read, but the description adds material behavior: the data source over-merges subgroups, alias entries are mappings not identity assertions, and relation/other_entities/corpus_uses_separately carry distinguishing semantic meaning. This is valuable context the annotation schema cannot convey.
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?
Every sentence earns its place: reverse relationship, usage guidance, data-quality warning, key output semantics, and accepted inputs. The structure front-loads the differentiating relationship and remains dense without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description need not restate return formats; instead it provides the conceptual semantics that make the results interpretable, plus the over-merge warning that affects correct reasoning. It is complete for an agent deciding whether and how to invoke this tool.
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 description coverage is 100%, so the baseline is 3 and the schema already documents name, type, and uuid well. The description matches the input fields but adds no meaningful parameter details beyond what the schema states; its extra content is about output semantics and caveats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence gives a specific verb and resource ('Every alias the reference set maps to ONE entity') and explicitly contrasts it with resolve_entity, which 'only walks a single alias forward.' This immediately distinguishes it from a close sibling and makes the reverse-relationship clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It names the exact use case ('Use it to check alias collision') and the alternative tool (resolve_entity), while explaining how this tool differs and the common failure it addresses. The MISP over-merging caveat also tells the agent when the data may be misleading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), it explains important behavioral details: results derive from the same indicator universe as the correlation graph, pivots carry value_threat_count thresholds, and confidence is rarity-based. It also clarifies a real semantic trap — that zero pivots can mean either a genuine negative or merely no pivotable indicators, and that labels are excluded by design so the returned evidence is not overstated.
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?
The description front-loads the primary purpose and then earns every subsequent sentence with real-value guidance: value_threat_count interpretation, coverage semantics as denominator, and when to route to get_similar_threats. It is dense but appropriately so for a tool whose output requires careful interpretation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is one required parameter, an output schema is present, and independent annotations already cover read-only/idempotent safety. The description supplies the missing interpretive context — how to read pivot_count/value_threat_count and why zero results can still be meaningful — making this complete for the agent to invoke and consume the tool responsibly.
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?
The schema already gives 100% coverage of the only parameter, threat_id, with a format example. The description adds no additional parameter detail beyond framing it as the 'given threat,' so the baseline of 3 applies; the schema is doing the heavy lifting here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: "surface cross-threat infrastructure links" for a given threat, listing the exact artifacts involved (IPs, domains, hashes, DNS overlaps). It differentiates itself from get_similar_threats by explicitly disclaiming TTP/actor-based similarity, leaving no ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says when to use it (to find shared infrastructure across threats) and when not to ('labels are deliberately not pivotable') with a direct pointer to the alternative: 'Use get_similar_threats for TTP/actor-based similarity instead.' It also tells the caller how to interpret edge cases like pivot_count=0 with scorable_iocs > 0 vs = 0.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish readOnlyHint=true and idempotentHint=true, so the description does not need to repeat safety behavior. It adds genuinely useful behavioral context: the tool works from family names, resolves them to canonical entities, and returns prevalence plus related threats/actors/techniques. It does not describe error behavior for unknown names, but the output schema and read-only annotations lower the burden here.
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?
Every sentence earns its place: the first states purpose and input, the second lists return contents, and the third provides routing to the natural sibling. It is concise, front-loaded, and has no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one required parameter, an output schema, and annotations covering side effects, the description includes everything operationally important: what type of input is accepted, what results are produced, the appropriate alternative, and the recommended disambiguation step. No critical invocation detail is missing for an agent to call this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the only parameter 'name' at 100% coverage, so the baseline is 3. The description adds further meaning by clarifying that the value is a family, not a tool or actor, and by telling the agent to resolve non-canonical names beforehand. This gives the parameter real semantic depth beyond the schema example strings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb and resource: 'Pivot on a malware FAMILY by name'. It lists concrete return contents (canonical family, type, prevalence, threats, actors, ATT&CK techniques) and distinguishes itself from get_tool_intelligence, so an agent can immediately separate it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when this tool is correct ('Pivot on a malware FAMILY') and when to choose the alternative: 'For an offensive TOOL (Cobalt Strike, Mimikatz) use get_tool_intelligence instead'. It also handles the ambiguous-name case by instructing 'Call resolve_entity first if unsure of the canonical name.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, but the description meaningfully exceeds that: it warns about the potentially huge threat list on a heavily-used technique, recommends include_threats=false for a few KB response, explains paging via limit/offset, and clarifies that threat_count always reports the true total. This alerts the agent to payload-size and performance behavior not visible in 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?
Two sentences with no filler. The first sentence states the core operation and full return-listing; the second covers paging/performance trade-offs. Every clause earns its place, and the description is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and annotations cover the safety profile, the description itself contains everything needed for a correct invocation: required ID format, what fields come back, the optional payload-size switch, pagination controls, and the meaning of threat_count. It leaves no practical gap for an agent selecting or calling this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all four parameters at 100% with helpful descriptions (defaults, max, 'underthehood'). The description goes beyond by explaining how include_threats=false compared to to page 'the low definition alone (a few KB)' rather than relying on names. That added rationale and the threat_count guarantee lifts it above the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Get details for a specific MITRE ATT&CK technique by ID (e.g. T1059 or T1059.001)' which is a precise verb + resource + scope. It enumerates the exact fields returned, which clearly differentiates this lookup tool from the many MITRE-adjacent siblings (coverage, transitions, rules, attack flow).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly identifies the primary use case and gives strong in-tool guidance: how to request just the definition via include_threats=false, how to page the threat list, and what behavior to expect from threat_count. It does not explicitly contrast against alternatives or name when-not-to-use, but no obvious sibling overlaps directly, so explicit exclusions are less critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description additionally reveals the minSupport cutoff of 0.02, the lift-descending sort order, the presence of summary.total_rules and has_more for pagination, and that names are included to reduce follow-up lookups. This goes well beyond the annotations with material behavioral detail.
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?
Every sentence carries distinct and necessary information: core output, adjacent distinction, ordering/pagination, and interpretation caveat. It is front-loaded with the main purpose and remains compact without redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one optional parameter, no destructive behavior, rich annotations, and an output schema. The description still adds crucial output semantics around total rules, has_more, sorting, and the minSupport miners, so an agent can select it and interpret its result without uncovered surprises.
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?
There is only one parameter, limit, and the schema already covers it with default and max values at 100% coverage. The description does not need to add parameter semantics, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Describes exactly what the tool provides: MITRE ATT&CK technique pairs mined from the corpus with support, confidence, and lift. It clearly describes the co-occurrence focus and explicitly distinguishes it from the sequence-focused predict_mitre_transitions tool, making the resource and intent unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the only sensible sibling alternative, predict_mitre_transitions, and explains the selection criterion: sequence versus co-occurrence. It also warns about the minSupport threshold, so an agent knows rare-pair results will be absent by design rather than anomalous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description discloses substantive data-behavior nuances: generation stopped, only archived rows remain, playbooks are synthetic and won't trigger detections, and an empty result distinguishes 'this threat never had any' from 'none for that platform'. That is enrichment annotations do not capture.
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?
Front-loaded with the most important arc (DEPRECATED) and elevides every detail: status, data volume, quality caveat, performance trigger, response semantics, and replacement., the one-sentence structure is effectively a compact CLI-style summary with no inerous commentary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only getter with a schema and output schema already present, the description is complete—youth provide and exact dark context, a response caveat (§empty reason), size/vacceptility constraint, and a migration path. There is nothing an agent would need to know to safely invoke or interpret this tool that is missing.
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?
The schema already covers 100% of parameter descriptions. The description adds justification for using limit/platform ('30 KB+ of command text'), but does not explain new parameter semantics—it reinforces rather than defines. Baseline of 3 applies because the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact resource ('adversary-emulation playbooks attached to a threat') and clearly identifies its scope and relationship. It also differentiates from the replacement tool get_attack_flow, so an agent can tell this tool apart from relevant siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly marks the tool as deprecated, names the preferred alternative (get_attack_flow), and advises how to narrow results when they could be huge ('narrow with platform (see available_platforms) and limit'). This-level of when-to-use and when-not-to-use guidance is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description surfaces a critical behavioral nuance: prevalence.actor_count is the true distinct-actor total, while the actors[] array is clipped to the top 20 and must not be mistaken for the full population. This is genuinely useful behavioral guidance.
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?
The description is compact and well-structured: an actionable purpose sentence, an output summary sentence, and a focused data-read confusion caveat. Every sentence earns its place and no structured schema details are merely repeated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter lookup with a full input schema and an output schema present, the description provides all needed context: what kinds of names are valid, what is returned, and how to interpret prevalence counts. No critical clarity gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already defines the single 'name' parameter, and the description expands it by narrowing the valid domain to offensive tools/utilities/RMMs/LOLBins and providing concrete examples. This adds value beyond the schema's generic 'Tool name' description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific, actionable operation: pivot by tool name and return canonical tool data, class, prevalence, threats, actors, and ATT&CK techniques. It gives examples that distinguish it from sibling intelligence tools like get_malware_intelligence or get_actor_intelligence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly defines when to use this tool: when you need intelligence about an offensive tool, utility, RMM, or LOLBin by name. It does not explicitly contrast with sibling tools, but its domain and input expectations are concrete enough to route an agent correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well established. The description adds value by confirming the operation is comprehensive ('every threat category') and returning 'threat count' per category. No contradictions with annotations. Lacks detail on pagination or output size, but for a zero-parameter list tool this is arguably unnecessary.
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?
Two sentences, zero waste. The first sentence states the action and output; the second gives the practical use case. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, an output schema exists, and rich annotations cover safety/idempotency, the description is complete. It explains what is returned (categories + counts), scope (whole corpus), and the primary use case. No further detail is needed for this simple listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are 0 parameters and schema coverage is 100% (empty properties object fully documented). The description adds no parameter info, which is appropriate since there are none to document. Baseline 4 for a tool with no parameters is justified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource ('list threat categories'), clear scope ('across the whole corpus'), and states what data is returned (threat count per category). Distinct from siblings like search_threats and get_threat, which operate on individual threats/categories. No ambiguity in purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the use case: 'Use to discover valid category filters for search_threats.' This gives the agent clear guidance on when to invoke this tool and how the output feeds into downstream workflow. While it doesn't explicitly enumerate exclusions, the stated purpose effectively differentiates it from the many search/intelligence siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (read-only, idempotent, non-destructive), the description discloses important behavioral details: depth expansion is resource-bounded, edge_type pruning changes which nodes are reachable, and min_fidelity uses a scale that '0.5 filters nothing.' It also warns about comparing rounded fidelity and points to raw values, all of which is practical operational behavior.
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?
The description is compact and front-loaded with the main purpose, followed by usage guidance and a nuanced numeric validation note. Every sentence earns its place: purpose, budget/expansion rationale, sibling differentiation, and edge-fidelity warning,
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is thorough for a graph traversal tool: it covers output shape, expansion pattern, borrowing limits, sibling selection, scale calibration, and edge-specific raw data. With an output schema present and annotations covering safety, it doesn't need to enumerate every return field. It might not describe all edge response capabilities, but nothing essential for invocation is missing enough for a 3.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (86%), so the baseline is decent. The description adds valuable semantics beyond the schema, especially for min_fidelity ('Scale is 0-100, NOT 0-1—typical NPMI edges sit between 5 and 30') and for edge_type pruning semantics. It doesn't add elaborate semantics for every parameter, but the ones it covers are materially helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says specifically what the tool does: 'The N-hop neighbourhood around any graph node — nodes, edges, and each edge's fidelity — for incremental exploration of the correlation graph.' This clearly identifies the verb, resource, and output, and it differentiates from get_entity_profile by emphasizing 'actual edge topology.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description is explicit about when to use this tool: 'Start at depth 1 and expand' is directly tied to 'a whole-corpus graph exceeds every response budget.' It then names an alternative ('prefer get_entity_profile, which is cheaper') and the condition under which this one should be selected ('when you need the actual edge topology').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, the description discloses the data source (tweetfeed.live, CC0), a concentrated submission pattern (~73% from a single reporter), and explicitly warns to treat results as corroborating evidence, never as authoritative attribution. This is valuable context that annotations do not provide.
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?
The description is three sentences, each earning its place: purpose, per-parameter behavior, and a reliability caveat. It is front-loaded with the core function and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, output schema provided), the description covers all necessary aspects: both usage modes, data provenance, and a critical reliability caveat. The output schema handles return value structure, so no gap exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds return-field details beyond the schema's brief parameter descriptions: for threat_id it lists matched community tags, corroborated indicator count, and the BEFORE report flag; for ioc_value it lists sightings, reporters, tags, and linked threats. This significantly enriches the meaning of each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides 'Community corroboration for a threat or an indicator from the TL_OSINT_Scan layer', with specific outputs for threat_id and ioc_value. This distinguishes it from sibling tools like get_osint_trends and get_ioc_intelligence by focusing on corroboration from a specific data source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool (when community corroboration is needed) and describes behavior for each parameter. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, and the description is consistent. Beyond annotations it adds valuable context: the deliberate absence of a family filter (a non-obvious behavioral trait), the dataset provenance/license (CC0), the 'matched against our corpus' constraint, and the concentration statistic (~73% from a single reporter) that warns the agent not to treat results as authoritative. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each carrying weight: scope+provenance, filter capability, no-family-filter explanation + sourcing caveat. The prose is efficient, but it's dense and could arguably be split into a cleaner scannable form. Still, no filler and front-loaded with the most important information (what the data is and its limitations).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-param search tool with a 100%-described schema, an output schema, and readSafe/idempotent annotations, the description is remarkably complete. It covers data provenance, source quirk (sparse family field), the correct filter strategy (tag vs family), and data-quality caveats (single-reporter concentration, corroborating-not-authoritative). Nothing critical is left unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all 8 parameters described. The description adds value via examples for the less obvious ones: 'tag' gets 'phishing, asyncrat, c2' examples plus case-insensitive/normalized behavior, 'asn' gets 'AS14061,' and 'country' gets 'RU.' The default-25/max-100 for limit also appears in the description. Minor gap: the 'q' substring and 'min_threats' semantics are adequately covered by schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource+scope: 'Search the canonical community-indicator set (TL_OSINT_Scan / tweetfeed.live, CC0)' with a specific qualification that results were 'matched against our corpus.' This distinguishes from siblings like search_iocs (presumably the authoritative/threat-linked set) by emphasizing community-sourced + corpus-matched nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit and rich: explains there is deliberately NO family filter and why (upstream family field populated on <1% of rows), directing the agent to 'Use tag instead (community tags carry the family signal).' Also gives caveat that data is corroborating, not authoritative, which sets expectations on how to weigh results versus search_iocs or search_threats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered; the description adds valuable behavior beyond that: lean vs full row semantics, the reason a full dossier caps at 3 (~68 KB), and the guarantee that overflow is named in `deferred_ids` and 'never silently dropped.' The `missing` behavior for unresolvable IDs is also disclosed.
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?
Three sentences, each earning its place: core capability first, then default-payload detail, then full mode, then cross-reference. No filler or repeated schema text; the most important constraint (20 IDs per call) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers everything an agent needs to invoke correctly and interpret the result: the batch cap, both detail modes, overflow handling, missing IDs, and a pointer to the single-ID fallback. An output schema is present for return fields, so the description's grounding from `count`/`missing`/`deferred_ids` is ample.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; both parameters are already documented, including the detail enum and max 20 on threat_ids. The description adds marginal value by explaining response-related semantics: what `count` counts, what `missing` contains, and why detail='summary' is what makes 20 fit in one response.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb, resource, and constraint: 'Fetch up to 20 threats by ID in one call.' This cleanly separates it from single-ID get_threat, search-based search_threats, and get_recent_threats without needing to read any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the alternative tool with its use case: 'Drill into any row with get_threat(id).' It also gives conditions for choosing the detail mode ('detail="summary" default, all 20 fit' vs 'detail="full"... max 3 ids per call'), so an agent knows when and how to call rather than guessing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint, idempotentHint, and destructiveHint annotations, the description discloses that the table is sparse, that empty results mean 'unrecorded' rather than 'disproved', and that live coverage numbers are included in the response. This semantic nuance is essential for avoiding false negative conclusions and is not available from annotations alone.
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?
The description is front-loaded with the core purpose and each sentence carries distinct value: scope, novelty semantics, exclusion semantics, sparsity warning, and parameter behavior. It is longer than an average description but every sentence earns its place, and the CRITICAL flag correctly draws attention to the most important interpretive rule.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully contextualizes this tool: it tells the agent why it exists, what it cannot prove, what emptiness means, how it differs from an alternative, and what live coverage info will accompany the response. Combined with an output schema, nothing needed for correct invocation or interpretation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented, but the description adds operational meaning: actor applies to either side, 'Omit to list the whole baseline', and rel_type results can be discovered through the response's coverage.rel_types field. This goes beyond the schema's structural descriptions without being redundant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (already-documented actor-to-actor links) with a specific verb (get) and explicitly lists relationship types like subgroup/overlaps/similar/linked-to. It also distinguishes itself from get_actor's relationship list by noting it matches both actor slots, so an agent can tell this tool apart from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to call it ('Call this before claiming any actor-to-actor relationship is new') and what not to infer from it ('never to rule a relationship out of EXISTENCE'). It even names the alternative behavior in get_actor that differs, giving the agent clear routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent, so the safety profile is covered. The description adds critical behavior beyond that: case-insensitive matching, CVE union semantics from two sources, authoritative CVE-to-threat mapping, and the caveat that edge_scores is a sampled projection and never the denominator for counts.
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?
Three sentences, each dense with necessary information and no filler. The core purpose is front-loaded, and the behavioral caveats are organized logically.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a moderately complex but bounded tool: it explains inputs, depth semantics, matching behavior, edge probabilities, CVE-specific union logic, and tool alternatives. An output schema exists, so detailed return values do not need to be restated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. However, the description adds meaningful elaboration: it defines depth traversal rings concretely (1=threats, 2=+techniques, 3=+actors & sibling IOCs) and clarifies the meaning of coverage and edge_scores in the output, going beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Map the blast radius'), a precise resource ('one indicator'), and enumerates the output dimensions (threats, MITRE techniques, actors, sibling IOCs). It also differentiates itself from the closest sibling by explicitly saying get_ioc_intelligence is for a richer multi-source dossier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to scope impact of a single IOC' and names the alternative for a richer dossier on one indicator (get_ioc_intelligence). This gives the agent clear selection criteria and an exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint true, and the description adds meaningful behavioral context beyond them: the data is stale, a stale_days field and warning are returned, and several planned items have already shipped. This transparency is critical to accurate agent behavior.
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?
The description is compact and front-loaded, with the core resource and fields stated first and the important staleness warning placed immediately after. Every sentence adds essential information, with no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read-only tool with an output schema and rich annotations, this description fully covers what an agent need aware of. It explains the data source, staleness, response warning, and which sibling tools to use for authoritative status checks.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the schema provides no parameter semantics to clarify. The description adds value by listing the output fields such as completed, in_progress, ideas, counts, generated_at, as_of, and stale_days, which supports expectation-setting for the response.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the exact resource and verb: retrieving the Threadlinqs Intelligence platform roadmap. It enumerates the statuses and fields returned, so an agent knows precisely what information the tool provides and can distinguish it from other catalog/status tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly warns that the roadmap is hand-maintained and stale, and instructs the agent to confirm current build status with get_started, get_platform_stats, or get_engine_status instead. This gives clear when-not-to-use guidance and names specific alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds materially beyond that: the response echoes `_sections` to tell the caller what was returned/omitted, detection RULE BODIES are omitted by default (~40% payload), `description` is trimmed to 1500 chars with `description_chars` disclosing the true length, and the escape hatch of sections="all" + max_description=-1 for the full record. That is rich, non-redundant 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A dense but well-structured description: first sentence establishes the core purpose, then the behavioral flags (retrievable in parts, chunked payload, omitted rule bodies), then the escape hatch, then the routing to the enrichment sibling. Every sentence earns its place and the most decision-relevant facts are front-loaded. Not a word of filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with an output schema, return values need no explanation, and the description covers the remaining behavioral gotchas: default sections, payload size implications, how to read the response via _sections, and how to get the full dossier. An agent has everything needed to invoke this tool correctly and to know precisely how to adjust behavior for different use cases. Nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3 — the schema already documents id, sections, and max_description including literal defaults. The description adds real value on top by explaining WHY the trim exists (payload size), that max_description=-1 returns the whole record, and the detections vs detections_meta distinction in context. It's genuine added meaning, but the schema carries most of the parameter documentation burden, so 4 rather than 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Get the detail') targeting a single threat by ID, and enumerates the content: overview, attribution, MITRE techniques, IOCs, detection roster, timeline, targets, tags. It explicitly differentiates itself from siblings by pointing to get_threat_enrichment for malware/tool/sector/OS/campaign data and mentioning export_detection/get_detection_detail as the tools that handle rule bodies, so an agent can distinguish it from search_threats, get_recent_threats, and related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit routing guidance: detection rule bodies are omitted by default because they are ~40% of a heavy dossier and have dedicated tools (export_detection / get_detection_detail). It also states exactly when to use get_threat_enrichment ('For malware families, tools, sectors/regions, OS and campaigns, call...'). This is explicit when-to/not-to guidance with named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnly, idempotent, non-destructive behavior. The description adds value beyond these annotations by explaining the bounded nature of the returned threat projection, the effect of include='summary', and that it bundles multiple data sources into one response. This is transparent about behavior without contradicting 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: the first defines the bundle, the second explains its round-trip advantage, and the third clarifies the bounded nature and points to an alternative. It is front-loaded with the core purpose and avoids redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only bundled tool with a full output schema and complete parameter schemas, this description covers all necessary agent guidance: what the bundle includes, how to narrow the response, when to use alternatives, and how the bundled 'threat' compares to get_threat's default projection. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds useful content beyond the schema: include='summary' yields just the threat, simulation_limit embeds full command text, and the warning to raise the limit only when needing more than the newest few playbooks. These clarifications make the parameter semantics easier to apply correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'One-shot dossier for a threat: threat detail plus its simulations and pipeline transcripts.' It clearly distinguishes itself from the component calls it bundles (get_threat + get_threat_simulations + get_threat_transcripts), and clarifies that include='summary' returns just the threat.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when this tool is preferable ('Fewer round-trips than get_threat + get_threat_simulations + get_threat_transcripts separately') and names the alternative for an uncompressed record ('call get_threat(id, sections="all") for the unabridged record'). This gives an agent a concrete decision rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and idempotentHint=true, and the description does not contradict them. It adds substantial behavioral detail beyond those annotations, including that each member carries `text_supported`, that the underlying table lacks a provenance column, and that some rows attach threats to campaigns without textual evidence — warning against treating co-membership as correlation evidence.
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?
Every sentence earns its place: the first gives purpose and scope, the second distinguishes it from alternatives, the third gives a filtering example, and the last discloses important data-quality caveats. There is no filler or repetition, and the key scoping information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read-only list tool, this description is complete. It explains what the returned members contain, flags data-quality risks, gives a filtering example, and places the tool among it will provide a missing capability that its siblings don't. The annotations and output schema cover the remaining expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description adds extra meaning for min_actors by giving a concrete use case (finding campaigns with two or more distinct actors) and reinforces the significance of fields like `unsupported` and `cross_nation`. It does not add anything about limit, but the schema covers that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: a roster of NAMED campaigns/operations referenced by the corpus, including their actors, nations, date range, and member threats. It also differentiates the tool from get_campaign_intelligence and get_graph_campaigns, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when this tool is the right choice: it answers the campaign-lineage question that get_campaign_intelligence cannot answer because that tool requires a known name, and get_graph_campaigns cannot because it only returns engine similarity clusters. It also gives a concrete filter example with min_actors, which further clarifies intended usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only/idempotent annotations, the description explains how each row is generated: attack_flow rows come from analyst-authored DAGs, mitre_canonical is inferred from tactic rank, and blended has both. It also discloses the limitation that ~24% of real transitions are inexpressible by the canonical basis, which is valuable 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence adds distinct information: purpose, evidence-basis semantics, preference recommendation, and direction intent. The structure is front-loaded with the core prediction behavior followed by necessary nuance, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich parameter schema, enums, output schema, and annotations, the description is sufficiently complete. It covers what the tool returns, how the data is derived, how to pick basis and direction, and a key limitation. Nothing necessary for successful invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all four parameters, so the baseline is 3. The description adds operational meaning for basis (attack_flow vs mitre_canonical vs blended) and direction (forward vs reverse) beyond the schema descriptions. It does not add much for top_n or technique_id, but the schema covers those sufficiently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence names the specific action (predict), resource (MITRE ATT&CK techniques), and conditionality (follow/precede a given technique) with probabilities and examples. This clearly distinguishes the tool from sibling functions focused on coverage, technique details, or raw attack flows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage direction: prefer attack_flow evidence, use forward to anticipate the next step, and reverse to infer what came before. It also explains which basis to prefer and why, giving an agent actionable selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses data-repair behavior, label_hygiene reporting, the meaning of role: co-mention and also_grounded_as, and non-pagination with a total count. This meaningfully helps an agent interpret returned rows correctly.
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?
The description is more verbose than average, but every sentence earns its place: purpose, filtering, sibling routing, pagination, and two critical data-quality warnings. It is front-loaded with the main verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a listing tool, it covers the full behavioral envelope: default and filtered behavior, single-actor alternative, output size expectations, and interpretation of per-row flags. The existing output schema carries the mechanical return shape, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter has a one-line description, so the baseline is 3. The description adds semantic clarity by showing that filters narrow the full roster and provides a concrete example of how filtering behaves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List attributed threat actors with aggregate stats,' and explicitly contrasts itself with get_actor for single-actor profiles. It immediately distinguishes itself from sibling actor tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly explains both modes: full roster in one call versus narrowing via optional filters, provides a concrete example with tool='Cobalt Strike', and directs users to get_actor for single-actor detail. It also states the pagination behavior, leaving no guesswork.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint, openWorldHint, and destructiveHint, but the description adds substantial behavioral context: deterministic semantics, row-per-observation behavior, stats vs non-stats output, count_distinct to avoid double-counting, operator list, and hyphen-quoting rule. These details are not visible in annotations or schema alone.
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?
Although dense, every sentence adds distinct operational guidance: when to use, how to aggregate, how to avoid double counting, supported operators, and required validation. There is no wasteful filler, and the most important usage signal is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers the full calling context: when to use, what the query does, how aggregation works, edge cases like hyphenated values, and the need to consult hunt_schema. The output is covered by the output schema and has_more reference, so the agent has everything needed to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes the parameters, but the description adds practical semantics for the query parameter: example TLQL, supported operators, quoting rules, stats syntax, and the count_distinct caveat. The limit parameter is also explained in the schema, while the description deepens the understanding of query behavior beyond the schema examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Run a deterministic SIEM-style query') and a specific resource ('pre-joined observation index'), and clarifies the kind of questions it answers: aggregates or queries crossing observation types. It explicitly contrasts with search_threats, making sibling differentiation clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use this tool INSTEAD of chaining many search_threats calls for aggregate questions or cross-observation-type questions. It also instructs calling hunt_schema first when fields are unknown, going beyond a simple 'when to use' statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![intelthreadlinqs-mcp MCP server](https://glama.ai/mcp/servers/threadlinqs-cmd/intelthreadlinqs-mcp/badges/card.svg)](https://glama.ai/mcp/servers/threadlinqs-cmd/intelthreadlinqs-mcp)

Score Badge

Copy to your README.md:

[![intelthreadlinqs-mcp MCP server](https://glama.ai/mcp/servers/threadlinqs-cmd/intelthreadlinqs-mcp/badges/score.svg)](https://glama.ai/mcp/servers/threadlinqs-cmd/intelthreadlinqs-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/threadlinqs-cmd/intelthreadlinqs-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server