Kopern

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

Beyond the readOnlyHint annotation, the description discloses the specific compliance articles it checks and notes 'No LLM cost', which is a behavioral trait (deterministic, no token usage). This adds useful context about what the report covers and its resource footprint.

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?

Two sentences, zero filler, and front-loaded with the action and object. Every word adds value, and it includes only necessary details like article references and cost behavior.

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

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

With one required parameter, readOnlyHint annotation, and no output schema, the description fully covers what the tool does, which articles are checked, and the 'No LLM cost' behavior. There are no significant gaps for an agent to invoke it 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?

The schema provides 100% coverage for the sole parameter 'agent_id' with a clear description ('The agent ID or name'). The description adds no extra parameter semantics, but the schema fully handles it, so baseline 3 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 the tool generates an EU AI Act compliance report for an agent, listing the specific articles checked (Art. 6, 12, 14, 52). This is a specific verb+resource combination that distinguishes it from all sibling tools, none of which handle compliance reporting.

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 should be used when an EU AI Act compliance report is needed, but it does not explicitly state when to use it or exclude alternatives. There is no mention of alternative tools or prerequisites, so usage context is only implied.

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 minimal annotation (readOnlyHint:false), the description adds valuable behavioral context: it requires OAuth in a browser and enables the service_calendar builtin tool. This conveys a mutating, state-changing operation, though it does not discuss reversibility or credential handling, so not a 5.

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 consists of three short, purposeful sentences: the first states the main action, the second gives a critical requirement, and the third explains the result. There is no redundant or extraneous information; every sentence earns its place and 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 simple tool with only 2 required parameters and no output schema, the description covers all key aspects: what it does (connects agent to calendar), the prerequisite (OAuth), and the expected effect (enables the service_calendar builtin tool). It is complete given the tool's 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?

The schema description coverage is 100%, with both parameters (agent_id and provider) already documented in the schema. The description does not add additional meaning beyond what the schema provides, such as examples or constraints, so the baseline of 3 applies.

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 ('Connect an agent') and the target resource ('Google Calendar or Microsoft Calendar'), with the purpose 'for scheduling tools'. It distinguishes itself from sibling connect tools by specifically naming calendar providers and the service_calendar builtin tool, making its unique role unambiguous.

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 on when to use the tool (for enabling scheduling tools) and a key prerequisite (OAuth in browser). It also explains the outcome (enables the service_calendar builtin tool), but it does not explicitly mention alternatives or exclusions, so it stops short of a 5.

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

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

Annotations include only readOnlyHint=false, so the description adds valuable behavioral context: it 'Requires OAuth in browser' (user interaction) and 'Enables the service_email builtin tool' (side effect). This goes beyond the annotation and sets expectations for the user.

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 two short sentences, front-loaded with the core action and purpose. Each sentence contributes meaningful information (providers, prerequisite, outcome) with no fluff or repetition.

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 2-param tool with no output schema, the description covers the what, the requirement (OAuth), and the result (enables service_email). It could add details about return values or failure behavior, but the essential context for use is provided.

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 100% with both agent_id and provider fully described in the schema. The description adds marginal value by matching 'Gmail or Outlook' to provider values, but it does not enrich parameter meanings 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 identifies the action ('Connect an agent to Gmail or Outlook'), the resource (agent), and the purpose (email tools). It also distinguishes from siblings by explicitly naming the email providers and related tools (read_emails, send_email, reply_email), making it unique among the connect_* siblings.

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 situational use by saying 'for email tools' and 'Enables the service_email builtin tool', giving clear context. It does not explicitly list exclusions or alternatives, but the sibling names (calendar, slack, etc.) make the choice obvious.

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 readOnlyHint annotation, the description discloses that the tool returns an interactive OAuth URL rather than directly performing the connection, and explains why (Slack requires interactive OAuth). This is significant behavioral context that the annotation alone does not provide.

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

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

Two concise sentences, the first front-loading the primary purpose, and the second adding essential clarification about the OAuth URL. Every sentence contributes 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 one-parameter tool with no output schema, the description sufficiently explains the return value (the OAuth URL) and the interactive authorization step, making the tool's behavior understandable.

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 covers 100% of the parameter, describing agent_id as 'The agent ID or name.' The description adds no additional meaning beyond this, so the baseline score of 3 applies.

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

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

The description specifies the action ('Connect an agent') and the target resource ('to Slack'), then clarifies the actual behavior by returning an OAuth install URL. This distinguishes it from sibling connect tools for other services.

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 clearly states this is for Slack connectivity, providing context for when to use it. However, it does not explicitly mention alternatives or exclusions, though sibling tool names imply them.

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=false and idempotentHint=true, covering basic safety and retry semantics. The description adds the authentication requirement (bot token) and clarifies the connection mechanism, but does not disclose potential side effects like overwriting existing connections.

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 two sentences, front-loaded with the primary action, and every word is purposeful. It is appropriately sized for a simple tool with only two parameters.

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 straightforward connection tool with no output schema, the description covers the essential purpose and prerequisite. It could mention whether the connection is idempotent or replaces existing ones, but the annotations and simple nature make it largely 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?

Schema description coverage is 100%, with both parameters (agent_id and bot_token) fully described. The description adds no new parameter meaning beyond what the schema provides; it merely reiterates the token requirement.

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 a specific action ('Connect an agent to Telegram') and identifies the resource (Telegram bot). It distinguishes from sibling tools like kopern_connect_slack and kopern_connect_whatsapp by naming the exact channel.

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 Telegram connections and provides a key prerequisite ('Requires a bot token from @BotFather'). It does not explicitly name alternatives or exclusions, but the tool name and sibling list make the context clear.

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 the tool as non-read-only and non-idempotent, consistent with the 'Create' action. The description adds useful context about the behavior (inbound receives POSTs, outbound sends events to URL) but does not mention prerequisites, return values, or error handling. It adds some value beyond annotations without being 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 exactly two sentences, front-loaded with the primary purpose, and contains no filler or redundant information. Every clause earns its place.

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 (6 params, 1 enum, no output schema), the description adequately covers high-level behavior and direction, plus compatibility context. It falls short of explaining return values or exact prerequisites, but the schema and annotations compensate for most structured information, making this reasonably 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?

The schema covers 100% of parameters with descriptions, so the description adds little beyond the schema. It does clarify the `type` parameter's direction and mentions compatible platforms for outbound webhooks, but does not provide additional syntax or usage details. Baseline of 3 is appropriate 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 'Create an inbound or outbound webhook for an agent' with specific verb (create) and resource (webhook). It distinguishes between inbound and outbound use cases, and the webhook-specific purpose is clear from the sibling context of other integration tools (email, slack, telegram, 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?

The description explains when each direction is appropriate ('Inbound: receive messages via HTTP POST', 'Outbound: send events to your URL'), and mentions popular integration platforms (n8n, Zapier, Make) as context. However, it does not explicitly list alternatives or when not to use this tool, leaving the guidance slightly implicit.

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 idempotentHint=true and readOnlyHint=false, so some behavioral context is already given. The description adds the credential requirement but does not disclose details such as whether an existing connection is overwritten, side effects like webhook setup, or what the return value indicates. Some value beyond annotations, but limited.

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?

Two sentences, front-loaded with the primary action, and no redundant information. Every word earns its place.

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 and full parameter descriptions, the tool is fairly complete. The idempotency annotation adds a useful safety signal. However, it lacks any mention of effects (e.g., notifications, webhook setup) or return values, which could matter for an integration tool. Still, for a simple connector, 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?

Schema descriptions cover 100% of parameters, so the baseline is 3. The description mentions credentials, which loosely aligns with access_token and phone_number_id, but does not offer any additional parameter-level 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 states a specific verb 'Connect' and a clear resource 'agent to WhatsApp Business', distinguishing it from sibling connect tools like Slack or Telegram. The purpose is immediately obvious.

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 clearly implies use for WhatsApp connectivity, but does not explicitly state when to choose this tool over alternatives like other connect tools. It mentions a prerequisite (Meta Cloud API credentials) but lacks comparative 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 include idempotentHint=true and readOnlyHint=false. The description adds the return of embed code, which is useful, but does not disclose side effects or prerequisites. Given annotations cover the safety profile, this is 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?

Two concise sentences with no filler. The first sentence states the action, the second the return value. Every word earns its place.

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?

Tool complexity is low with 4 parameters and no output schema. The description covers the main functionality but doesn't elaborate on optional parameter effects or return format details. Given output schema absence, slightly more detail could help, but it's sufficient for the scope.

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%, and all parameters have descriptions. The tool description adds no extra parameter detail, so it relies on the schema. Baseline 3 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 the action ('Enable the embeddable chat widget') and the specific resource ('for an agent'). It also mentions the output ('Returns the <script> embed code'), making it distinct from sibling tools like Slack or email connectors.

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 website embedding by mentioning 'your website'. While it doesn't explicitly exclude other connect tools, the widget-specific naming and website context provide clear usage guidance relative to siblings.

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 convey that this is a mutating (readOnlyHint=false) and non-idempotent (idempotentHint=false) operation. The description adds useful context by stating it returns the agentId, but does not disclose additional behaviors such as error handling or permission requirements, so it provides only modest added 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 a single, front-loaded sentence that states the action and the key return value. Every word earns its place; there is no waste 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 create tool with no output schema, the description covers the core function, key input types, and the return value (agentId). The parameter details are thoroughly documented in the schema, so the description is sufficiently complete for its complexity, though it could mention error or conflict behavior for full 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?

Schema description coverage is 100%, so the schema fully documents all eight parameters. The description mentions system prompt, model, and optional skills, which aligns with the schema but adds no extra semantic detail beyond what the schema already provides.

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 ('Create'), identifies the resource ('AI agent'), and names key attributes (system prompt, model, optional skills). This clearly distinguishes it from sibling tools like kopern_update_agent, kopern_get_agent, and kopern_delete_agent.

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 you want a new agent) but does not explicitly state when to use it over alternatives or provide exclusions. It's clear but lacks explicit when/when-not guidance.

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

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

Annotations declare readOnlyHint=false and idempotentHint=false, and description aligns as a create operation. However, description adds no extra side effects or behavioral details beyond the obvious 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?

Two sentences, no filler, front-loaded with the 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?

Covers core purpose and cases structure, but omits return value and any usage prerequisites. Since no output schema exists, some expectation of return info would help.

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?

All 4 params have schema descriptions (100% coverage), so description adds little new. It summarizes cases but the schema already documents each field.

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?

States 'Create a grading suite with test cases on an agent' – a specific verb+resource. Distinguishes from siblings like run_grading and get_grading_results 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?

No guidance on when to use vs alternatives. No mention of prerequisites or relationship to run_grading.

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 disclose readOnlyHint=false and idempotentHint=false, indicating a mutating, non-idempotent operation. The description adds the behavioral model of sequential step chaining and configurable input mapping, but does not mention other traits like permissions, side effects, or response behavior. With annotations covering safety, the added context is moderate but not extensive.

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 two short sentences, front-loaded with the action, and contains no redundant information. Every clause adds value: 'multi-step pipeline' conveys scope, 'on an agent' the target, and the second sentence explains step chaining and input mapping. It is an exemplary model of conciseness.

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 100% schema description coverage and annotations, the description covers the essential purpose. It does not explicitly mention that creating a pipeline does not execute it, nor what is returned, but these are inferable from the verb 'create' and the sibling run tool. The tool's complexity (multi-step, input mapping) is adequately introduced, though a bit more context on return or execution would improve 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?

Schema description coverage is 100%, so all parameters are already documented. The description's phrase 'configurable input mapping' highlights the input_mapping parameter, but this is already in the schema. It adds minimal semantic value beyond what the schema provides, so the baseline 3 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 uses the verb 'Create' with resource 'multi-step pipeline on an agent', which is specific and distinguishes from siblings like kopern_run_pipeline (execute) and kopern_create_agent (create a single agent). It further explains 'Steps chain agents sequentially with configurable input mapping', clearly scoping the tool's functionality.

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 that this tool is for creating pipelines, but it does not explicitly mention alternatives or exclusions. The distinction from kopern_run_pipeline is implied by the verb 'create' and the sibling name, but not stated explicitly. The context is unambiguous enough to justify a 4 rather than a 3.

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 context about collaboration modes (parallel, sequential, conditional) beyond the minimal annotations (readOnlyHint=false, idempotentHint=false). However, it does not disclose side effects, permissions, or return behavior, which are important for a creation tool.

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, concise sentence that front-loads the core action and includes relevant detail about execution modes without any fluff. It earns its place perfectly.

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 tool has no output schema, and the description fails to mention what the tool returns or how the created team can be referenced later. For a creation tool with moderate complexity and minimal annotations, this leaves significant gaps for an agent attempting to use the tool beyond just the initial create call.

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 fully documents all parameters. The description adds no extra meaning for parameters, only mentioning the execution modes which are already enumerated in the schema. Baseline 3 applies.

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 creates a multi-agent team, with a specific verb and resource. It distinguishes from sibling tools like create_agent and create_pipeline by focusing on multi-agent collaboration and execution modes.

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 creating a team of agents, but does not explicitly state when to use this versus alternatives or provide any exclusions. The mention of execution modes gives some context for customization, but no direct comparison to 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 already indicate destructive behavior, and the description adds specific context about what gets destroyed (skills, tools, grading suites, sessions, connectors). This goes beyond the generic destructive hint and gives the agent concrete information about the impact of the 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?

The description is a single, concise sentence that front-loads the action and resource, with a parenthetical list of affected data types. Every word earns its place and there is 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 delete tool with one required parameter, the description, schema, and annotations together provide complete information: what the tool does, what it destroys, and the required parameter. The lack of an output schema is acceptable for a delete 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 input schema fully documents the single parameter (agent_id) with a clear description. The tool description does not add any additional semantic detail beyond what the schema provides, so the baseline score of 3 applies.

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

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

The description clearly states the action (permanently delete) and the resource (agent), along with the scope of data affected (skills, tools, grading suites, sessions, connectors). This distinguishes it from sibling tools like get_agent, update_agent, or create_agent.

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 this tool is for permanent deletion but provides no explicit guidance on when to use it versus alternatives such as export_agent or update_agent. It does not mention prerequisites, fallback options, or cautionary notes, so it lacks clear exclusions or 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 annotations already indicate this is a non-read-only, non-idempotent operation. The description adds significant transparency by enumerating exactly what is created ('agent + skills + tools + grading suite'), which is beyond the annotations' simple safety classification. It does not, however, disclose potential side effects like overwriting or reversibility, but the added detail is valuable.

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 two sentences, front-loaded with the core function, and includes a practical usage pointer. Every sentence earns its place; there is no fluff or repetition of schema details.

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 complex tool that creates multiple resources, the description explains the action and the prerequisite for finding slugs. However, with no output schema, it fails to describe what the agent receives in response (e.g., IDs of created resources), and it does not mention any required permissions or error conditions. This is a meaningful gap for such a comprehensive 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 input schema covers both parameters with descriptions (100% coverage). The description enhances the slug parameter by telling the agent to use kopern_list_templates to see available slugs, which provides practical guidance on valid values. This adds meaning beyond the schema's basic type/description, justifying a score above the baseline of 3.

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 with a specific verb ('Deploy'), a clear resource ('an agent from a template'), and details the scope ('Creates agent + skills + tools + grading suite in one shot'). It also distinguishes itself from siblings like kopern_create_agent by emphasizing the all-in-one template-based deployment, and mentions the count of templates (28 general + 9 vertical) for added specificity.

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 gives clear usage context by indicating an all-in-one deployment ('in one shot') and provides a direct prerequisite ('Use kopern_list_templates to see available slugs'). However, it does not explicitly contrast with alternative tools like kopern_create_agent or state when one might prefer individual creation steps, so it lacks explicit 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 already declare readOnlyHint=true, so read-only is known. The description adds useful behavioral details: 'No LLM cost' and the specific scope of the exported JSON, going beyond what annotations provide.

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

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

The description is two concise sentences, front-loaded with the primary action and enriched with only essential details—the companion tool and cost note. Every word earns its place.

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, read-only export tool with one parameter and no output schema, the description covers the purpose, scope, companion import tool, and cost. No critical information 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?

Schema description coverage is 100% with the single agent_id parameter clearly described. The tool description does not add parameter-specific details beyond the schema, so the baseline score of 3 applies.

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

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

The description clearly states the tool exports an agent as a portable JSON object, listing the included components (config, skills, tools, extensions, grading suites). It distinctively uses the verb 'export' and differentiates from siblings like get_agent and import_agent.

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 points to kopern_import_agent as the counterpart for re-importing, and notes 'No LLM cost,' providing context on when this tool is appropriate. It does not explicitly exclude alternatives like get_agent, but the purpose is clear enough.

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, and the description aligns with a read-only fetch. The description adds valuable context by enumerating the return fields (system prompt, model, counts), which helps the agent anticipate the response shape. No contradictory behavior is disclosed, and the extra detail exceeds the annotation baseline.

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 that leads with the action and resource, then efficiently lists the return fields. Every word contributes value, and there is no redundancy or tangential 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?

Given the tool's simplicity—one parameter, read-only annotation, and no output schema—the description is complete. It effectively acts as return-value documentation by listing all included details, and the parameter is fully documented. Nothing material 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?

The input schema already provides 100% coverage by describing agent_id as 'The agent ID or name'. The description does not add any additional parameter semantics beyond what the schema offers, so the baseline score of 3 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 uses a specific verb ('Get') with a clear resource ('agent') and lists the exact details returned (system prompt, model, skills count, tools count, grading suites count). This clearly distinguishes it from siblings like list_agents (which likely returns summaries) and update_agent (which modifies).

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 phrase 'full details' implies this tool should be used when a complete agent snapshot is needed, suggesting the need to distinguish from list_agents. However, there is no explicit comparison to alternatives or stated when-not-to-use conditions. Usage is implied, not directly stated.

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?

Annotation readOnlyHint=true already declares a safe read operation. The description adds valuable behavioral context: 'No LLM cost' and the specific types of data returned (per-case scores, agent outputs, criteria evaluations, improvement notes), which goes beyond the annotation. No contradictions found.

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?

Two sentences with zero fluff. The first sentence front-loads the action and its result contents; the second adds a distinctive, useful note about cost. Every word earns its place.

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 output schema, the description adequately enumerates what the results contain. It also provides a behavioral note (no LLM cost) and implicitly ties to the run context via required parameters. This is complete for a retrieval tool with clear annotations and parameter schema.

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 baseline is 3. The description does not add semantic detail to the parameters themselves; it only references the run context. The schema's short descriptions ('The grading run ID', etc.) are adequate, and the description does not need to 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?

The description uses a specific verb 'Get' and resource 'detailed results of a grading run', listing concrete contents (per-case scores, agent outputs, criteria evaluations, improvement notes). It clearly distinguishes from sibling tools like kopern_list_grading_runs by emphasizing 'detailed' results while not being a listing or run-triggering 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?

The description clearly implies this tool is for retrieving detailed results after a grading run, which is distinct from listing runs or running grading. However, it does not explicitly name alternative tools or give when-not-to-use guidance, so it falls short of a 5.

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

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

The readOnlyHint annotation already declares a safe read operation. The description adds the 'No LLM cost' trait, which is useful for cost-aware tool selection, and lists the expected contents (message events, tool calls, metrics). 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 a single efficient sentence that front-loads the purpose and includes relevant details without any fluff. Every word earns its place.

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 output schema, the description clarifies the return contents (message events, tool calls, metrics) and notes the no-cost aspect. It is missing minor details like error behavior or authorization prerequisites, but for a simple read-only get tool, it is sufficiently 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?

The input schema already fully describes both parameters (agent_id and session_id) with 100% coverage. The description does not add parameter-specific meaning beyond what the schema provides, so the baseline of 3 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 the tool gets full session details including specific content types (message events, tool calls, metrics). This distinguishes it from sibling tools like kopern_list_sessions, which list sessions, and kopern_get_agent, which gets agent details.

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: use this tool when you need full details of a specific session rather than a summary or list. It provides clear context but does not explicitly mention alternatives or exclusions, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true, and the description adds context by specifying exactly what metrics are included and the notable exclusion of LLM cost. This goes beyond the annotation to set expectations about the data content, though it doesn't address rate limits or auth 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?

Three concise sentences front-load the purpose, then detail outputs, and end with a clarifying caveat. No redundant or filler content—every sentence earns its place.

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 read-only usage tool with two optional params and no output schema, the description sufficiently explains what data the user will receive. However, it could be more complete by clarifying how 'grading runs' factor into usage or how cost is calculated, though these are not critical 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 description coverage is 100% for both parameters (year_month and include_history), so the description doesn't need to repeat them. The description adds no extra detail beyond the schema, earning the baseline score of 3.

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 states a specific action ('Get token usage and cost metrics') and lists the concrete outputs (input/output tokens, cost, grading runs, per-agent breakdown). It clearly distinguishes this from sibling tools like grading result or session list tools by focusing on usage and cost 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 implies the tool is for accessing usage/cost metrics and clarifies it does not include LLM costs, providing context for when it's appropriate. However, it does not explicitly contrast with alternative tools or state when not to use it, so it falls short of a full 5.

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

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

Annotations already declare readOnlyHint and openWorldHint. The description adds key behavioral context beyond these hints: it uses the user's own API keys, applies six specific criteria types, and returns a 0-1 score. This alerts the agent to potential costs and side effects without contradicting the safe-read 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, front-loaded with the primary purpose. Each sentence earns its place: purpose, criteria types, return value and API key caveat. No repetition or filler.

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 output schema, the description appropriately discloses the score range and criteria list. It does not detail a complete response breakdown, but for a read-only inline grading tool with strong annotations and schema coverage, this is adequate. It could mention more about error handling or rate limits, but that is not essential.

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 for all four parameters, so the baseline is 3. The description mentions criteria types but does not add further parameter-level detail beyond what the schema already provides. It does not clarify relationships between test_cases structure and the listed criteria, leaving the schema to carry the full burden.

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 ('Grade') and resource ('system prompt against inline test cases') and enumerates six criteria types, clearly distinguishing this as an ad-hoc inline grader rather than the suite-based kopern_run_grading. The scope is clear and unambiguous.

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 phrase 'inline test cases' implies use for quick, ad-hoc evaluation, but the description does not explicitly name alternatives or provide when-not guidance (e.g., when to use kopern_run_grading or kopern_create_grading_suite). No exclusions are stated, so guidance remains implied rather than explicit.

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

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

Annotations indicate a write operation (readOnlyHint=false) and non-idempotent (idempotentHint=false). The description adds behavior beyond annotations: it creates a new agent with all associated components and states 'No LLM cost', which is useful operational context. There is no contradiction with annotations.

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

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

The description is two sentences, front-loaded with the action ('Import'), and every phrase adds value: what it imports, what it creates, and the cost implication. 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 single-param tool with a well-defined input, the description covers the purpose, scope, and a key side-effect (no LLM cost). It does not mention return values or failure modes, but given the simplicity and clear annotation of safety profile, it is adequately 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?

Schema description coverage is 100%, with the param 'data' described as 'The full Kopern agent export JSON (from kopern_export_agent)'. The description adds little beyond what the schema already provides, merely restating 'Kopern export JSON'. Since the schema fully documents the parameter, the baseline of 3 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 the verb 'Import' and the resource 'agent from a Kopern export JSON', and specifies it 'Creates a new agent with all skills, tools, extensions, and grading suites.' This distinguishes it from siblings like kopern_create_agent (which likely creates from scratch) and kopern_export_agent (the inverse operation).

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 you have a Kopern export JSON, and the schema adds 'from kopern_export_agent', making the context clear. It does not explicitly exclude alternatives like creating a new agent from scratch, so it falls short of a 5, but the intended use case is unambiguous.

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 readOnlyHint annotation already signals a safe read operation, and the description adds value by stating 'No LLM cost', which is a behavioral trait not covered by annotations. It also discloses the exact return fields, which is especially important given the lack of an output schema.

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 only two sentences long, front-loads the primary action and resource, and contains zero fluff. Every phrase—including the field list and cost note—contributes to comprehension.

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 parameterless list tool with readOnlyHint annotations and no output schema, the description adequately explains what the tool returns and its cost profile. It is complete for the tool's apparent complexity, and the sibling tool names make the listing-vs-get distinction inferable even without explicit guidance.

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 zero parameters and 100% schema coverage, the baseline is 4. The description adds contextual meaning by specifying 'your' agents, indicating an implicit ownership filter, and makes clear that no input is required. This provides sufficient semantic clarity beyond the empty 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 uses the specific verb 'List' with the resource 'all your Kopern agents', clearly distinguishing it from the singular get_agent tool. It also enumerates the returned fields (name, description, model, domain, grading score), leaving no ambiguity about the tool's purpose.

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 when to use the tool (to list all agents) and notes 'No LLM cost' as a selection benefit, but it does not explicitly state when not to use it or mention alternatives like get_agent for single-agent retrieval. Usage guidance is implicit rather than explicit.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful context beyond that: it discloses that the operation incurs no LLM cost and describes what information the tool returns (score history, pass rates, versions). This enriches the behavioral understanding without contradicting 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 two sentences, front-loaded with purpose. The first sentence states the core action, and the second adds valuable information (what is shown and cost) without any fluff. Every word earns its place.

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?

This is a simple list tool with two well-documented parameters and no output schema. The description adequately covers what the tool does and what it returns, and the readOnlyHint annotation covers safety. Nothing essential is missing for an agent to select and invoke this tool correctly.

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

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

Schema description coverage is 100%, with agent_id and suite_id both described. The tool description does not add any parameter-specific meaning beyond what the schema already provides, so the baseline score of 3 applies.

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

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

The description opens with a specific verb+resource: 'List grading runs for a suite,' and further clarifies the scope by mentioning score history, pass rates, and versions over time. This clearly distinguishes it from sibling tools like get_grading_results, which likely fetches specific results rather than listing runs.

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 – to list grading runs for a suite and review history. It does not explicitly name alternatives or exclusions, but the context is unambiguous, and the 'No LLM cost' note implies safe, cheap exploration, which effectively guides usage.

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 readOnlyHint annotation already covers the non-destructive nature, and the description adds 'No LLM cost' and enumerates the output fields (token usage, cost, timestamps), which is useful behavioral context beyond the annotation. It does not describe pagination or sorting, but that is not critical for a list tool.

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 two concise sentences, front-loaded with the main action and then adding the return value summary and cost note. Every word earns its place.

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 list tool with a readOnly annotation and fully documented parameters, the description covers the output contents (purpose, source, token usage, cost, timestamps) and the no-LLM-cost behavior, compensating for the lack of an output schema. It is complete enough for an agent to select and invoke it correctly.

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

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

Both parameters are fully described in the schema (agent_id and limit), so the description does not need to add parameter semantics. It adds no extra information about parameters beyond the schema, hence baseline score of 3.

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 ('List') and resource ('conversation sessions for an agent'), and specifies the returned fields (purpose, source, token usage, cost, timestamps). This clearly distinguishes it from sibling tools like kopern_get_session, which presumably returns a single session.

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 clearly indicates this tool is for listing sessions, implying it's the right choice when you need an overview of multiple sessions. However, it does not explicitly name alternatives or exclusion criteria, such as when to use kopern_get_session or kopern_get_usage instead.

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 readOnlyHint annotation already signals a safe read. The description adds 'No LLM cost' as a behavioral trait and returns field list, but does not discuss pagination, authentication, or error behavior. Still, for a simple list, this 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?

A single sentence that efficiently conveys action, scale, scope, return fields, and cost. No wasted words; front-loaded with the 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?

With only one optional parameter, readOnly annotation, and the description covering return fields, this is complete for an agent to invoke correctly. No output schema is needed because the description lists the fields.

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 already defines 'category' with enum values and default. The description enriches by specifying the template counts (28 general, 9 vertical), which clarifies the meaning of category selections without adding syntax 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 uses a specific verb ('List') and resource ('37 AI agent templates'), with explicit counts for general vs vertical categories, and lists return fields. This clearly distinguishes it from sibling tools like kopern_list_agents or kopern_list_sessions.

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 clearly states its purpose as listing templates and even notes 'No LLM cost' as an implicit advantage, but does not explicitly name alternatives or state when not to use. However, the 'List all' context and optional category filter make usage clear.

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 readOnlyHint: false, providing minimal safety disclosure, so the description must carry the burden of behavioral transparency. It does disclose that 'remember' saves a key-value pair, 'forget' deletes by key, and the tool has no LLM cost, which are useful traits. However, it omits details such as whether recall is exact or semantic search, whether memories are scoped by agent_id, or what happens on overwrite, leaving gaps for an agent to discover at runtime.

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 two sentences: an opening purpose statement and a compact list of actions with brief parenthetical definitions. Every word earns its place, with no redundant phrasing. The 'No LLM cost' note is a succinct additional benefit.

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 output schema, the description should at least hint at return values or data shapes, but it does not mention what recall or list return (e.g., a single value, a list, metadata). The parameter schema is rich and the actions are clear, so basic usage is possible, but the lack of return info and behavioral constraints (like persistence scope) leaves the description incomplete for a tool with only a readOnlyHint false annotation.

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 provides 100% coverage with descriptions for all six parameters, so the schema already conveys parameter semantics. The description adds minimal value beyond mapping actions to parameter names (key, query, value, category), which is implicit from the schema enums and descriptions. No further parameter explanation is necessary.

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: managing an agent's persistent memory, and enumerates four specific actions (remember, recall, forget, list) that map directly to the tool's capabilities. This distinguishes it from sibling tools, which focus on integrations and agent lifecycle, not memory. The 'No LLM cost' note adds a unique selling point.

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 implicit usage context by listing the actions available, making it clear when to use the tool (to store, search, delete, or enumerate memories for an agent). It does not explicitly name alternatives or exclusions, but no sibling tool offers similar memory management functionality, so the intended use case is clear. A slightly more explicit 'use when' statement would improve 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?

Beyond the annotations, the description explicitly discloses that the tool uses the user's API keys (cost implications), may take several minutes (time expectation), and mutates the system prompt (state-changing behavior). This is substantial context that helps the agent set expectations and assess 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?

The description is compact and front-loaded with the primary purpose, followed by the process, return value, and critical caveats. Each sentence adds unique information with no filler 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 complex tool with no output schema, the description effectively communicates the core behavior, side effects (API key usage, time), and return value. It could mention prerequisites like the agent and suite needing to exist, but these are implied by the parameter names and the optimization context.

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

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

Input schema covers 100% of parameters with clear descriptions, so the description does not need to elaborate. The schema already explains agent_id, suite_id, target_score, max_iterations, and max_token_budget. The description adds no additional semantic 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 states a specific verb ('Run AutoTune optimization') with a clear resource ('an agent'), and explains the iterative mutation process. It is distinct from siblings like run_grading or grade_prompt by focusing on automated optimization, not just grading.

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 when to use it (for optimizing an agent's prompt via AutoTune), but provides no explicit exclusions or comparisons to alternatives. It does not mention that run_grading or grade_prompt might be better for simple grading tasks, leaving the agent to infer the appropriate 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?

The annotations are minimal (readOnlyHint=false, openWorldHint=true), so the description adds meaningful context by disclosing that the tool executes test cases, evaluates, returns detailed scores, and 'Uses YOUR API keys'—an important external side-effect. It does not describe persistence or cost details, but it goes beyond the annotations without contradicting them.

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 two short sentences, front-loaded with the primary purpose, and every clause contributes meaning. It avoids redundancy with the schema and is easy to parse quickly.

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 two-parameter tool, the description covers the main action and return value ('detailed scores') and includes the key caveat about API key usage. It does not describe output structure, but since no output schema is present and siblings cover related retrieval, this is reasonably 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?

The schema already provides 100% coverage for both parameters with clear descriptions for agent_id and suite_id. The tool description does not add extra parameter-level semantics (e.g., formats, constraints, or usage patterns), so the baseline of 3 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 a specific action ('Run a grading suite') and target ('an agent'), and distinguishes itself from siblings like get_grading_results (retrieval) and create_grading_suite (creation). The phrase 'Executes all test cases, evaluates with configured criteria, returns detailed scores' nails the 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?

The description implies when to use the tool—when you need to execute a grading suite—but it does not explicitly contrast with alternatives such as kopern_get_grading_results for retrieving results or kopern_list_grading_runs for listing runs. It provides some context via 'Uses YOUR API keys' but lacks explicit when/when-not guidance.

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

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true), the description adds useful behavioral context by disclosing that steps run sequentially and that the tool consumes the caller's API keys. This clarifies that it makes external calls and may incur costs, which is valuable even with annotations present. It does not cover everything (e.g., return value, session creation) but adds meaningful 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?

The description is three concise sentences, front-loaded with the primary action, followed by the execution model and a key warning. Every sentence adds value with no unnecessary 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?

While the tool has only 3 parameters and helpful annotations, it lacks an output schema, and the description does not explain what the tool returns or how to retrieve results. The sequential execution and API key usage are explained, but the missing return-value information leaves a gap for the agent. Sibling tools like get_session hint at the outcome, but the description itself is incomplete.

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 100%, with each parameter having a basic description. The tool description does not add significant semantics beyond what the schema already provides—it mentions 'prompt' as the input, but doesn't elaborate on how agent_id or pipeline_id are used. The baseline score of 3 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 what the tool does: 'Execute a pipeline on a prompt.' It uses a specific verb and resource, and explains the sequential feeding behavior. This distinguishes it from sibling tools like kopern_create_pipeline or kopern_run_autoresearch by focusing on executing an existing pipeline on a prompt.

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 this tool is for running existing pipelines on prompts, which is clear from the name and first sentence, but it doesn't explicitly state when to use this over alternatives or mention any exclusions. The note about 'Uses YOUR API keys' provides a hint about prerequisites but not a full usage guide.

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=false and openWorldHint=true. The description adds 'Uses YOUR API keys', which is a useful behavioral caveat (cost/security). However, it does not disclose other potential side effects or execution semantics beyond returning outputs, so it provides only partial 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?

Two concise sentences, front-loaded with the primary action and outcome. No redundant wording or filler.

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?

There is no output schema, so the description correctly explains return values. It mentions API key usage. However, it omits prerequisites (e.g., team must be created first), error conditions, and any potential side effects, leaving gaps for a multi-agent execution 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 is 100% with both parameters described ('prompt' and 'team_id'). The description does not add extra meaning beyond what the schema provides—it simply mentions a 'prompt' implicitly. Baseline 3 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 the verb 'Execute' and the resource 'multi-agent team on a prompt'. It also specifies the output: each agent's output and final combined result. This distinguishes it from siblings like kopern_run_pipeline and kopern_run_autoresearch.

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 such as kopern_run_pipeline or kopern_create_team. It lacks any when-to-use or when-not-to-use context, prerequisites like 'team must exist', 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 already declare readOnlyHint=false and idempotentHint=true, so the description need not restate those. It adds useful context by telling users to use add/remove arrays for granular subcollection control, implying that arrays are additive/removal rather than direct replacement. However, it does not explain idempotency or detail partial-update behavior beyond that.

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 two sentences, front-loaded with the main purpose, and every word adds value. It avoids restating schema fields and quickly communicates both scope and a key usage pattern.

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 complexity of 14 parameters across multiple subcollections, the description does a good job of summarizing the tool's scope and the add/remove pattern. The schema handles individual parameter details, so the description does not need to list them. It could mention that only provided fields are updated, but the schema and idempotentHint cover most context.

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

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

The schema has 100% description coverage for all 14 parameters, so the schema already provides parameter meaning. The description adds minimal semantic value beyond grouping parameters into categories (config, skills, tools, extensions) and mentioning the add/remove pattern. This matches 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 tool's function: 'Update any part of an agent: config, skills, tools, or extensions.' It uses a specific verb and resource, and the enumeration of updateable areas distinguishes it from sibling tools like create_agent or delete_agent.

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 establishes that this tool is for updating existing agents and covers config, skills, tools, and extensions. It does not explicitly mention alternatives like create or delete, but the clear scope and sibling tool names provide enough context. The instruction to 'Use add/remove arrays for granular control' offers practical guidance for subcollections.

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