Axint

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

The description discloses key behaviors: reads local context and may refresh advice artifacts, and states there is no network usage. Since annotations provide no read-only or idempotent hints, this transparency 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 very concise: two main sentences plus short 'Use' and 'Effects' notes. No redundant information, and the primary purpose is immediately 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?

The description covers the tool's inputs, reading behavior, and output adaptation. With an output schema present, return values do not need explanation. Minor gap: no mention of error cases or prerequisites, but overall sufficient.

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

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

Schema coverage is 100%, so baseline is 3. The description adds some context about parameter usage (e.g., agent lane adaptation), but does not substantially extend beyond schema descriptions.

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

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

The description clearly states the tool's function: asking the local Axint project brain for next-step guidance, reading multiple context sources, and returning host-specific advice. This distinguishes it from sibling tools like axint.agent.claim or axint.agent.install.

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 includes a 'Use' section that specifies when to use this tool: 'when multiple tools or agents need the next safest move from local proof.' It does not explicitly mention alternatives, but the context 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 provide readOnlyHint=false and destructiveHint=false. The description adds transparency by stating 'Effects: writes local coordination claims under .axint/coordination; no network.' and explaining claims are short-lived. This goes beyond annotations, though it could mention if claims can be overwritten or conflict behavior.

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

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

The description is concise with four short sentences. It is front-loaded with purpose, then context, usage, and effects. No redundant or unnecessary 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 complexity (6 params, 1 required) and that an output schema exists (though not shown), the description covers core behavioral aspects. However, it lacks mention of return values or error scenarios. Overall adequate for a coordination 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%, so baseline is 3. The description does not add significant meaning beyond the schema's parameter descriptions. It emphasizes the 'files' parameter through the main purpose, but other parameters like 'cwd', 'task', 'agent', 'format', 'ttlMinutes' are not elaborated further.

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

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

The description clearly states the tool's purpose: 'Claim files before an agent edits them so other agents do not patch the same SwiftUI/App files concurrently.' It uses a specific verb (claim) and resource (files), and distinguishes from the sibling tool 'axint.agent.release' which is mentioned.

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 explicit usage guidance: 'Use: use before editing shared files in parallel-agent work; release claims when done.' It specifies when to use (before editing in parallel work) and implies when not to use (if not parallel), and even mentions the release action.

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

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

Annotations already provide idempotentHint=true and destructiveHint=false. The description adds valuable behavioral details: it writes specific files (.axint/agent.json, etc.) and confirms no network activity, which is beyond what annotations convey. No contradictions with annotations.

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

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

The description is concise (four sentences) and front-loads the core purpose. Every sentence adds value: purpose, use case, effects. No extraneous information.

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

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

Given that an output schema exists (though not shown), the description adequately covers purpose, usage, effects, and constraints. It provides sufficient context for an install tool with clear side effects.

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%, and the parameter descriptions in the schema are already clear. The tool description does not add additional parameter-level context beyond what the schema provides, so a 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 starts with a specific verb-resource pair ('Install the local Axint multi-agent project brain') and lists concrete files written. It distinguishes itself from sibling tools by explicitly stating it's for one-time project setup, not for one-off compile, and mentions multi-agent coordination, which sets it apart from tools like axint.compile or axint.run.

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

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

The description states when to use ('use once per project to create local multi-agent coordination') and when not ('not needed for one-off compile'). This gives clear usage context, though it could be more explicit about what to use instead for one-off tasks.

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 idempotentHint=true and destructiveHint=false, but the description adds valuable behavioral context: it updates local coordination claims under .axint/coordination, makes no network calls, and explains the effect on other agents (prevents blocking). This 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 three sentences with no wasted words. The first sentence states the core action and resource, the second explains the why, and the third gives usage and effects. Key information is front-loaded and easy to parse.

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 5-parameter schema with 100% coverage and an output schema (though not shown), the description is sufficiently complete. It covers purpose, usage, and effects. Minor omission: it does not mention the output format or default behavior when no claims exist, but the output schema likely handles that.

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%, so baseline is 3. The description does not add parameter-specific details beyond what the schema already provides (e.g., 'all', 'cwd', 'agent', 'files', 'format' are all described in the schema). No extra semantic information is given.

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 releases active local Axint file claims after finishing or abandoning a task, which directly distinguishes it from sibling tools like axint.agent.claim. It also explains the reason (preventing blocking) and the resource (claims under .axint/coordination).

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

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

The description explicitly says 'Use: use after finishing or abandoning claimed files so other agents are unblocked,' providing clear when-to-use guidance. It does not mention when not to use or explicitly name alternative tools, but the context implies axint.agent.claim as the counterpart.

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

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

Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that the tool is read-only, may use a configured Cloud Check endpoint, and no source is sent unless provided. This aligns with annotations and adds a bit of context, but doesn't disclose rate limits or auth requirements. No contradiction.

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

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

The description is several sentences long, starting with the main action and then listing parameters and usage. It is adequately structured but contains some vague phrasing ('next...' and a trailing colon). Could be more concise without losing clarity.

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

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

Given the tool has 15 optional parameters, no required, annotations, and an output schema, the description covers the core purpose and usage. It mentions key parameter pairs like actualBehavior/expectedBehavior. However, the incomplete ending ('next...') and lack of mention of return type (covered by output schema) hold it back from a 4.

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 15 parameters. The tool description only provides a high-level summary (accepts inline source or sourcePath) but doesn't add significant meaning beyond what the schema already provides. 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 runs a Cloud Check against Swift or Axint TypeScript source and returns a verdict and findings. It specifies the input (inline source or sourcePath) and output (Cloud-style verdict, Apple-specific findings). However, it does not explicitly differentiate from siblings like axint.swift.validate or axint.compile, so it's slightly less than a 5.

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 includes 'Use: use for Apple-aware source review and repair prompts; provide evidence for UI/runtime claims.' This gives context for when to use. It also notes effects: read-only, uses endpoint, no source sent unless provided. However, it lacks explicit comparisons to alternatives or when not to use, so it's adequate but not excellent.

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, idempotentHint=true, destructiveHint=false. The description adds valuable context: returns a string with specific fields (swift, infoPlist?, entitlements?), no files written, no network requests, and diagnostics on failure. This goes beyond annotations without contradiction.

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

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

The description is two concise sentences: first defines purpose and output, second gives usage guidelines and effects. All information is front-loaded, no wasted words.

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

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

Given the complexity (compilation with multiple parameters, output schema exists), the description covers input format, output structure and side effects, usage context, and failure behavior. It is complete for safe and correct invocation.

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

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

Schema description coverage is 100% (all 5 parameters have descriptions). The tool description does not add significant extra meaning beyond the schema, only providing a general summary. Baseline is 3 as per rubric.

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 'Compile TypeScript source into native Swift App Intent code,' specifying the verb, resource, and output. It distinguishes from siblings like 'axint.validate' (cheaper preflight) and 'axint.project.pack' (packing), providing clear differentiation.

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

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

Explicit guidance: 'Use when TypeScript DSL source should become Swift; use validate for cheaper preflight only.' This directly tells when to use the tool and when not to, with a named alternative. It also sets expectations about side effects (no files written, no network requests).

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?

Description adds details beyond annotations: 'read-only generated docs context; writes no files and uses no network,' confirming and expanding on readOnlyHint and destructiveHint.

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 sentences, front-loaded with purpose and use case. No redundant words, every sentence adds value.

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

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

Given simple tool, optional parameters, and existence of output schema, description sufficiently covers purpose, usage, and behavioral effects.

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 descriptions for each parameter. Description does not add any additional meaning or usage context for parameters, so 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?

Description clearly states it returns project-local Axint docs context for reloading after compaction. Could explicitly differentiate from sibling 'axint.context.memory' but still specific enough.

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?

Explicit use case provided: 'use after compaction when the agent needs workflow docs without rereading the whole site.' Does not mention when not to use or alternatives like 'axint.context.memory'.

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 destructiveHint=false. The description adds context: 'read-only generated context; writes no files and uses no network', confirming the behavior and adding no contradictions. It is transparent about what the tool does not do.

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

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

The description is concise with three sentences: the first describes the tool, the second states its purpose, and the third gives usage guidelines. It is front-loaded with key information. Minor redundancy in phrasing ('Use: use') does not detract significantly.

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 that an output schema exists (as per context signals), the description does not need to explain return values. It adequately covers when to use and what it does (compact operating memory). It is complete for a simple read-only tool.

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

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

The schema has 100% coverage, so the baseline is 3. The description does not add any parameter-specific semantics beyond what the schema provides. It mentions platform, projectName, and expectedVersion only in the schema, not in the description.

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

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

The description clearly states the tool returns compact Axint operating memory, specifying the verb 'Return' and the resource. It distinguishes itself from sibling like axint.context.docs by emphasizing compactness and specific usage scenarios (new chat start, compaction, long coding drift).

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

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

The description explicitly says when to use the tool ('after compaction or session restart when the agent needs compact operating rules') and implies the alternative of reading full docs. It provides clear context but does not explicitly mention when not to use it.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds 'read-only inspection; writes no files; no auth or network required', providing valuable behavioral details beyond annotations. No contradiction.

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

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

Two concise sentences plus a short effects line. Front-loaded with core purpose. Every sentence adds value; no fluff.

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

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

Covers purpose, usage context, effects, and what it inspects. Output schema exists, so return values are handled. All key aspects are addressed for a read-only diagnostic 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 good parameter descriptions. The description does not add significant meaning for individual parameters beyond the schema, so baseline 3 is appropriate.

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

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

The description starts with 'Audit the current Axint runtime and project wiring' and lists specific items like MCP version, paths, config files, and Xcode registration. It clearly distinguishes from siblings (e.g., axint.status, axint.validate) by focusing on inspection of wiring and configs.

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?

Explicit guidance: 'Use: call when MCP wiring, package paths, Xcode setup, or project memory may be stale.' It provides clear context but does not mention alternatives among sibling tools.

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

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

Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds 'read-only generated output; writes no files and uses no network', reinforcing and adding specific behavioral traits. 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?

Description is front-loaded with the key action, followed by 'Use:' and 'Effects:' sections. It is moderately concise but could be slightly shorter without losing clarity. Every sentence adds value.

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

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

Given the complexity (11 params, nested objects, output schema), the description covers purpose, behavior, and generated files adequately. With output schema present, return value details are not needed. Could mention how parameters interact more, but 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?

Schema description coverage is 100%, so baseline is 3. Description adds overall context but does not detail individual parameters beyond what's in schema. 'name' is inferred from description, which is hinted, but not significantly more.

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 generates a scaffolded Apple-native feature package, specifying multiple file types. It distinguishes from repair tools by saying 'not for repairing existing app bugs', and the sibling tools include axint.scaffold, but the description focuses on Apple-native surfaces.

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

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

Explicitly says 'Use: use for new Apple-native surfaces; not for repairing existing app bugs', giving clear when-to-use and when-not. Mentions read-only, no writes, no network. However, it does not explicitly compare with sibling tools like axint.scaffold or axint.compile.

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

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

With annotations providing no hints, the description fully bears the burden. It discloses that the tool writes or reads packets, never includes source by default, and creates redacted files, giving good transparency about 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 functional but includes a truncated 'Users...' fragment that harms conciseness. It could be streamlined.

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 complexity (16 optional params, output schema exists), the description covers purpose, usage, and effects adequately. It lacks some edge cases but is sufficient.

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

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

Schema coverage is 100%, so the description does not need to add parameter details. It adds no extra meaning 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 clearly states the tool creates or reads privacy-safe learning packets and lists their contents and exclusions. However, it does not explicitly differentiate this tool from siblings like axint.fix-packet.

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 includes explicit 'Use:' guidance for when to use (weak Axint output) and what not to use (sending source), providing clear context.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds 'read-only local artifact read; writes no files and uses no network', which aligns with annotations and provides extra context (local, no network). No contradictions.

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

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

The description is concise (3-4 sentences), front-loaded with the core purpose, and structured with 'Use:' and 'Effects:' sections. Every sentence provides value without redundancy.

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

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

The description covers purpose, usage context, effects (read-only, no network), and output content (verdict, findings, diagnostics, next steps, fix prompt). Given the presence of an output schema, it does not need to detail return values. Complete for a read-only 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%, and each parameter already has a description in the input schema. The tool description does not add new information about parameters; it focuses on the output and usage. Thus 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 'Read the latest Fix Packet that Axint emitted locally after a compile or watch run', specifying the verb (read), resource (fix packet), and context (latest local artifact). It distinguishes from sibling tools like axint.compile or axint.repair by noting it's 'not a new analysis pass' and for consumption by AI/Xcode helpers.

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

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

The description explicitly says 'Use: use after a local compile/watch/check emitted a packet; not a new analysis pass', providing clear when-to-use and when-not-to-use guidance. It also implies the tool is for reading repair artifacts, differentiating it from other tools that perform analysis or fixes.

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 idempotentHint=true, destructiveHint=false. Description adds context: 'writes .axint/context' (write operation), 'reads local project files only' (scope), and dryRun behavior. Adds value beyond annotations without contradiction.

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

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

Three sentences: purpose, usage, effects. Front-loaded and concise. 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?

Good context for a tool with 6 parameters and output schema. Explains when to use and what it does. Could mention how the context pack is used later (e.g., by axint.agent.* tools) but not necessary.

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 clear descriptions. Description adds minimal extra meaning beyond 'dryRun=true' and 'reads local project files'. Baseline 3 is appropriate as schema does the heavy lifting.

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

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

Clear verb+resource: 'Scan the local Apple project and write a compact .axint/context pack'. Distinguishes from siblings like axint.project.pack and axint.compile by mentioning specific purposes (changed files, SwiftUI surfaces, interaction-risk files). However, no explicit sibling differentiation, so a 4.

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?

Explicit when-to-use: 'Use: use before project-aware repair, multi-file SwiftUI work, or interaction-risk analysis.' Also notes effects and dryRun flag. No mention of when not to use, but the positive guidance is strong.

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, destructiveHint=false, and idempotentHint=true. The description adds no file writes and no network use, which reinforces the read-only, idempotent nature and provides additional assurance.

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 relatively concise and includes a 'Use:' section for clarity. However, it has an incomplete sentence: 'install the...' which harms conciseness and completeness.

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

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

Given the presence of an output schema, the description adequately covers purpose, usage, and effects. It lists the returned files and states no side effects. Could mention it does not modify the project.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description does not add extra meaning or context beyond what the schema provides, earning a baseline 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 generates a project-start pack for a new Apple app, listing the specific files returned. It distinguishes from siblings by specifying it is for bootstrapping, not inspecting an existing project.

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 states when to use (bootstrap a new Apple project) and when not to use (not to inspect existing project). It also notes no file writing or network use. Lacks explicit alternatives among 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?

Beyond annotations (idempotentHint=true, destructiveHint=false), the description adds valuable context: updates specific files (.axint/project.json, AGENTS.md, etc.), dryRun behavior, and no network activity. 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 somewhat redundant ('Use: use after...') but still efficient. Two sentences cover purpose, usage, and effects. Could be slightly tighter, but acceptable.

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 output schema exists, the description covers all necessary aspects: when to use, what it does, effects, and dryRun behavior. No missing key information.

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 documented. The description adds minimal value beyond schema (e.g., mentions dryRun effect and version default), 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 it updates version hints after upgrades, specifying the verb 'Update' and the resource (project-pack version hints). It lists affected files and distinguishes itself from sibling tools like axint.upgrade.

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 states when to use: 'after axint.upgrade or npm/pip upgrades'. It provides clear context and repeats guidance but does not explicitly mention when not to use or list alternatives. Still, it is clear enough for an agent.

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

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

Annotations already indicate read-only, idempotent, non-destructive. Description adds specific context: local registry search via AXINT_REGISTRY_PATH or sibling checkout, and no network by default.

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

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

Description is concise with three sentences covering purpose, usage, and effects. Front-loaded with key information, no wasted words.

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

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

Given the tool has 5 parameters and an output schema, the description provides sufficient context for use, including when and how it works. Could mention output but schema covers that.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description does not add extra semantics for parameters, so 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 the tool searches the Axint Registry for published packages using natural-language queries, and it distinguishes itself by advising use before axint.feature or axint.compile.

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

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

Explicitly states when to use (before generating code to find reusable packages) and when not to use (not for validating local Swift), and implies alternatives like axint.feature or axint.compile.

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?

Describes that it reads local files and writes artifacts to .axint/repair and .axint/feedback. Annotations show readOnlyHint=false and destructiveHint=false, and the description aligns, adding context about the artifacts without contradiction.

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

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

Structured with summary, Use, and Effects sections, but truncated ending ('returns a...') is a flaw that reduces completeness and conciseness. Sentences are generally efficient.

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

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

Given 17 parameters and many sibling tools, the description covers the tool's main behaviors, evidence types, and outputs. Lacks explicit return value explanation, but output schema exists. Truncation is a minor gap.

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%, so baseline is 3. The description adds minimal extra meaning beyond schema (e.g., mentions Cloud Check when source is provided). Does not significantly enhance parameter understanding.

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

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

Clearly states it plans project-aware repairs for existing apps, distinct from greenfield generation. However, it is truncated ('returns a...') and does not explicitly differentiate from sibling repair tools like axint.swift.fix or axint.xcode.write.

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

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

Includes explicit 'Use:' section stating it is for existing app bugs with evidence, and explicitly excludes greenfield generation. Does not mention alternatives among siblings, but the guidance is clear and actionable.

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?

Describes effects: starts child processes, writes artifacts, may run xcodebuild/tests, may call Cloud Check. Annotations (readOnlyHint=false, destructiveHint=false) are consistent. Additional behavioral context beyond annotations is provided.

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?

Moderately sized, front-loaded with purpose, clear 'Use' and 'Effects' sections. Could be slightly more concise but not excessively verbose.

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 (27 params, output schema exists, annotations present), the description covers key aspects: what it does, when to use, side effects. Does not explain output schema, but that is available separately.

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 detailed descriptions; baseline is 3. The description does not add significant per-parameter meaning beyond the schema, but the overall context of the tool's workflow is given.

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

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

Description clearly states the tool runs the Axint Apple build loop outside Xcode UI, listing steps: validates Swift, runs Cloud Check, executes xcodebuild build/test. It implies a combined workflow but doesn't explicitly differentiate from sibling tools like axint.swift.validate or axint.cloud.check.

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

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

Provides explicit use condition: 'use when the agent must prove Swift validation, Cloud Check, Xcode build/test, and runtime evidence.' Does not list when to avoid or mention alternatives for specific subtasks.

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 destructiveHint=true; description adds 'kills active child process groups' and 'no network' side effects, providing extra behavioral detail beyond annotations.

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

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

Concise at two sentences plus use/effects lines. Minor redundancy between 'Use this when' and 'Use:' section. Overall efficient and 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?

Covers purpose, usage, effects, and when to use. Lacks error handling details (e.g., no active run), but output schema exists for return values. Adequately complete given tool complexity.

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

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

Schema covers 100% of parameters with descriptions; description does not add substantial extra meaning beyond the schema. 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?

Clear verb 'Cancel', specific resource 'Axint run', and detailed mechanism 'by killing active child process groups'. Distinguishes from siblings like axint.run and axint.run.status.

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

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

Explicit when-to-use scenarios: 'when xcodebuild or a UI-test runner survived an MCP timeout or transport close' and 'use only to stop an active Axint run or stuck child process group'. No explicit exclusions but context is 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?

Adds details beyond annotations: 'read-only local run/job inspection', 'writes no files and uses no network'. No contradiction with annotations (readOnlyHint, idempotentHint, destructiveHint). Thorough disclosure.

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. First sentence states core purpose; second sentence provides usage context. Efficient and 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?

Covers full complexity: 3 optional params fully described, output schema present, behavioral effects stated, and usage context given. No missing information.

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 100%, so baseline 3. Description does not add parameter-specific meaning beyond defaults and enum, which are already in schema. Adequate but not enhanced.

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

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

Description states 'Read the latest or selected Axint run job record, including active child process IDs.' Clearly identifies verb (read), resource (job record), and scope. Distinguishes from siblings like axint.run and axint.run.cancel.

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

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

Explicitly advises use when long xcodebuild run may be active after MCP timeout or disconnect. Provides clear scenario and alternative avoidance of guessing. Directly answers when-to-use.

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

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

Discloses key behaviors: no files written, no network requests, returns error on invalid domain values. Annotations (readOnlyHint, idempotentHint, destructiveHint) are consistent with description, no contradictions.

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

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

Extremely concise: two sentences plus brief 'Use:' and 'Effects:' lines. Front-loaded with purpose, no unnecessary words.

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

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

With annotations, schema, and output schema present, the description covers purpose, usage, effects, and error handling completely. No missing 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?

Schema coverage is 100%, so schema already describes parameters. Description adds little beyond naming conventions (PascalCase) and domain validation hint, but not enough to raise above baseline.

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 generates a starter TypeScript intent file from a name and description, returning a string ready to save as .ts. It distinguishes from siblings by focusing on scaffolding small starters, while siblings like axint.templates.get provide richer examples.

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

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

Explicitly says 'use to create a small TypeScript intent starter; use templates for richer examples,' guiding when to use this vs. alternative tools. Could be more specific about when not to use, but it's 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?

Description adds beyond annotations: 'read-only Swift generation; writes no files and uses no network' and token-light aspect. Annotations already declare readOnlyHint, idempotentHint, destructiveHint; description reinforces and adds concrete behavior.

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

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

Two sentences plus Use/Effects sections. Every sentence earns its place. Front-loaded with purpose. Minimal waste.

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 complexity (18 params, conditional requirements), description plus schema provide complete understanding. Output schema exists. Overview sufficient to use tool effectively without deep schema dive.

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%, so baseline 3. Description provides high-level grouping (type determines relevant parameters) but no new details beyond schema. Does not add much value beyond what schema already states.

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

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

Clearly states it compiles minimal JSON schema to Swift, bypassing TypeScript DSL. Mentions supported types via 'type' parameter and distinguishes from axint.compile sibling.

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

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

Explicitly provides when to use ('token-light JSON-to-Swift generation') and when to use alternative ('use compile for full TypeScript DSL control'). Also notes read-only, no files/network effects.

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 are all false, providing minimal guidance. Description compensates by detailing side effects: writes .axint/session/current.json, refreshes .axint/AXINT_REHYDRATE.md, and notes no auth or network required. This adds valuable behavioral context beyond annotations.

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

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

The description is three sentences, front-loaded with the primary action. Each sentence serves a purpose: stating the action, listing effects, and giving usage guidance. No fluff 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?

Covers purpose, when to use, effects, and return structure. Output schema exists, so return details are not required. Complete for a session-start tool with basic parameters and good annotations coverage.

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 7 parameters have descriptions in the schema (100% coverage). The description does not add extra meaning or usage details for any parameter beyond what the schema already provides, so it meets the baseline but adds no incremental value.

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 'Start an enforced Axint agent session' with specific verb and resource. It lists exact effects and distinguishes from siblings like 'axint.run' or 'axint.workflow.check' by focusing on session initialization.

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

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

Explicitly says 'call at the start of a tool-enabled agent session or after context compaction', providing clear context for when to use. No explicit when-not-to or alternatives, but the tool's narrow scope makes this acceptable.

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?

Description states it is read-only, writes no files, requires no auth or network, matching annotations. It adds context about providing reload/update instructions, which is beyond annotations but not contradictory.

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

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

Description is well-structured: purpose sentence, usage instructions, then effects. It is not overly verbose but could be slightly trimmed. Still concise and informative.

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 presence of output schema and annotations covering safety, the description provides sufficient context for the agent to understand the tool's function and when to use it. No gaps identified.

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

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

Only one optional parameter 'format' with full schema documentation (enum with descriptions). Description does not add additional meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the tool reports server version, package path, uptime, tool count, and reload/update instructions. It distinguishes itself from siblings by specifying it is not an npm/PyPI lookup and should be used to verify the connected server version.

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

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

Explicitly says to use as first tool in a new agent chat or after an MCP reload, and advises against using as a package lookup. This provides clear when-to-use and when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable context: 'local mode is read-only; Pro mode may call Axint endpoint when credentials are configured.' It also clarifies that domain is a weak hint. However, it could mention more about potential state changes or rate limits, hence a 4.

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

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

The description is well-structured with three clear sections: what it does, use cases, and effects. It is concise but could be slightly trimmed. Every sentence adds value, and it's front-loaded with the core purpose.

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

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

Given the tool complexity (10 parameters, 1 required) and the presence of an output schema, the description covers essential context: it explains the primary use case, mode differences, and that results are a ranked list. It is complete enough for an AI agent to select and invoke 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%, so baseline is 3. The description adds minimal extra meaning beyond the schema, primarily noting that domain is a weak hint and that appDescription wins. No significant elaboration on individual parameters is needed since the schema already describes them adequately.

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

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

The description clearly states the tool's purpose: 'Suggest Apple-native features for an app based on its description.' It specifies the verb (suggest), resource (Apple-native features), and input (app description). It also distinguishes from siblings by noting it is not a substitute for registry search.

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?

Explicit guidance: 'Use: use before generation to choose Apple surfaces; not a substitute for registry search or validation.' This tells when to use and when not to, and mentions mode effects, providing clear context for the AI agent.

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=true, destructiveHint=false, idempotentHint=true), the description adds that the tool produces 'read-only fixed-source output, writes no files, and uses no network,' giving concrete behavioral details consistent with annotations.

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

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

The description is concise with two main sentences plus structured 'Use:' and 'Effects:' sections. Every part adds value, though it could be slightly more organized.

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

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

Given the presence of an output schema and annotations, the description covers the tool's purpose, usage context, effects, and examples. It doesn't mention error handling or edge cases, but these are partially covered by the output schema and the association with swift.validate.

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%, so the schema already documents the three parameters. The description does not add extra meaning for parameters beyond listing fix rules, which indirectly hints at source input but doesn't detail format or file.

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 auto-fixes mechanical Swift errors detected by axint.swift.validate, listing specific fix rules like rewriting @State let to @State var and injecting perform(). This distinguishes it from sibling tools like axint.validate and axint.repair by explicitly tying it to validation.

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

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

Provides explicit usage guidance: 'use after swift.validate when errors are mechanical; inspect remaining diagnostics manually.' It tells when to use and what to do after, although it does not name alternative tools for non-mechanical errors.

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 read-only and non-destructive. Description adds concrete behavioral details: 'read-only Swift diagnostics; writes no files and uses no network.' 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?

Concise three-sentence structure: scope, examples, usage/effects. Every sentence adds value without redundancy.

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

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

Given 2 parameters, existing annotations, and output schema, description covers purpose, usage, and behavioral effects sufficiently. No gaps.

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

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

Schema covers both parameters fully (100% coverage). Description does not add extra meaning beyond what schema already states, so 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?

Clearly states 'Validate existing Swift source against 150 build-time rules (AX700–AX749)' including specific examples like Swift 6 concurrency and Live Activities. Distinguishes from sibling axint.swift.fix by mentioning pairing for mechanical repairs.

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

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

Explicitly recommends using on 'generated or edited Swift before build' and to 'pair with swift.fix for mechanical repairs.' Provides clear context but lacks explicit when-not alternatives.

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

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

Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint. The description adds specifics: 'read-only template source; writes no files and uses no network,' providing valuable behavioral context beyond annotations.

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

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

The description is concise with two main sentences and separate 'Use' and 'Effects' sections. However, there is a trailing ellipsis after 'parameter definitions, and...' indicating potentially incomplete information, slightly reducing 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 an output schema (not shown but mentioned), the description explains the return value as 'a complete, compilable defineIntent() file as a string.' Combined with annotations and the single parameter, the description provides comprehensive context for effective tool usage.

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

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

The tool has one parameter (id) with 100% schema description coverage, so the schema already documents it fully. The tool description does not add additional parameter details beyond what the schema provides, resulting in a 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 clearly states 'Retrieve the full TypeScript source code of a specific bundled template by id,' with a specific verb and resource. It distinguishes from sibling tools like axint.templates.list (listing) and axint.compile (compiling).

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 includes 'Use: use to fetch a complete reference template; edit before compiling into an app,' providing clear context for when to use the tool. It does not explicitly mention alternatives or when not to use, but the usage guidance is sufficient.

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

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

Discloses read-only nature, no file writes, and no network usage, adding context beyond annotations (which already indicate readOnlyHint and idempotentHint).

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 plus a usage line; concise, front-loaded, and no superfluous text.

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?

Fully describes purpose, output format, usage context, and behavioral effects; no output schema needed beyond description.

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

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

No parameters exist; baseline is 4. Description adds no parameter info but is not needed.

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 lists all 26 bundled reference templates in the Axint SDK, distinguishing it from siblings like templates.get which retrieves a single template.

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

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

Explicitly states 'Use: use to discover valid template ids before templates.get', providing clear when-to-use guidance and implying the complementary tool.

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

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

Annotations already provide readOnlyHint and idempotentHint. The description adds value by explicitly stating it is 'read-only' and 'writes no files and uses no network,' offering clarity beyond the annotations. No contradictions.

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

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

The description is concise with two main sentences plus a short usage note. While it could be more structured, it contains no redundant information and is front-loaded with the core action.

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

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

The description provides a complete picture of what the tool does and when to use it. With an output schema present and full parameter coverage, the description adequately supports decision-making, though it could mention the output schema or return format more explicitly.

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 elaborate on parameters beyond what the schema provides; it only mentions the source types in the first sentence. It adds no new meaning for individual parameters.

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 defines the tool's action ('Ingest design tokens') and resource ('JSON, JS/TS object exports, or CSS variables') and specifies the output ('SwiftUI token enum'). It also provides context for when to use it (before view/component generation), distinguishing it from sibling tools.

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

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

The description explicitly states when to use the tool: 'before view/component generation when a design system should be preserved.' It does not provide direct when-not scenarios, but the specialized nature and the clear use case make it effective.

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

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

Annotations already indicate destructiveHint=true, but the description adds specifics: 'destructive when apply=true: can run package installs, refresh Xcode wiring, and write .axint/upgrade; may use npm network.' This adds valuable context 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?

Three sentences efficiently convey purpose, usage, and effects. The main action is front-loaded, and every sentence is informative without redundancy.

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

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

With output schema present and good annotations, the description is fairly complete. It covers inputs, outputs (install commands, file paths), and side effects. Minor gap: no explicit mention of prompt format output, but overall sufficient.

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

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

Schema coverage is 100% with clear parameter descriptions, so the description does not need to add much. However, it loosely references some parameters (e.g., format, reinstallXcode) without detailed mapping, providing marginal extra value.

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

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

The description clearly states the tool checks the latest Axint package and optionally applies the upgrade, specifying the verb 'check' and 'upgrade' with resource 'Axint package'. It also distinguishes from app dependency upgrades, making its purpose 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?

Explicitly provides when to use ('when axint.status shows a stale server') and when not to use ('not for app dependency upgrades'). Effects are listed, offering clear guidance on scenarios.

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, idempotentHint, destructiveHint. Description adds value by specifying 'writes no files' and 'uses no network', which are beyond annotations.

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

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

Single paragraph with clear purpose, pipeline detail, output format, usage guidance, and effects. 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?

With output schema present, description covers return type and structure. Annotations handle safety. Complete for a validation 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 baseline 3. Description adds extra context: 'Must be a complete file starting with an axint...', enriching beyond schema.

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

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

Clearly states verb 'validate', resource 'TypeScript intent definition', and distinguishes from generating Swift. Mentions the full validation pipeline and output format.

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

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

Explicitly says 'use for TypeScript DSL diagnostics before Swift output; use swift.validate for existing Swift', providing clear guidance on when to use this tool vs. sibling.

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?

Consistent with annotations (readOnlyHint, idempotentHint, destructiveHint). Adds useful detail: 'may update tiny workflow freshness stamps; no network,' which goes beyond annotations without contradiction.

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

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

Three sentences covering purpose, requirement, and effects. Some repetition ('Use: use'), but front-loads core information efficiently.

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?

Adequately explains when and why to use the tool given its 23 parameters and rich schema. Output schema exists so no need to detail return values. Covers effects and usage 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?

Schema coverage is 100% with detailed descriptions; description adds minimal extra parameter meaning. Baseline of 3 appropriate as description adds behavioral context rather than parameter detail.

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

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

Clearly states 'read-only agent workflow gate' and specifies its role in prove Axint workflow coverage at various stages. Distinguishes from siblings like session start and build tools.

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

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

Explicitly says 'not a final build/test substitute' and lists appropriate stages. Could be improved by referencing specific sibling tools for alternatives, but the context is 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 indicate false for readOnly, destructive, idempotent, and openWorld hints. The description adds value by stating it writes files (guard proof), may start a session, and does not edit app source or use network. This clarifies the non-read-only, non-destructive nature beyond annotations.

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

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

The description is succinct: three sentences covering purpose, usage, and effects. Every sentence adds value, and it is front-loaded with the core action ('Guard an Xcode agent session...'). No unnecessary 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?

The tool has 14 parameters, enums, and an output schema. The description covers high-level purpose, usage, and effects, but does not explain output format content, how parameters interact, or default behaviors (e.g., stage defaults to context-recovery). Given the complexity, more detail would be helpful.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds context by mentioning checks (e.g., 'latest Axint Run or guard proof' relates to lastAxintResult and maxMinutesSinceAxint) but does not provide new details beyond the schema's own descriptions. No param is fully explained in description, but schema suffices.

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

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

The description clearly states the tool's purpose: guarding against context compaction and Axint drift. It lists specific checks (project memory files, active session, latest Axint Run/guard proof, long-task freshness) and mentions writing a guard proof. This distinguishes it from sibling tools like axint.session.start or axint.run.

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

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

The description provides explicit when-to-use scenarios: 'around long Xcode tasks, context recovery, broad Swift edits, or before claiming runtime proof.' It also notes effects (writes guard proof, may start session). However, it does not mention when not to use or point to specific alternatives among the 34 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?

Describes effects: writes file, may create dirs, validates Swift, and may write guard/check artifacts. Annotations show non-destructive, but writing is inherently state-changing; the description adds context beyond annotations without contradiction.

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

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

Two main sentences plus structured 'Use:' and 'Effects:' sections. Front-loaded with core purpose. However, the 'Use... Use:' phrasing is slightly awkward but still clear and concise.

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

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

Given 12 parameters and high complexity, the description provides an overview but lacks detail on param interplay and the guard path context. Output schema exists, so return values are covered, but the overall context could be richer.

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 baseline is 3. The description ties validateSwift and cloudCheck to Swift file handling, but does not elaborate on other parameters like format, notes, etc. Modest added value.

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 writes files inside an Xcode project through the Axint guard path, and distinguishes itself from sibling tools by specifying it's for guarded Xcode-project writes, not general file operations.

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

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

Explicitly says 'use only for guarded Xcode-project file writes' and provides an alternative: 'outside Xcode, patch normally and validate after', giving clear when-to-use and when-not-to-use guidance.

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