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

The description adds that it 'Requires Novyx Cloud' and that it gives access to memories, beyond the annotations (destructiveHint: false). It adequately discloses behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short, well-structured with Args and Returns sections, and front-loads the core purpose. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter tool, the description covers the action, input, requirement, and return value. Output schema is present (per context signals), so return description is adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema only defines 'token' as a string without description. The description clarifies: 'The sharing token from the invitation.' This adds meaningful context, compensating for the 0% schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'accept' and the resource 'shared context invitation', distinguishing it from sibling tools like share_space and revoke_shared_context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit context: 'When another user shares a context space with you, use this to accept and gain access to their memories.' Does not mention when not to use or alternatives, but the context is sufficient.

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

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

Annotations already indicate readOnlyHint=true, so the agent knows it's safe. The description adds that it shows various statuses (submitted, pending, etc.), which provides some behavioral insight but nothing about authentication, rate limits, or how 'recent' is defined. It adds modest 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise, with a clear front-loaded purpose, and structured Args/Returns sections. Every sentence adds value with no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains the simple parameter and return type. However, it omits details like how 'recent' is defined (timeframe?), and no output schema is provided to clarify the return format. For a read-only list tool, it is adequate but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Since schema description coverage is 0%, the description fully compensates by explaining the 'limit' parameter: 'Maximum actions to return (default 20).' This adds clear meaning beyond the schema's mere existence.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'List' and the resource 'recent Control actions with their status', making it specific. However, it does not explicitly differentiate from sibling tools like 'action_status' or 'audit', though the purpose is sufficiently clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives (e.g., action_status for a single action, audit for overall history). The description does not exclude any contexts or mention when not to use it.

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

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

Annotations already declare readOnlyHint=true; the description adds specific return details (policy decision, approval status, execution result, evidence) beyond annotations, providing useful behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief, front-loaded with the core purpose, and uses clear argument/return sections with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter retrieval tool with an output schema, the description covers the main purpose and return details. Minor gap: does not specify where to obtain action_id or that it only applies to Control actions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description compensates by explaining action_id ('The action ID (e.g. act_xxx)'), though it lacks format constraints or source guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves the status of a specific Control action, distinguishing it from siblings like action_history (list actions) and action_submit (create actions).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies using it when you need the status of a specific action, but does not explicitly state when not to use it or mention alternatives.

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

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

Annotations declare destructiveHint false; description adds policy evaluation and return fields. Does not disclose error handling, side effects, or authentication needs. Adequate but could be richer.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise, well-structured with purpose, explanation, Args, and Returns sections. Front-loaded with main point. No redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, input, approval flow, and return fields. Output schema exists so return details are not required. Lacks error scenarios or prerequisites, but complete enough for typical use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage 0% but description's Args section explains each parameter thoroughly, including example values for connector and operation, and format for payload. Adds significant meaning beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states verb 'submit' and resource 'action' with explicit context of governed execution and policy evaluation. Distinguishes from siblings like approve_action or check_policy by emphasizing the submission process.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides context on policy evaluation and approval routing but does not explicitly state when to use alternatives or when not to use the tool. Implicit guidance, but lacks clear exclusions.

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

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

Annotations provide destructiveHint: false. The description adds value by disclosing that entities are auto-created if they don't exist—a key behavioral trait not covered by annotations. It does not mention failure cases or permissions, but the auto-creation detail is useful.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief and front-loaded: the main purpose is stated in the first sentence, followed by a concise note on auto-creation and a clearly structured parameter list. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (3 string params, no enums, output schema exists), the description covers essential aspects: what it does, parameter meanings, and return type. It does not elaborate on constraints (e.g., allowed predicates) but is sufficient for a basic create operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 3 required string parameters with no descriptions (coverage 0%). Description compensates by explaining each parameter: 'subject: The subject entity name.', 'predicate: The relationship predicate.', 'object_name: The object entity name.' This adds meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states 'Add a knowledge graph triple (subject -> predicate -> object).' It uses a specific verb 'Add' and a clear resource 'knowledge graph triple.' Among siblings like 'delete_triple' and 'query_triples', this tool is uniquely identified as creation, distinguishing it well.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when adding a triple, but does not provide explicit guidance on when not to use it or alternative tools. It lacks context like prerequisites (e.g., requiring a space) or cases where existing triples might conflict.

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

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

Annotations only provide destructiveHint: false, leaving the description to cover behavioral traits. The description states it triggers execution and returns a JSON string, but does not disclose potential side effects, permissions needed, or failure modes. Adequate but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with 'Args' and 'Returns' sections, making it scannable. It uses clear, concise language without unnecessary repetition, though slightly longer than minimal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (3 parameters, output schema exists), the description covers purpose, parameters, return format, and target connectors. It does not discuss error scenarios or prerequisites, but the presence of an output schema reduces the need for detailed return descriptions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 0% parameter descriptions, so the description compensates by explaining each parameter with examples (e.g., 'approval_id: The approval ID (e.g. apr_act_xxx)'). Adds meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action ('Approve a pending agent action'), the context ('Novyx Control'), and the effect ('triggers its execution against the target connector'), with specific connectors listed. This distinguishes it from sibling tools like action_submit or action_history.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is used for approving pending actions, but provides no explicit guidance on when to use it versus alternatives (e.g., action_submit for new actions), nor does it state when not to use it. Lacks explicit exclusions or comparisons.

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

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

Annotations already provide readOnlyHint=true, and the description adds minimal extra behavioral context (returns JSON string). 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise, front-loaded with purpose, and each sentence (including the parameter list and return line) adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple retrieval tool with two optional params, readOnly annotation, and an output schema, the description covers purpose, parameters, and return format completely.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description bears full burden. It explicitly describes both parameters with default values and example values, adding meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get the audit trail of memory operations' with a specific verb and resource. It distinguishes from siblings like audit_export and audit_verify by specifying the target.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. Siblings include related tools like audit_export and audit_verify, but the description lacks context for selection.

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

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

Annotations already indicate readOnlyHint=true, so the description adds value by noting the requirement and that it downloads the full audit log. However, it does not disclose potential limitations (e.g., file size, synchronous behavior, rate limits).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is highly concise: two sentences for purpose, one for requirements, and a clear Args/Returns section. No superfluous information, front-loaded with essential purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple export tool with one parameter, the description covers purpose, requirement, parameter semantics, and return format. It is mostly complete, though it could mention error conditions (e.g., invalid format or insufficient permissions) and why to choose this over 'audit'.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds the allowed values ('json', 'csv', 'jsonl') and default for the 'format' parameter, which are absent from the schema (string type without enum). This fully compensates for the schema's lack of description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool exports the full audit log with a specific verb (Export/Downloads) and resource (audit log). It distinguishes itself from the sibling 'audit' tool by focusing on downloading the complete trail rather than viewing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

While it mentions a requirement (Pro tier/Novyx Cloud), it does not explicitly guide when to use this tool over siblings like 'audit' or 'audit_verify'. The usage context is implied but not contrasted with alternatives.

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

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

The description adds value beyond the readOnlyHint annotation by detailing the verification mechanism (cryptographic hash chain vs entry consistency) and specifying the return format (JSON string). It does not contradict annotations and provides moderate behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, with two short paragraphs. The first sentence clearly states the purpose, and the subsequent lines provide necessary detail without redundancy. Every sentence contributes meaningfully.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters and a simple output, the description is mostly complete. It explains what the tool does and how it works, though it could mention potential performance implications or clarify the output schema further. The presence of an output schema mitigates this need.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has no parameters, and schema coverage is 100%. Per guidelines, baseline is 3. The description adds no parameter-specific information, but this is acceptable given the parameterless nature of the tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Verify the integrity of the audit trail.' It explains the verification method (cryptographic hash chain or entry consistency) and differentiates itself from sibling tools like 'audit' and 'audit_export' through its focus on integrity checking.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide guidance on when to use this tool versus alternatives. It lacks explicit context such as when verification is appropriate or prerequisites. No exclusion criteria or alternative tool mentions are given.

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

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

Annotations already indicate destructiveHint=true. Description adds no additional behavioral context such as irreversibility, permissions, or side effects. It does not contradict annotations but fails to elaborate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise (three words). While it contains no filler, it sacrifices necessary detail. It is appropriately sized for a simple tool but could include a brief note on effect.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the destructive annotation and single required parameter, the description is insufficient. It does not explain what 'cancel' entails, any prerequisites, or what happens upon cancellation. The presence of an output schema is not leveraged.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, and the description provides no information about the sole parameter mission_id. No format, example, or semantics are given, leaving the agent to guess.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb-resource pair ('Cancel a mission'). However, it does not distinguish from sibling tools like delete_mission or pause_mission, which could overlap in functionality. The purpose is clear but lacks differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives (e.g., delete_mission, pause_mission). The description is minimal and does not provide context or exclusions.

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

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

Annotations declare readOnlyHint=true, and the description aligns by stating 'check'. The description additionally reveals the return format (JSON string with policy profile and approval status), which adds 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact, uses clear headings (Args, Returns), and every sentence adds value. No wasted words, well-organized for quick parsing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (read-only, two optional params, known output schema), the description covers all needed context: what it does, parameters, and return value. Nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by explaining both parameters: connector (optional, with examples) and environment (with default). This provides essential meaning beyond the schema's titles and defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool checks the current Control policy profile and enumerates specific details it shows (connector approval, risk tier rules, auto-approve settings). This distinguishes it from sibling tools like create_policy, delete_policy, and list_policies.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for inspecting policy state but does not explicitly state when to use versus alternatives. It provides optional arguments, giving context for filtering, but lacks exclusions or alternative recommendations.

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

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

Annotations provide readOnlyHint=true. The description adds specific behavioral details: returns recent memories, stats, and audit activity – extending beyond the annotation. No contradictions detected.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is concise: two sentences plus a return note. Front-loaded with the core purpose. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no parameters and a readOnly annotation, the description is mostly complete. It explains the return value is a JSON string with snapshot details. Missing formal output schema, but context signals indicate one exists externally.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so schema coverage is effectively 100%. The description adds no parameter info (none needed). Baseline 4 for 0 parameters is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it gets a 'snapshot of your current memory context' with recent memories, stats, and audit activity. It distinguishes from siblings like 'recall' or 'list_memories' by emphasizing a quick overview, but does not 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies it's for a quick overview of current memory context, but lacks explicit guidance on when to use this vs alternatives like 'memory_stats' or 'list_memories'. No when-not-to-use or prerequisites mentioned.

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

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

Annotations already indicate readOnlyHint=true, and the description's 'Check if...' is consistent. The description adds detail about the analysis approach (timing, pattern similarity) but no additional behavioral traits like concurrency limits or data handling. With annotations covering safety, a score of 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with sections (purpose, analysis, requirements, args, returns) and is reasonably concise. The first sentence clearly states the purpose. A slight redundancy exists (e.g., the analysis line repeats the purpose), but overall it earns its length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter check tool with no output schema, the description covers the input format, return type (JSON boolean), and basic analysis logic. It omits error conditions and edge cases, but is sufficiently complete for typical use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain parameters. It specifies that 'threat_events' is a JSON string of an array and 'time_window_hours' is optional with default 'auto'. This adds meaning beyond the schema's types and titles, though more detail on expected JSON format would improve it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool checks if multiple threat events are part of a coordinated attack, with a specific verb and resource. It lacks explicit differentiation from sibling tools like 'correlate_threat' and 'detect_campaign', but the analysis of timing and pattern similarity provides some distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives such as 'correlate_threat' or 'detect_campaign'. The description only mentions a prerequisite (Pro tier or Novyx Cloud), but does not specify contexts or exclusions.

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

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

Annotations declare readOnlyHint=true, so the description's 'Check if a threat correlates' is consistent with a read operation. The description adds context about cross-referencing the threat fingerprint against the network database, but does not disclose other behavioral traits like rate limits or error handling. The annotation already covers the safety profile, so the description adds moderate extra value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (5 lines) and front-loaded with a clear one-line summary. It is structured with a purpose statement, a cross-referencing detail, prerequisites, and an args/returns section. Every sentence serves a purpose without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has a single parameter, annotations indicating read-only, and an output schema (existence assumed), the description adequately covers the tool's purpose, input, and return. It lacks details on error conditions or format of the output, but the presence of an output schema mitigates the need for deep explanation. Minor gaps prevent a perfect score.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% (parameter description is just 'Threat Event'), but the description states that 'threat_event' is a 'JSON string describing the threat to correlate.' This adds semantic meaning beyond the schema, though it does not detail the expected structure or required fields. The description partially compensates for the low schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Check if a threat correlates with attacks on other tenants.' This uses a specific verb ('check') and resource ('threat correlation'), and distinguishes it from sibling tools like 'threat_match' (likely local) and 'threat_mitigate' (likely remediation).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions a prerequisite ('Requires Pro tier or Novyx Cloud'), but does not provide explicit guidance on when to use this tool versus alternatives such as 'threat_match' or 'threat_record'. The context of cross-tenant correlation is implied, but no when-to-use or when-not-to-use rules are given.

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

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

Annotations already declare readOnlyHint=true; the description adds value by listing the specific configuration elements (thresholds, decay rates, schedule) and the required access tier, going beyond the annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences with no fluff, front-loaded with the core purpose, and each sentence adds necessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters, an output schema, and annotations, the description fully covers what the tool does, what it returns, and access requirements.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters; schema coverage is 100%, so baseline is 4. The description does not need to add parameter info.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Get' and resource 'Cortex configuration', clearly distinguishing it from sibling tools like cortex_update_config (update) and cortex_status (status).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states a prerequisite (Pro tier or Novyx Cloud) but does not provide explicit when-to-use or when-not-to-use guidance relative to alternatives like cortex_update_config.

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

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

Annotations already declare readOnlyHint=true, so no contradiction. The description adds that insights are 'auto-generated' and requires an Enterprise tier, which provides some behavioral context. However, it does not disclose any error conditions, pagination behavior, or performance characteristics beyond the default limit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with three short sentences plus a structured 'Args' and 'Returns' section. Every sentence adds value, and the purpose is front-loaded. No redundant or wasteful wording.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with one parameter and an output schema, the description covers the core functionality, return format, and access requirement. It does not discuss error handling or limits beyond the default, but given the low complexity, this is adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, but the description explicitly documents the sole parameter 'limit' with its purpose ('Maximum insights to return') and default value (20), adding significant meaning beyond the raw schema. This compensates well for the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List auto-generated memory insights', specifying the verb 'List' and the resource 'auto-generated memory insights'. This distinguishes it from sibling tools like 'list_memories' which list user memories, and 'recall' which queries memories. The 'auto-generated' qualifier adds precision.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions a prerequisite ('Requires Enterprise tier or Novyx Cloud') but does not provide guidance on when to use this tool versus alternatives such as 'list_memories' or 'recall'. There is no explicit statement of context or exclusions, making it insufficient for an agent to decide between related tools.

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

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

Beyond the destructiveHint annotation (false), the description details the safe operations performed (consolidation and reinforcement) and the requirement for a specific tier. It could further mention any rate limits or cooldown, but current info is sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is exceptionally concise: two short paragraphs with clear bullet points. Every sentence adds value with zero redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters, clear purpose) and the presence of annotations and output schema mention, the description fully covers what an agent needs to decide to invoke this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist in the schema (100% coverage), so the description adds no param info. With zero parameters, a baseline score of 4 is appropriate as there is nothing to clarify.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'trigger' and the resource 'Cortex cycle'. It explains the two operations (consolidation and reinforcement) and distinguishes from sibling tools like cortex_status or cortex_config.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It mentions the normal automatic schedule and a prerequisite (Pro tier or Novyx Cloud), providing context for when manual use is appropriate. However, it does not explicitly state when not to use it or list alternatives.

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

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

Annotations already indicate readOnlyHint=true. The description adds behavioral details beyond that, such as 'last run time' and 'consolidation/reinforcement stats', and notes the return type. No contradictions 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (4 sentences) and front-loaded with the main action. Every sentence adds value: purpose, details, requirement, and return format. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple status retrieval tool with no parameters, the description is complete. It covers the output (JSON string with status and last run info) and prerequisites. The output schema is available for return values, so additional detail is not needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, and schema coverage is 100%. The description does not need to add parameter info. Baseline for 0 parameters is 4, and the description is appropriately minimal.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get Cortex autonomous intelligence status.' It specifies what is shown (enabled, last run time, consolidation/reinforcement stats) and the return format (JSON string). This is specific and distinguishes it from sibling tools like cortex_config or cortex_run.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a clear prerequisite: 'Requires Pro tier or Novyx Cloud.' This helps the agent understand when the tool is usable. However, it does not explicitly mention when not to use it or provide alternatives among sibling tools.

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

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

Annotations only include destructiveHint=false. The description adds the behavioral trait of being a mutation (update) and the tier requirement. For a simple config update, this is sufficient; no additional side effects are noted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with a one-line purpose, a brief explanation of the tool's functionality, a prerequisite line, and formatted argument descriptions. Every sentence adds value without excess.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With three optional parameters and an output schema (not shown but indicated as existing), the description covers the essential semantics. It could mention default behaviors when params are null, but the current level is adequate for a config update tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description fully compensates. Each parameter has a clear explanation: consolidation_threshold (range 0.0-1.0), reinforcement_boost (how it affects recall), decay_rate (fade speed). This adds the meaning the schema lacks.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Update Cortex configuration' and specifies the resources affected (memories consolidation, reinforcement, decay). This distinguishes it from sibling tools like cortex_config (likely read-only) and cortex_status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It mentions the prerequisite 'Requires Pro tier or Novyx Cloud', which guides usage. However, it does not explicitly state when to use this tool versus alternatives like cortex_config for reading. The inference is clear but not explicit.

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

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

Annotations only give destructiveHint=false. The description adds that it creates an entity and explains provider behavior, but does not disclose side effects, permissions, or behavior on duplicate agent_id.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Main purpose is front-loaded, and the Args list is structured logically. The litellm context is useful but adds length; minor redundancy in describing requirements.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, parameters, and provider guidance. Output schema exists, so return values need not be described. Missing edge-case behavior (e.g., conflict handling) but acceptable given annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description's Args section adds meaning by describing each parameter (e.g., provider options, model examples). However, some descriptions like 'policy_profile: JSON string' are brief, lacking format details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states 'Create a first-class agent entity', using a specific verb and resource. It distinguishes from sibling tools like update_agent, delete_agent, get_agent, and list_agents by focusing on creation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear guidance on when to use different providers, especially litellm for unsupported models. However, it does not explicitly state when not to use this tool or compare to siblings like update_agent for modifications.

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

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

Annotations only provide destructiveHint=false. Description adds governance details (risk levels, approval, memory, eval) but omits side effects, permissions, or validation behavior. Moderate transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with clear purpose. Uses docstring style (Args:) but is somewhat lengthy with 7 parameters. Efficient but not maximally concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers core purpose and parameter meanings. No return value explanation needed due to output schema. Missing prerequisites or error cases, but sufficient for a creation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage 0%. Description lists all parameters with brief explanations but lacks format details (e.g., JSON string specifics). Provides basic meaning but not rich enough to fully compensate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clear verb+resource: 'Register a capability pack' with governance. Distinguishes from siblings like get/update/delete_capability.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or alternatives mentioned. Description implies usage for registering capability packs but lacks context on when to prefer this over other tools.

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

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

The description does not contradict annotations (destructiveHint=false). It adds 'rollback point' context but does not disclose other behavioral traits such as whether an existing checkpoint with the same label is overwritten, permission requirements, or error handling. Annotations already indicate non-destructive nature.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with no unnecessary words. It front-loads the core purpose and follows with a clear parameter list. Every sentence is meaningful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 3 parameters, no enums, and an output schema exists, the description covers the essentials. It could mention the return value or error scenarios, but the presence of an output schema reduces the need. Adequate for a simple create operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds meaning beyond schema titles: it clarifies 'mission_id: Mission to checkpoint', 'label: Human-readable label', and 'metadata: JSON string of additional metadata' (the schema allows both string and object but description specifies JSON string). This compensates for the 0% schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Create a checkpoint') and the resource ('for a mission') with explicit mention of 'rollback point'. It distinguishes well from siblings like 'get_checkpoint', 'list_checkpoints', 'rollback_to_checkpoint'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the usage context (creating a rollback point) but does not explicitly state when to use vs. alternatives like 'create_mission' or 'rollback'. It provides clear context but lacks exclusion or alternative guidance.

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

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

Annotations only provide destructiveHint: false. The description says 'Record' implying a write operation, but does not disclose side effects, whether it overwrites existing data, required permissions, or if the intervention triggers automated actions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief and front-loaded with the purpose, followed by a clear bullet list of parameters. Every sentence adds value, no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool creates a record and has an output schema (not shown), the description sufficiently covers input but omits success/error behavior or return value expectations. It is minimally complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description provides essential meaning for all 6 parameters, including a list of acceptable values for intervention_type. However, it could provide more detail, e.g., format constraints for metadata or whether parameters are optional in certain contexts.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Record a supervisor intervention' and lists specific intervention types (approve, reject, pause, escalate), distinguishing it from siblings like 'get_intervention' and 'list_interventions'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. Does not mention that this creates a new intervention record or advise against using it for retrieval (which would be handled by sibling tools).

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

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

The description only reiterates the creation action, adding no behavioral insight beyond the annotation `destructiveHint: false`. It omits disclosures about side effects, required permissions, or post-creation behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, using one introductory sentence followed by a clear bullet list of arguments. Every word serves a purpose, though the list format is slightly redundant with the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 5 parameters and an output schema, the description fails to explain the return value, prerequisites (e.g., agent existence), or how to handle optional parameters. It does not leverage sibling tool context to guide usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds brief explanations for all five parameters, covering the 0% schema coverage. However, the explanations are minimal (e.g., 'Constraints on execution') and lack specificity about format or constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Create' and the resource 'mission (bounded job)', making the tool's purpose unambiguous. It effectively distinguishes from sibling tools like cancel_mission and update_mission.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives (e.g., create vs update). The description lacks any context about prerequisites or scenarios where this tool is appropriate.

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

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

Annotations only provide readOnlyHint=false, which is consistent. The description adds that policies are evaluated on every action submission and requires a plan. However, it does not disclose whether policies can be overwritten or any side effects of creation, which limits transparency for a write operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is well-structured: an introductory sentence followed by parameter details in a bullet-like format. Every sentence adds value, and the purpose is front-loaded. No redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (5 parameters, nested structures) and the presence of an output schema, the description covers all aspects: purpose, parameters, return format, and plan requirement. Lacks mention of error handling or limits on number of policies, but is sufficient for agent usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by detailing all parameters: name, description, rules (with sub-fields like match, severity, reason, etc.), step_types, and whitelisted_domains. Examples are given (e.g., 'pii_protection').

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Create a custom governance policy for your agent's actions.' The verb 'create' and noun 'policy' are specific, and it distinguishes from sibling tools like check_policy (evaluate an action) and list_policies (list existing policies).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description provides clear context: policies are evaluated alongside built-in policies on every action submission, and requires Starter plan. However, it does not explicitly state when not to use this tool or compare to alternatives like check_policy or delete_policy.

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

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

Annotations provide destructiveHint=false, indicating non-destructive. The description adds that the creator is the owner with permission grants, which is useful context. However, it does not disclose any additional behavioral traits like rate limits or side effects beyond the basic creation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: a two-sentence purpose followed by a bulleted Args list. No extraneous information, and front-loaded with the core action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (4 params, 1 required, output schema exists), the description covers purpose, parameters, and return value (JSON with space_id). It lacks error handling or uniqueness notes but is sufficiently complete for a creation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description compensates by listing each parameter with brief explanations (e.g., 'Optional description of the space's purpose'). While not deeply detailed, it adds meaning beyond the schema's type and name.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'create' and the resource 'shared context space' for multi-agent collaboration. It distinguishes from sibling tools like share_space, update_space, list_spaces, and delete_space by focusing specifically on creation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description lacks explicit guidance on when to use this tool versus alternatives like share_space or update_space. It does not provide when-not-to-use instructions or mention any prerequisites.

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

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

Annotations already indicate read-only. Description adds value by specifying the components (stats, spaces, recent activity) and return format, 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences plus a return note, all front-loaded with purpose. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and existing output schema, description fully covers usage and return value. Complete for a simple retrieval tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters, so baseline 4 applies. Description mentions return format which is helpful.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get a full dashboard overview' with a specific verb and resource, and distinguishes it from siblings as a composite aggregation tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly recommends use for 'periodic status checks or reporting,' providing clear context. Could mention when not to use, but sufficient for a simple tool.

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

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

Annotations indicate destructiveHint=false, and description correctly indicates it's a write operation (deploying a rule). No contradiction, but description does not add behavioral context beyond what annotations and the action description imply.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise with about 4 lines. Front-loaded with purpose, then prerequisites and parameter explanations. Could be slightly more streamlined but generally efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an output schema exists (context signal true), the description's note about return value (JSON string with details) suffices. For a creation tool with 3 parameters, it covers essential aspects but omits error handling or idempotency.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description compensates well by explaining each parameter: signature_id as threat signature, rule_type as defense type with enumerated values, and rule_config as optional JSON string. Adds meaning beyond schema titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it deploys a defense rule against a threat signature, listing the action types (block, rate-limit, quarantine, alert_only). It distinguishes from sibling tools like defense_list or defense_remove.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool vs alternatives. The description mentions a prerequisite (Pro tier or Novyx Cloud) but does not specify when not to use it or provide context for decision-making.

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

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

The description adds value beyond the readOnlyHint annotation by explaining the scoring basis ('blocks vs false positives') and the tier requirement. It does not mention any destructive behavior, which is consistent with the read-only hint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is four sentences with no extraneous words. It is front-loaded with the purpose, then details the return value, requirements, and argument. Very efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (1 param, read-only, output schema exists), the description covers input, output format, and requirements. A minor gap is lack of error handling, but overall it is adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Since schema description coverage is 0%, the description compensates by explaining 'defense_id: The defense rule ID to evaluate.' This provides necessary meaning beyond the schema's empty description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Measure the effectiveness of a deployed defense' with a specific verb and resource. It distinguishes from siblings by mentioning the 0-1 score based on blocks vs false positives, which is unique among defense tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions a prerequisite ('Requires Pro tier or Novyx Cloud') but does not provide explicit guidance on when to use this tool versus alternatives like defense_stats. The context is implied but not fully elaborated.

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

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

Annotations already indicate readOnlyHint=true; the description adds that it returns a JSON string and requires a tier, providing helpful context without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief, uses a clear structure with 'Args:' and 'Returns:', and every sentence adds value. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with an output schema, the description covers purpose, prerequisites, parameter options, and return type completely. No gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter rule_type is described in detail with allowed values ('block, rate_limit, quarantine, or alert_only'), fully compensating for the 0% schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List active auto-deployed defense rules', specifying the verb (list) and resource (defense rules). It distinguishes from sibling tools like defense_deploy or defense_remove by focusing on listing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context: 'Requires Pro tier or Novyx Cloud' and optional filter, but does not explicitly exclude other tools or give when-not guidance. It is clear enough for typical use.

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

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

Annotations already declare readOnlyHint=true, so the description adds value by mentioning the tier requirement and the return format. 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise and well-structured: first sentence states purpose, then output format, requirement, and finally args/returns. Every sentence adds value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple single-parameter tool with an output schema, the description covers the purpose, return fields, and prerequisite. It is fully sufficient for the agent to understand and use the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, but the description explains the parameter signature_id as 'The threat signature to get a recommendation for.' This provides necessary context beyond the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool's purpose: 'Get a recommended defense strategy for a threat signature.' It specifies the output (rule_type, confidence, reasoning) and distinguishes from sibling tools like defense_deploy and threat_*.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Includes a prerequisite ('Requires Pro tier or Novyx Cloud') which guides usage. However, it does not explicitly state when to use this tool versus alternatives or provide when-not scenarios. The context is clear enough given sibling names.

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

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

Annotations provide destructiveHint:false, which aligns with the logging nature of the tool. The description adds value by stating that marking false positives triggers auto-tuning, and it discloses a licensing requirement. 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the primary purpose, followed by usage context and structured parameter details. It is efficient but the Args section partially repeats schema information; still, it is clear and well-organized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 2 simple parameters and an output schema, the description covers purpose, usage, prerequisites, and parameter meanings. It mentions the return type but could elaborate on error conditions or ID format, though not necessary for clarity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it does. For both parameters, it provides full descriptions: defense_id is 'the defense rule that blocked the threat' and is_false_positive explains its boolean nature and default.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with 'Record that a defense blocked a threat,' which is a specific verb+resource combination. This clearly distinguishes it from sibling tools like defense_stats or defense_list, which are query or management tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains it is used to track defense performance and auto-tune rules via false positives. It also states the prerequisite of Pro tier or Novyx Cloud. However, it does not explicitly mention when not to use it or compare to alternatives, though no direct alternative exists.

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

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

Annotations already declare destructiveHint: true. Description adds that it stops defense actions and returns confirmation, but lacks deeper behavioral context like reversibility or error scenarios.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise, front-loaded with action, followed by effect and prerequisite. Uses clear docstring format with no redundant sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a simple remove tool: states purpose, input, output, and prerequisite. Could mention where to obtain defense_id or note irreversibility, but overall sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description explains defense_id as 'The defense rule ID to remove.' This adds basic meaning but lacks format examples or sourcing guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool removes a deployed defense rule with specific verb and resource. Distinguishes from siblings like defense_deploy and defense_list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides prerequisite (Pro tier/Novyx Cloud) and effect (stops blocking/rate-limiting), but does not explicitly state when not to use or offer alternatives.

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

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

Annotations already indicate read-only behavior. The description adds that the return is a JSON string, which is helpful but does not disclose other behavioral traits like data freshness or access limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two clear sentences and a return type line. It is front-loaded with the core purpose and efficient, though the requirement line could be more integrated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters, a simple output schema, and read-only annotations, the description covers the essential information. However, it could specify the scope (e.g., per workspace or global) for added completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so the schema coverage is effectively 100%. The description adds no parameter info, but none is needed, meeting the baseline for zero-parameter tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns overall defense statistics with specific fields (total defenses, active count, etc.), distinguishing it from more specific sibling tools like defense_effectiveness or defense_list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The only guidance is a prerequisite (Pro tier or Novyx Cloud), but there is no information on when to use this tool versus alternatives like defense_effectiveness or defense_list.

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

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

The destructiveHint annotation already signals destructive behavior. The description repeats 'delete' without adding further context (e.g., irreversibility, cascading effects). Minimal value added 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no extraneous words. However, it is so minimal that it borders on under-specification. It earns a high conciseness score but loses some for being too sparse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one parameter and an output schema, the description lacks details about return values, side effects (e.g., if the agent is being used), or error conditions. It is not complete enough for confident invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage for the sole parameter 'agent_id'. The description does not explain what agent_id refers to or how to obtain it, leaving the agent without meaningful guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Delete an agent' clearly states the action and resource, matching the tool name. It distinguishes from sibling tools like create_agent or update_agent, but could add detail about permanence or scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives (e.g., delete_capability), or prerequisites like the agent existing. The agent must infer usage solely from the name.

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

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

Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds no additional behavioral context beyond confirming deletion. It does not mention irreversibility, cascading effects, or permission requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise (one sentence) but lacks structure such as clear separation of purpose, usage, or parameter details. It is front-loaded but too brief to be fully effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the low complexity, the description is incomplete. It does not mention return values, side effects, or prerequisites. The output schema exists but is not referenced in the description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No description is provided for the required parameter 'capability_id'. With 0% schema coverage, the description fails to explain what constitutes a capability_id or how to obtain it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (delete) and the resource (capability pack). It is specific and differs from sibling tools like create_capability or get_capability, but does not explicitly distinguish itself from them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives (e.g., update_capability, get_capability). No prerequisites or conditions for deletion are mentioned.

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

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

The annotation destructiveHint: true already signals destructiveness. The description adds context about the scope (deleting entity and all associated triples), which is beyond the annotation. It is consistent and useful.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: two sentences plus structured Args and Returns sections. It front- loads the core action and avoids unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple delete tool with one parameter, the description covers purpose, parameter, and return format. It lacks details on error handling or prerequisites but is adequate given the output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description provides a helpful explanation for the only parameter (entity_id) in the Args section, adding meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool deletes a knowledge graph entity and all its triples, distinguishing it from siblings like delete_triple, which only removes a triple. It uses specific verbs ('delete', 'removes') and names the resource ('entity', 'triples').

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains what the tool does but provides no guidance on when to use it versus alternatives like delete_triple. It does not mention prerequisites, conditions, or scenarios for use.

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

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

The description is consistent with annotations (destructiveHint: true) but does not add additional behavioral context such as cascading effects, permissions, or irreversibility. Annotations already flag destructiveness.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence efficiently conveys the tool's purpose with no extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While an output schema exists, the description is minimal and omits critical details such as whether deletion is permanent, any side effects, or required permissions. For a destructive tool, more context is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter (mission_id) has no description in the schema or in the tool description. With 0% schema description coverage, the description fails to explain what mission_id is or how to obtain it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Delete a mission,' which is a specific verb+resource combination. It distinguishes from sibling tools like create_mission, update_mission, cancel_mission, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like cancel_mission. No prerequisites or context for usage are mentioned.

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

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

Annotations already indicate destructive hint; the description adds that it is a soft-delete and explains the effect (no longer evaluates on action submissions), providing useful behavioral context 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences plus an Args/Returns section with no unnecessary words. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given one parameter and a simple return type (JSON string confirmation), the description fully covers purpose, constraints, and return value. No gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter, policy_name, is explained as 'Name of the custom policy to disable', adding context that it must be custom. The schema itself has no descriptions, so the description compensates well.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool disables a custom governance policy via soft-delete, using specific verb and resource. It distinguishes from siblings like create_policy and list_policies.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states that built-in policies cannot be deleted, providing a clear when-not-to-use rule. Implicitly guides use for custom policies only.

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

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

Adds ownership constraint and return value ('JSON string indicating success') beyond the destructiveHint annotation. 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise: two lines of description plus a docstring for args/returns. Front-loaded purpose statement. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, usage constraint (ownership), parameter, and return value. Despite simplicity, description is complete for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Provides description for space_id ('The space ID to delete') that adds meaning beyond the input schema, which had no description for the parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states verb 'delete' and resource 'context space', plus ownership constraint 'owner only'. Distinguishes from sibling tools like create_space and update_space.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Specifies 'owner only' as prerequisite. Implicitly clear when to use, but does not explicitly discuss alternatives or situations to avoid.

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

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

The description adds little beyond the annotations. Annotations already indicate 'destructiveHint: true'. The description confirms deletion but does not disclose additional behavioral traits such as error scenarios, permissions needed, or side effects beyond what is obvious.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loaded, with three sentences covering action, parameter, and return value. However, the explanation of a triple could be considered redundant given the tool name, but overall it is efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and an existing output schema, the description covers the basics. However, it omits important context like error handling, the need for the triple to exist, and any potential irreversible consequences beyond the destructive hint.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage for the single parameter. The description provides a minimal explanation ('ID of the triple to delete') that essentially restates the parameter name. It lacks details on format, source, or validation, failing to compensate adequately for the lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'Delete a knowledge graph triple' and explains the resource ('subject-predicate-object relationship'). The tool name and description are unambiguous, and siblings include 'add_triple' and 'query_triples', making the purpose distinct.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. It does not specify when deletion is appropriate, what prerequisites exist (e.g., the triple must exist), or when not to use it.

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

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

Annotations indicate read-only, and description adds multi-tenant scope and tier requirement, but lacks details on detection method or limitations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise with front-loaded purpose, but redundant first two sentences could be merged. Overall clear and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers main usage, required tier, parameter, and return value. With output schema present, no need for more detail.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Describes the 'hours' parameter fully with look-back window and default, adding meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool detects ongoing attack campaigns across multiple tenants, distinguishing it from other tools in the sibling list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides prerequisites (Pro tier or Novyx Cloud) and parameter hint, but no explicit when-not-to-use or alternatives like coordhe attack_check.

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

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

Annotations indicate 'readOnlyHint: true', and the description adds that it returns a JSON string with changed fields and a merge recommendation. This provides useful behavioral context beyond the annotation, although it does not disclose any additional constraints (e.g., whether the draft must be active).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief, front-loads the main action, and separates Args and Returns in a structured format. Every sentence serves a purpose without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an existing output schema and annotations, the description covers the tool's purpose, parameters, and return value adequately. The tool is not complex, and the description, combined with structured metadata, provides complete contextual information for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description explains 'draft_id' as returned by 'draft_memory' and 'compare_to' as an optional existing memory UUID. This adds essential meaning not present in the schema, though it could specify how 'compare_to' affects the diff (e.g., comparing to a specific version).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it 'Show a field-level diff for a memory draft,' with specific verb and resource. It differentiates from sibling tools like 'draft_memory' (which creates drafts) and 'merge_draft' (which merges), but does not explicitly contrast them, leaving some ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus alternatives such as 'merge_draft' or 'reject_draft'. It neither states conditions for use nor precludes other tools, leaving the agent to infer context from the name and description alone.

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

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

The description discloses that the tool is non-destructive and does not commit to canonical memory, which aligns with the 'destructiveHint: false' annotation. It adds value by explaining the draft behavior, though it does not cover other behavioral aspects like auth or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: a one-line purpose, a bullet-like list of arguments with types/defaults, and a clear return statement. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description, combined with the output schema, provides sufficient information for most use cases. It covers the core purpose, parameters (mostly), and return format. The omission of 'branch_id' is a minor gap, but overall completeness is high.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description compensates by detailing five of six parameters (observation, tags, importance, context, confidence) including types and defaults. However, 'branch_id' is missing from the description, leaving a gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Create a reviewable draft without writing to canonical memory.' It uses a specific verb ('create') and resource ('draft'), and distinguishes it from sibling tools like 'remember' that write to canonical memory.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use the tool ('without writing to canonical memory'), implying it's for proposing content for review before committing. However, it does not explicitly 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.

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

Annotations only provide destructiveHint: false. Description adds that it saves a baseline and mentions limits, but does not disclose overwrite behavior, idempotency, or error handling. Adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise docstring with front-loaded purpose, followed by context, limits, and parameter descriptions. No wasted words, well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Describes returned type (JSON string) but no output schema or details on error cases, idempotency, or auth. Adequate for a simple creation tool but leaves gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but description provides meaningful parameter descriptions (query = recall query, expected_observation = expected top result). Adds value beyond bare schema titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clear verb 'Save a recall baseline for regression testing' defines exact action and resource. Differentiates from sibling tools like eval_baseline_delete and eval_baselines.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explains purpose with future regression testing context and plan limits (Free/Starter/Pro). Lacks explicit when-not-to-use or alternatives but sufficient for usage context.

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

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

Annotations already mark it as destructive. Description adds that it returns a JSON string confirming deletion, but lacks details on permissions or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise with a one-line summary and clear Args/Returns sections, no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a simple delete tool, but could specify error cases or the confirmation JSON structure. Output schema exists but is not detailed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter, baseline_id, with description stating it is a UUID, adding semantic meaning beyond the schema's basic type and title.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description uses specific verb 'Delete' and resource 'eval baseline', clearly distinguishing it from sibling tools like 'eval_baseline_create' and 'eval_baselines'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives or prerequisites. Simply states the action without context.

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

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

Annotations already declare readOnlyHint=true, which this reinforces. The description adds return format (JSON string). No further behavioral details (e.g., no mention of permissions or result size).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise: two sentences and a return line. No redundant information. Purpose is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only tool with an output schema, the description explains the tool's purpose, content, and return type. No gaps given the simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so schema coverage is 100%. The description adds meaning by explaining the content of the returned list (recall queries and expected observations), going beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'List' and the resource 'saved eval baselines'. It defines what baselines are (recall queries and expected observations) and contrasts with siblings eval_baseline_create/eval_baseline_delete.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for listing baselines but does not explicitly state when to use it versus alternatives or provide exclusion criteria. Sibling names hint at distinct use cases, but no direct guidance.

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

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

Annotations already declare readOnlyHint=true, so the read-only nature is transparent. The description adds that it returns a JSON string with drift metrics, but does not elaborate on other behavioral traits such as authentication needs or performance impact.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with three short paragraphs, front-loading the purpose. Every sentence adds value: purpose, explanation, args, returns. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and an output schema, the description covers purpose, usage, parameter, and return. It could briefly mention that it's read-only, but annotations already cover that, so completeness is high.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explicitly documents the 'days' parameter with meaning ('Number of days to look back'), default value, and identifies the return format, fully addressing the parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Detect memory drift over a time period' and explains it shows counts of created, deleted, and updated memories. This purpose distinguishes it from sibling tools like eval_history or eval_run.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description says 'Useful for monitoring memory churn,' providing a clear use case. However, it does not explicitly mention when not to use this tool or suggest alternatives among sibling eval tools, so it lacks exclusions.

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

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

Annotations indicate readOnlyHint: true, so the tool is read-only. The description adds context that it acts as a gate returning a pass/fail result, which is consistent. It does not contradict annotations and provides behavioral context beyond the safety profile.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences: a clear purpose statement, usage context, and concise parameter/return description. It is front-loaded and contains no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, output schema present), the description adequately explains the return format in general terms. It could mention error conditions or detailed result structure, but overall it is complete enough for a gate tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully explains the single parameter 'min_score' as a minimum acceptable score in the range 0.0 to 1.0. This adds complete meaning beyond the schema's type definition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool is a CI gate that passes or fails based on memory health score. It distinguishes from siblings like eval_run by emphasizing CI/CD pipeline use, though it could be more specific about the concept of memory health.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says to use in CI/CD pipelines to block deploys when memory quality degrades. However, it does not mention when not to use this tool or provide alternatives from the sibling list, such as eval_run for general evaluations.

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