Korext: AI Code Governance

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool returns violations with details, but it lacks critical information such as whether this is a read-only operation, potential rate limits, authentication requirements, or error handling. For a tool with no annotations, this leaves significant gaps in understanding its 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 front-loaded and concise, consisting of a single sentence that efficiently conveys the tool's action, inputs, and outputs without unnecessary details. Every word earns its place, making it easy for an agent to quickly understand the tool's function.

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 (code analysis with policy packs) and the absence of annotations and output schema, the description is moderately complete. It covers the purpose and return values but lacks details on behavioral traits and usage context. It is adequate as a minimum viable description but has clear gaps that could hinder effective tool selection and 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 description coverage is 100%, so the schema already documents both parameters ('code' and 'packId') with descriptions. The description adds no additional meaning beyond what the schema provides, such as examples or constraints, but it does not contradict the schema. Baseline 3 is appropriate when the schema handles parameter documentation effectively.

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 with specific verbs ('Check a code snippet') and resources ('against one or more policy packs'), and it distinguishes from sibling tools by focusing on code analysis rather than proof generation, directive retrieval, or pack listing. It explicitly mentions the return content (violations with severity, governance context, line numbers), making the purpose distinct and comprehensive.

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 code checking with policy packs, but it does not provide explicit guidance on when to use this tool versus alternatives like 'generate_proof' or 'get_directives'. No exclusions or prerequisites are mentioned, leaving the agent to infer context from the tool's 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?

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it performs scanning and generates a signed proof bundle (implying a write/mutation operation), and specifies the return data (bundle ID, decision, violation count, URL). However, it lacks details on permissions, rate limits, error handling, or whether the operation is idempotent.

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, dense sentence that efficiently conveys the tool's purpose, action, and return values. Every part adds value: scanning context, proof generation, and output details. No wasted words or 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 mutation tool with no annotations and no output schema, the description is moderately complete. It covers the core action and return data, but lacks details on error cases, side effects, or verification process. Given the complexity (code scanning with cryptographic signing), more behavioral context would be helpful.

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

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

Schema description coverage is 100%, so the schema fully documents all 4 parameters. The description doesn't add any parameter-specific details beyond what the schema provides (e.g., it doesn't explain 'packId' defaults or 'language' options). Baseline 3 is appropriate when the schema handles parameter documentation.

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 specific action ('Scan code against policy packs and generate a cryptographically signed proof bundle') and distinguishes it from siblings like 'check_code' (likely simpler scanning) and 'get_proof' (retrieving existing proofs). It specifies both the input (code scanning) and output (proof bundle generation).

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 scanning code to produce verifiable proofs, but doesn't explicitly state when to use this versus alternatives like 'check_code' (which might return immediate results without proof generation) or 'get_proof' (for retrieving existing proofs). No guidance on prerequisites or exclusions is provided.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool returns enriched rules with governance context, but lacks details on permissions, rate limits, error handling, or whether it's a read-only operation. This leaves significant gaps for a tool that presumably accesses policy data.

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, efficient sentence that front-loads the core purpose. It could be slightly more structured by separating usage context from output details, but it avoids redundancy and wastes no 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 has no annotations and no output schema, the description is moderately complete for a single-parameter query tool. It explains the purpose and output content but lacks behavioral context and detailed usage guidelines, which are important for policy-related operations.

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 100%, so the schema fully documents the 'packId' parameter. The description adds no additional parameter semantics beyond implying it accepts one or more policy packs, which is already covered by the schema's oneOf structure. This meets the baseline for high 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 specific action ('Get enriched policy directives and living standards') and resource ('for one or more policy packs'), distinguishing it from siblings like 'check_code' or 'list_packs' by specifying it returns rules with governance context for inference time enforcement.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'list_packs' or 'check_code', nor does it mention prerequisites or exclusions. It only states what the tool does without contextual usage information.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a retrieval operation, implying read-only behavior, but doesn't cover critical aspects like authentication needs, rate limits, error handling, or whether the bundle ID must be pre-existing. It mentions return content but not format or structure.

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 front-loaded, with two sentences that efficiently convey the core action and return values. There's no wasted text, though it could benefit from more context to improve completeness.

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 annotations and no output schema, the description is incomplete for a retrieval tool. It mentions return fields (decision, violations, packs, verification status) but doesn't explain their meaning, format, or how to interpret them. For a tool with one parameter and no structured output, more detail is needed to guide effective 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?

The input schema has 100% description coverage, with the parameter 'bundleId' documented as 'The proof bundle ID (kpb_...)'. The description adds no additional meaning beyond this, such as where to obtain the ID or validation rules. Baseline 3 is appropriate since the schema does the heavy lifting.

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 with a specific verb ('Retrieve') and resource ('proof bundle by ID'), and mentions what it returns. However, it doesn't explicitly differentiate from sibling tools like 'list_packs' or 'get_directives', which might also retrieve related data.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid bundle ID), exclusions, or comparisons to siblings like 'generate_proof' for creating proofs or 'list_packs' for listing packs.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it lists packs with tags, but doesn't describe key traits such as pagination, rate limits, authentication needs, or whether it's read-only (implied by 'list' but not explicit). This leaves gaps in understanding the tool's behavior beyond basic functionality.

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, efficient sentence that directly states the tool's purpose and filtering capability. It is front-loaded with the main action and resource, with no redundant or unnecessary information, making it highly concise and well-structured.

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

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

Given the tool's low complexity (2 optional parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and filtering, but lacks details on behavioral traits, usage context, and output format, which are needed for full agent understanding. It's minimally viable but has clear 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 input schema has 100% description coverage, detailing both parameters ('region' and 'industry') with examples. The description adds minimal value beyond this, only mentioning filtering by 'industry and region tags' without providing additional context or semantics. This meets the baseline for high schema coverage, but doesn't enhance parameter understanding.

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 ('List') and resource ('available policy packs'), and mentions the filtering capability by 'industry and region tags'. It distinguishes itself from siblings like 'check_code' or 'generate_proof' by focusing on listing rather than checking or generating. However, it doesn't explicitly differentiate from other list-like tools if they existed, but in this context, it's 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?

The description provides no guidance on when to use this tool versus alternatives. It mentions filtering by industry and region, but doesn't specify scenarios, prerequisites, or exclusions. For example, it doesn't indicate if this is for initial discovery, compliance checks, or other contexts, leaving the agent with minimal usage direction.

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