axint

Server Quality Checklist

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

Latest release: v0.6.0
Disambiguation4/5
Most tools have distinct purposes and clear descriptions, but some overlap exists between validation tools (axint.validate vs axint.swift.validate vs axint.cloud.check) and run-related tools (axint.run vs axint.run.status), which could cause minor confusion.
Naming Consistency5/5
All tool names follow a consistent dot-separated pattern with lowercase and underscore style, clearly indicating domain and action (e.g., axint.compile, axint.workflow.check). No mixing of conventions.
Tool Count3/5
36 tools is on the high side for an MCP server, covering many sub-domains. While each tool serves a specific purpose, the sheer number could overwhelm agents and users, making it borderline for appropriate scope.
Completeness4/5
The tool set covers the full lifecycle of Apple-native development with Axint: setup, compilation, validation, repair, templates, design tokens, and session management. Minor gaps like deployment are outside the stated purpose.
Average 4.4/5 across 36 of 36 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- 4 of 4 community issues answered or closed in the last 6 months
- 54 commits in the last 12 weeks
- Last stable release on July 16, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
View related servers

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral disclosures beyond annotations: 'no files written, no network requests, no side effects' and 'read-only template metadata; writes no files and uses no network'. However, it also claims 'Inputs: category and query filter metadata' despite the schema having zero parameters, which is a contradictory and misleading claim. This undermines the transparency with a false statement about inputs, so a mid-range score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is repetitious: the claim 'no files written, no network requests, no side effects' appears twice in slightly different wording. The 'Inputs' section is unnecessary and factually wrong given the empty schema, adding noise. While the use of labels (Use, Inputs, Effects) provides structure, the redundant and misleading content makes it less concise than it should be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with no parameters and an output schema (implied by 'Returns a JSON array'), the description covers purpose, usage, safety, and return format exceptionally well. The only serious gap is the contradictory filter/input mention, which prevents a perfect score. Overall, the agent has enough context to invoke the tool correctly and interpret the result, despite this inconsistency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With an input schema of 0 parameters, the baseline for this dimension is 4. But the description introduces fictional inputs ('category and query filter metadata') that do not exist in the schema, which actively misleads an agent. Instead of adding meaningful parameter semantics, it creates confusion about optional filters that are not supported. Hence the score is significantly below baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List all bundled reference templates in the Axint SDK', using a specific verb ('List') and resource ('bundled reference templates'). It further distinguishes itself from the sibling tool axint.templates.get by positioning itself as the discovery step ('use to discover valid template ids before templates.get'). The return format is also specified, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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: 'use to discover valid template ids before templates.get'. It also advises 'call without filters to discover every valid id'. However, the mention of 'category and query filter metadata' is confusing because the input schema declares no parameters, so the guidance around filters is unsupported. This prevents a perfect score but the primary use case is clearly communicated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context by stating 'writes no files and uses no network,' which goes beyond the basic read-only hint and clarifies the tool's side-effect profile. It also explains that it is generated docs context, adding behavioral insight without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for purpose, usage, inputs, and effects. It is not overly long and front-loads the main purpose. However, the 'Inputs' section is inaccurate and should be corrected, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are covered. The description gives purpose, usage, and safety context. However, it fails to accurately describe how the actual parameters (platform, projectName, expectedVersion) influence the returned docs context, and the phantom 'cwd' and 'include sections' create confusion. This gap makes the description incomplete for an agent trying to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema describes all three parameters (platform, projectName, expectedVersion) with 100% coverage, the description introduces 'Inputs: cwd selects project docs context' and 'include sections only when the longer runbook is needed.' Neither 'cwd' nor 'include sections' correspond to any actual schema property, creating misleading guidance. Rather than adding value, this misdirects the agent and detracts from the schema's clear parameter definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns project-local Axint docs context, using a specific verb ('Return') and resource ('docs context'). It further distinguishes the tool from siblings by explaining it is durable docs memory for agents to reload after chats or compaction, and that it avoids rereading the whole site.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use: use after compaction when the agent needs workflow docs without rereading the whole site,' providing a clear when-to-use scenario. However, it does not explicitly name alternatives or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint=true, but the description adds meaningful detail beyond that: 'destructive: kills active Axint child process groups; no network.' It explains the exact destructive effect and the scope (child process groups). This provides valuable context beyond the structured annotations, though it could have stated more about process escalation details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise but includes some redundancy and awkward repetition of 'Use'. It front-loads the core purpose but then has a slightly disjointed structure with the parameter section that doesn't align with the schema. Still, it conveys a lot of important information in a compact form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main scenarios, effects, and scope of the tool, and the presence of an output schema reduces the need to explain return values. However, the contradictory parameter information creates a significant gap in understanding how to actually invoke the tool. For a destructive tool with no required parameters, this mismatch is a notable completeness issue.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description is misleading regarding parameters. It states 'Inputs: jobId is required; signal and grace period control escalation before killing the process group.' However, the actual schema contains parameters `id`, `cwd`, and `format`, none of which are required. The description introduces non-existent parameters (jobId, signal, grace period) and incorrectly claims requiredness. Even though schema description coverage is 100%, the description actively contradicts the schema and adds confusion, so it receives the lowest score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Cancel the latest or selected Axint run by killing active child process groups.' It specifies the resource (Axint run) and the method (killing child process groups), which distinguishes it from other tools. The sibling comparison shows it is obviously different from read-only tools like run.status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is given: 'Use this when xcodebuild or a UI-test runner survived an MCP timeout or transport close.' It also states exclusions ('use only to stop an active run or stuck child process group') and names an alternative tool ('use run.status for read-only inspection'). This is excellent context for when to select this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses reads ('Reads project context, latest run proof, latest repair plan, and active file claims'), side effects ('may refresh advice artifacts'), and constraints ('no network'). Since annotations do not provide read-only or idempotency hints, the description carries the burden and does a solid job, though it stops short of detailing permissions or exact artifact impacts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and uses labeled sections ('Use:', 'Inputs:', 'Effects:') to organize additional detail. It is moderately sized with every sentence contributing, though slightly dense due to multiple clauses.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fails to accurately map all 5 parameters, naming nonexistent inputs and omitting others. While an output schema exists and return values are not necessary to explain, the incomplete and misleading parameter references create a significant gap for a tool with optional, diverse parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions, giving a baseline of 3. However, the description introduces an inaccurate parameter 'question' (schema has 'issue') and misnames 'changedFiles' as 'modifiedFiles', while omitting 'agent' and 'format' entirely. This confusion detracts from what would otherwise be acceptable schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb and resource: 'Ask the local Axint project brain what this agent should do next.' It specifies the inputs (project context, proof, repair plan, file claims) and output (host-specific guidance). It also distinguishes itself from siblings by naming 'suggest' and 'repair' as alternatives, making its purpose unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'Use when local proof should choose the next move; use suggest for greenfield ideas and repair for known bugs.' This directly tells when to use this tool versus alternatives, meeting the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, but the description goes further by stating 'writes no files and uses no network' and 'read-only generated output.' It also discloses that output is structured file-by-file for an Xcode agent to write. This adds meaningful behavior beyond the annotations, though the idempotentHint is not explicitly reinforced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: main action, return value, usage, inputs, and effects. Each sentence provides distinct information, and the most critical fact (what the tool does) is front-loaded. Minor redundancy in 'read-only generated output' and 'writes no files' could be trimmed, but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 11 parameters, nested objects, and an output schema, the description offers a good high-level context: it clarifies the use case, output structure, and side-effect profile. The only notable gap is the misleading 'kind' reference and the lack of explicit mention of the output schema (though the schema itself is present). Given the schema's richness, the description suffices for guiding invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds a helpful note that 'description' is the feature brief and that 'platform' constrains the package. However, it also mentions 'kind' as an input, yet no parameter named 'kind' exists in the schema—this is misleading. The ambiguity undermines the added value and could lead an agent to look for a non-existent parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+noun: 'Generate a scaffolded Apple-native feature package from a description.' It then enumerates the output file types, making the tool's purpose unmistakable. The 'Use' clause also distinguishes it from repair tools, and the name 'feature' aligns with new-surface generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use it ('for new Apple-native surfaces') and when not to ('not for repairing existing app bugs'). However, it does not name a specific alternative tool (e.g., axint.repair or axint.scaffold), so the guidance is clear but lacks a direct pointer to the sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable specifics: 'read-only fixed-source output; writes no files and uses no network'. This reinforces and contextualizes the annotations, though it omits details about the 'format' parameter behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only four sentences but contains an awkward 'Use: use after...' redundancy and an erroneous parameter list. It is compact, but the incorrect references and slight redundancy prevent a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers when to use, effects, and basic inputs, and the presence of an output schema removes the need to describe return values. However, it introduces non-existent parameters and fails to explain the 'format' parameter's role, leaving a complete understanding incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full descriptions for all three parameters (source, file, format), so baseline is 3. However, the description incorrectly mentions 'codes' and 'maxPasses' which do not exist in the schema, misleading an agent into passing non-existent parameters. It does correctly identify source as required, but the false parameter references are harmful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Auto-fix mechanical Swift errors detected by axint.swift.validate', identifying a specific verb+resource and distinguishing it from the validator sibling. The purpose is unambiguous and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to 'use after swift.validate when errors are mechanical' and to 'inspect remaining diagnostics manually'. This provides clear when and how to use, and what to do after, effectively differentiating it from the validation tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond annotations: 'No files are written,' 'read-only Swift token output,' and 'uses no network.' This complements the readOnlyHint, idempotentHint, and destructiveHint annotations and provides concrete effects useful to an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably structured but contains redundancy: 'No files are written' is stated twice, and 'Use: use before...' repeats the prior 'Use this before...' sentence. It also includes inaccurate parameter names, adding noise. It could be tightened without losing important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers when to use the tool and side-effect transparency, and the schema covers all parameters plus an output schema. However, the inaccurate parameter references create a notable gap and could cause an agent to pass non-existent parameters. The overall context is adequate but not complete due to this mismatch.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for all actual parameters (format, source, namespace, sourcePath), so the baseline is 3. However, the description introduces 'tokens', 'enumName', and 'accessLevel' which are not in the schema, potentially misleading an agent. It also omits any reference to the real parameters' nuances, making the description add confusion rather than value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Ingest design tokens from JSON, JS/TS object exports, or CSS variables and return a SwiftUI token enum.' This is a specific verb+resource+output combination that clearly distinguishes it from sibling tools like axint.compile, axint.run, and axint.validate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use before generating Swarm-style views/components' and 'use before view/component generation when a design system should be preserved,' providing clear when-to-use context. It doesn't mention when not to use the tool or name alternatives, but the intended context is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it writes specific files (.axint/agent.json, context, coordination files) and that it makes no network calls. This adds meaningful detail beyond the annotations, which already indicate idempotentHint=true and destructiveHint=false. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized with 'Use:', 'Inputs:', and 'Effects:' sections, making it scannable. It is slightly verbose but every sentence provides useful context (purpose, usage, effects). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and annotations (idempotent, non-destructive), the description covers the essential context: what it does, when to use it, what files it writes, and that it's local-only. It doesn't explain return values, but the output schema handles that. Complete enough for a setup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter already has a clear description. The tool description adds some extra context (e.g., cwd scopes local coordination, projectName shapes files), but doesn't substantially improve on the schema's parameter docs. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Install') and resource (local Axint multi-agent project brain). It distinguishes itself from siblings by noting it is a one-time per-project setup and explicitly says it's not needed for one-off compile, which differentiates it from tools like axint.compile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: 'use once per project to create local multi-agent coordination; not needed for one-off compile.' This clearly indicates when to use it and provides an exclusion. However, it doesn't mention alternative tools or when not to use it beyond compiling, so it's not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that the tool 'may use configured Cloud Check endpoint' and 'no source is sent unless', which hints at network and privacy behavior beyond the annotations. However, the final sentence is truncated ('unless.'), leaving the disclosure incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses clear 'Use:', 'Inputs:', and 'Effects:' labels for structure, but it contains a truncated final sentence ('no source is sent unless.') that dangles without completion. There is also redundant phrasing ('Use: use for') that adds noise. The dangling sentence is a significant structural flaw.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 15 optional parameters and an output schema, the description covers the core return behavior, input constraints, and typical use cases without needing to restate schema details. It explains the tool's role in Apple-aware review and evidence support. The truncation is the only notable gap, but overall the description is adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 15 parameters have schema descriptions (100% coverage), providing a solid baseline. The description adds meaningful constraints: 'provide source or sourcePath, not both' resolves an ambiguity not stated in the schema. It also groups 'evidence fields strengthen UI and runtime claims', which helps the agent decide which optional parameters to supply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Run an agent-callable Cloud Check against Swift or Axint TypeScript source', which clearly identifies the verb, resource, and supported languages. It also enumerates the returned artifacts (verdict, findings, next steps, repair prompt), distinguishing this cloud-based check from sibling local compile/validate/repair tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Use:' section explicitly says 'use for Apple-aware source review and repair prompts; provide evidence for UI/runtime claims', giving concrete contexts. It does not name alternative tools as exclusions, but the cloud-check nature and the focus on Apple-specific findings implicitly separate it from axint.compile, axint.swift.validate, and axint.repair.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond these: 'read-only local artifact read; writes no files and uses no network,' and 'never reruns analysis.' This clarifies side effects and network usage, which are not fully covered by the annotations, making the description more informative. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured. It opens with the core action, lists return contents, then gives usage context, inputs, and effects in a logical order. Every sentence adds meaningful information, with no fluff or redundancy. The 'Use:' and 'Inputs:' labels help parsing, and the length is appropriate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple (read-only artifact retrieval) and the description covers purpose, usage, return content, and side effects. The presence of an output schema reduces the need to describe return format in detail. Minor gaps include a truncated schema description for 'format' and the 'path' vs 'packetDir' wording, but these do not materially impede understanding for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters (cwd, format, packetDir) are described in the input schema (100% coverage). The description adds context that cwd and packetDir locate an existing packet, but it mentions 'path' instead of 'packetDir,' causing slight ambiguity. The 'latest' behavior is described but is not tied to a specific parameter, which could confuse an agent. Overall, the schema already carries the semantic load, and the description provides marginal additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: reads the latest Fix Packet emitted by Axint after a compile or watch run. It specifies the exact contents returned (verdict, findings, diagnostics, next steps, fix prompt) and explicitly distinguishes itself from a new analysis pass. This is a specific verb+resource combination that differentiates it from sibling tools like axint.compile or axint.repair.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'use after a local compile/watch/check emitted a packet; not a new analysis pass.' This tells the agent when to invoke it and implicitly when not to, but it does not name alternative sibling tools. Providing an explicit exclusion without naming alternatives is slightly below the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool writes to Axint-owned project instruction files, honors dryRun to suppress writes, and makes no network calls. Annotations already indicate non-read-only and non-destructive behavior, and the description aligns with and extends them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The content is informative and front-loaded, but there is clear redundancy: 'Use this after axint.upgrade or npm/pip upgrades' is echoed by 'Use: use after package upgrades so local project-pack hints stop naming old Axint versions.' Trimming this duplication would tighten the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the full parameter schema, output schema, and annotations, the description covers the tool's purpose, usage timing, side effects, and dryRun behavior. The only notable gap is the minor parameter naming mismatch, which prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for all four parameters, so the baseline is 3. The description adds high-level context about how cwd and targetVersion map to behavior, but it uses slightly inconsistent names (cwd vs targetDir, targetVersion vs version), which may confuse rather than clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Update Axint-owned project-pack version hints after an upgrade.' It names concrete affected files and positions itself as a post-upgrade sync step, clearly distinguishing it 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: 'Use this after axint.upgrade or npm/pip upgrades.' The description repeats the invocation context in a 'Use:' clause, making it unmistakable when the tool should be applied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, but the description goes further by stating 'no files written, no network requests' and 'writes no files and uses no network.' It also discloses failure behavior (returns diagnostics instead of Swift), adding valuable 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with clear sections (Returns, Use, Inputs, Effects) and front-loads the core purpose. There is some redundancy between the return statement and the later 'Effects' line, but overall it is well-organized and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a five-parameter compile tool, the description covers purpose, output structure, error behavior, side effects, and usage alternative. It does not attempt to restate return values in detail (output schema exists), but it omits any mention of prerequisites or permissions, though those may not be relevant given the no-network, no-write nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers all five parameters with descriptions, so baseline is 3. The description adds little parameter-specific meaning: it groups options as 'sandbox, format, plist, or entitlement proof' but does not clarify individual parameters like fileName or the exact semantics of each boolean. No contradiction, but also no substantial added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Compile TypeScript source (defineIntent() call) into native Swift App Intent code.' It clearly distinguishes this from siblings by naming 'validate' as a cheaper preflight alternative and by specifying the exact return object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Use: use when TypeScript DSL source should become Swift; use validate for cheaper preflight only.' This clearly states when to use this tool and directly names an alternative, satisfying the dimension fully.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds important context: 'writes no files and uses no network' and 'format changes rendering without changing content.' This enriches the agent's understanding of side effects and idempotent behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it opens with purpose, then usage, inputs, and effects. However, the input section is inaccurate, which slightly undermines the structure's usefulness despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage, and effects, and an output schema exists, so return values need not be detailed. However, the input mismatch is a significant gap that prevents full completeness, leaving the agent uncertain about how to supply the correct parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description references 'cwd' and 'format' as inputs, but these do not appear in the input schema, which lists platform, projectName, and expectedVersion. This mismatch can mislead the agent into thinking parameters exist that don't. The schema has full descriptions, so the baseline is 3, but the misleading input references reduce clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a compact operating memory and explicitly distinguishes it from sibling tool axint.context.docs by noting the latter is for longer workflow docs. The verb 'Return' and resource identification are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (after compaction, session restart, long coding drift) and provides an alternative (context.docs for longer docs). This gives the agent clear decision criteria for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide little (all false), so the description carries the burden. It discloses read/write effects, redaction, inspectability before sending to Axint Cloud, and the default exclusion of source code. This adds meaningful behavioral context beyond the sparse annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three labeled sentences with front-loaded purpose. It is dense but every sentence contributes; no waste, though it could be slightly more scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a dual-purpose tool with 16 parameters and an output schema, the description covers use cases, privacy constraints, and key parameter behavior. It does not explain return values, but the output schema covers that, so this is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for 16 parameters, so baseline is 3. The description adds value by clarifying that `latest` reads instead of creates and that diagnostic fields remain source-free unless explicit, which enhances parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates or reads a privacy-safe learning packet for Axint repair intelligence, naming the specific resource and its purpose. It distinguishes from sibling tools by emphasizing privacy and excluding source code, which is a unique focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is present: create a packet when output is weak, read the latest packet, and never use it to send source. However, it does not name alternative sibling tools for those other cases, so it lacks the full alternatives component.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context beyond annotations: it is a 'read-only local run/job inspection; writes no files and uses no network.' This clarifies the scope and side effects, fully complementing the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably structured with clear sections, but it contains redundancy: 'Use this when...' appears twice in slightly different forms. The mention of 'jobId' and 'includeLogs' also adds avoidable noise. It could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only status tool with annotations, output schema, and full schema coverage, the description covers purpose, usage, and effects. It misses a direct explanation of the 'cwd' and 'format' parameters but is otherwise complete. The parameter name mismatch slightly detracts from completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. However, the description says 'jobId selects a background run; includeLogs changes returned detail,' but the actual schema parameters are 'id' and 'format.' This misnames parameters and could confuse an agent into looking for parameters that do not exist, actively reducing clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Read the latest or selected Axint run job record, including active child process IDs.' This is a specific verb+resource pairing. It also distinguishes itself from siblings by explicitly saying it 'does not start, rerun, or cancel work,' which separates it from 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'Use this when a long xcodebuild run may still be active after an MCP timeout or client disconnect.' It also gives exclusions by stating what it does not do, serving as clear 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (read-only, idempotent), the description discloses specific behavioral details: 'Effects: read-only; writes no files; no auth or network required' and 'format changes rendering only.' It also clarifies that it reports the running server version, not a guessed version, adding useful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, starting with purpose, then usage, inputs, and effects. It is slightly repetitive (e.g., 'Use this as the first tool...' and later 'Use: call first...'), but every sentence adds value and no unnecessary filler exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage, inputs, and effects, and the output schema exists to specify return values. It leaves a minor gap in explaining the 'prompt' format's meaning, but overall it is complete enough for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the 'format' parameter with an enum and a (though truncated) description. The tool description adds 'format changes rendering only' and 'no project path is required,' but does not fully compensate for the incomplete schema description of the 'prompt' option. Baseline is 3 due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports the exact running Axint MCP server version, package path, uptime, registered tool count, and reload/update instructions. It distinguishes itself from siblings like axint.run.status by focusing on the server process itself and explicitly excludes being an npm/PyPI lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use: 'call first or after an MCP reload to prove the connected server version' and when not to use: 'do not use as an npm/PyPI lookup.' However, it does not name alternative tools, so it stops short of fully meeting the 'alternatives' criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description confirms the read-only nature and adds that it writes no files and uses no network, which complements the annotations (readOnlyHint, idempotentHint) 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with purpose, usage, and effects; efficient but includes slight redundancy ('without writing files' vs 'writes no files'). Well front-loaded overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich output schema and annotations, the description covers purpose, usage, and effects. The only gap is the misleading 'cwd' reference, which introduces potential confusion during invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description introduces 'cwd' as an input, but the schema has no such parameter; it also vaguely refers to 'host choices' instead of naming the `agent` parameter. Despite 100% schema coverage, these inaccuracies mislead the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Generate the Axint project-start pack') plus scope ('for a new Apple app') and explicitly contrasts with sibling `project.index`, making differentiation clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance: use this to bootstrap a new project, and use `project.index` for existing projects, so the agent knows exactly when to choose this tool over an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds concrete behavioral details beyond annotations: 'read-only Swift diagnostics', 'writes no files', and 'uses no network'. These complement and reinforce the readOnlyHint and destructiveHint 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-organized with Use/Inputs/Effects sections. It remains concise while covering essential aspects, though the inaccurate Inputs section slightly detracts from structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage scenarios, behavioral effects, and pairing with swift.fix. The output schema handles return value details. However, the dangling parameter references prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the two parameters, but the description introduces 'sources', 'projectIndex', and 'platform' that are not in the schema. This creates confusing references to non-existent inputs, undermining agent confidence.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates existing Swift source against Axint's Apple-specific build-time rules (AX700–AX749), including specific rule categories. This distinguishes it from siblings like axint.swift.fix and axint.validate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use on generated or edited Swift before build and pairs with swift.fix for mechanical repairs, providing clear context and an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, providing no inherent behavioral hints. The description adds useful context: 'writes a local .axint/session workflow freshness stamp; edits no app source and uses no network.' This discloses side effects and safety boundaries. It could go further on failure modes or exact file format, but given the absence of annotation guidance, this is strong. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: purpose, usage, and inputs/effects. Front-loaded with the primary action, each sentence carries distinct value. No filler or redundancy. The structure makes it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage, preconditions, side effects, and safety boundaries (no source edits, no network). An output schema exists, so return format is covered elsewhere. The only gap is the parameter name inconsistency ('allowNoSession' vs 'requireSession'), which causes minor ambiguity. Overall, it is near-complete for a complex 23-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds high-level semantics for a few key params ('stage selects the gate; sessionToken proves continuity; allowNoSession is an explicit escape hatch'), but it misnames the parameter: schema has 'requireSession', not 'allowNoSession'. This mismatch could mislead an agent. It also doesn't map the full set of 23 params, though that is unnecessary given schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Agent workflow gate that records a local freshness stamp.' It clearly states the tool's role as a workflow gate, and explicitly distinguishes it from siblings: 'use status for version checks and run for build/test proof.' This differentiates it from tools like axint.status and axint.run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidance is explicit: 'Use: use at stage gates to prove workflow coverage; use status for version checks and run for build/test proof.' This states when to use this tool and when to prefer alternates. It also specifies the session token requirement and the escape hatch via requireSession=false, setting clear preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotent and non-destructive, but the description adds concrete effects: 'writes .axint/context unless dryRun=true; reads local project files only.' This clarifies write/read scope beyond the annotation hints, though it doesn't detail overwrite behavior or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three succinct sentences: purpose, usage, then inputs/effects. It is front-loaded with the action, avoids redundancy, and every sentence contributes essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 optional params, output schema present), the description covers purpose, when to use, key input roles, and effects. The output schema handles return details, so missing return descriptions are fine. This is a complete and well-rounded description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description enhances semantics by explaining that 'changedFiles seed related-file discovery' and 'dryRun returns the pack without writing .axint/context,' adding value beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Scan the local Apple project and write a compact .axint/context pack' for enabling reasoning over changed files, nearby SwiftUI surfaces, and interaction-risk files. This specific verb+resource+outcome distinguishes it from single-file tools and sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use: use before project-aware repair, multi-file SwiftUI work, or interaction-risk analysis.' This gives clear when-to-use context, but does not mention when-not-to-use or name alternatives like axint.project.pack. Hence 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavior beyond the annotations: 'local mode is read-only; Pro mode may call Axint endpoint when credentials are configured.' This nuances the readOnlyHint, clarifying that Pro mode may have external side effects. It also explains input weighting ('domain is only a weak hint; the app description wins'). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with 'Use:', 'Inputs:', 'Effects:' sections and front-loaded with the core function. It is somewhat verbose but each section has a purpose. The stray 'prompt/dir' input reference could have been omitted, but overall it remains readable and useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 10 parameters and an output schema, the description covers the essentials: return format, mode behavior, and usage context. It does not need to explain return values due to the output schema. The minor parameter mismatch prevents a perfect score, but the description is largely complete for an agent to decide and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, so the baseline is 3. The description does add useful context, e.g., appDescription takes precedence over domain. However, it mentions 'prompt is the product brief; dir adds project context', which are not actual parameters in the schema, potentially misleading the agent. This inconsistency prevents a higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Suggest Apple-native features for an app based on its description.' It uses a specific verb ('suggest') and resource ('Apple-native features'), and specifies the input basis ('app description'). It also distinguishes from siblings by noting it is 'not a substitute for registry search or validation.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: 'Use: use before generation to choose Apple surfaces; not a substitute for registry search or validation.' This tells the agent when to use it and what it is not for. Also clarifies Pro mode is used only when configured, setting expectations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false and provide no safety hints, so the description carries the burden and mostly delivers: it reveals that Swift files trigger immediate validation and cloud check, writes .axint/guard/latest.* proof, may create directories, and may write guard/check artifacts. However, it does not disclose failure behavior (e.g., what happens if validation fails) or permission requirements, so it is not fully transparent, but still strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and uses short sentences, but it repeats the 'use' guidance twice ('Use this instead of raw XcodeWrite...' and 'Use: use only for guarded...') and includes a somewhat redundant 'Effects' section that restates earlier points. Still, it remains reasonably tight and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 12 parameters, two Swift validation steps, and artifact writing, the description covers purpose, usage context, effects, and default parameter values. It does not describe return values, but an output schema exists so that is acceptable. Missing details like failure handling or integration with session tokens are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, but the description adds extra meaning by pointing out defaults ('createDirs, validateSwift, and cloudCheck default true') and the constraint that 'path must remain inside cwd.' It also links behavior to parameters (Swift validation/cloud check) beyond schema text, adding genuine value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Write a file inside the Xcode project through the Axint guard path') and explains the unique guard/validation behavior. It further distinguishes itself from 'raw XcodeWrite' and states it is for Apple-native files during long tasks, which clearly separates it from sibling tools like axint.xcode.guard or axint.swift.validate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs 'Use this instead of raw XcodeWrite when an agent is editing Apple-native files during a long task' and then provides a clear exclusion: 'outside Xcode, patch normally and validate after.' This gives both positive and negative usage guidance, fully differentiating it from alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With all annotations false, the description carries the full burden. It clearly discloses side effects: 'reads local project files', 'writes .axint/repair and privacy-safe .axint/feedback artifacts', and even notes 'runs Cloud Check when source is provided', implying network activity. This exceeds the minimal disclosure expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured into useful segments ('Use:', 'Inputs:', 'Effects:') and front-loads the main purpose. However, it repeats the artifact-writing detail ('writes .axint/repair plus a privacy-safe .axint/feedback packet' and later 'Effects: writes .axint/repair and privacy-safe .axint/feedback artifacts'), costing a small amount of economy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 17 parameters, the schema and output schema cover the detailed semantics. The description provides the high-level workflow (index, classify, Cloud Check, rank, return plan, write artifacts) and contextual notes (privacy-safe feedback, reads local files), making it complete for an agent to understand when and how to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds some context (e.g., 'describe the observed bug and attach logs or evidence', 'modifiedFiles and project index narrow the plan'), but it uses the term 'modifiedFiles' while the schema defines 'changedFiles', creating potential confusion. It doesn't meaningfully compensate beyond the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Plan'), the resource ('a project-aware Apple repair for existing apps'), and specific actions (indexes, classifies, runs Cloud Check, ranks files, returns plan, writes artifacts). It distinguishes from siblings by explicitly noting 'not for greenfield generation', separating it from scaffold or feature tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use: use for existing app bugs with logs, UI symptoms, or runtime evidence; not for greenfield generation.' This is a clear when/when-not directive, and the mention of 'modifiedFiles and project index narrow the plan' indicates how to refine usage for better results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds concrete behavioral context beyond these: no files are written, no network requests made, returns an error string on invalid domain, and output compiles directly with axint.compile. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Use, Inputs, Effects) and front-loaded purpose. Minor repetition of 'writes no files and uses no network' appears twice, but overall it is efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and 4 parameters, the description fully covers what the tool does, its return value, error behavior, and relationship to siblings. It also explains the compile integration with axint.compile, making it complete for an 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.
Parameters4/5
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 useful semantics: 'name must be PascalCase' (reinforces schema), 'params define the starter contract', and 'domain defaults to general' (not in schema). This adds value beyond the structured schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a starter TypeScript intent file from a name and description, and that it returns a defineIntent() source string. It also explicitly distinguishes itself from siblings by recommending templates.get for richer examples and compile for Swift output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: 'use to create a small TypeScript intent starter; use templates.get for richer examples and compile for Swift output.' This clearly tells the agent when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds concrete behavioral details: 'writes no files and uses no network' and 'has no project inputs'. This provides valuable context not captured in the annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet information-dense. Each sentence serves a purpose: what it does, when to use it, what the inputs are, and what the effects are. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional parameter) and has an output schema. The description covers the purpose, usage timing, alternatives, input semantics, and effects, making it complete for an 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with a clear enum description. The description adds meaning by stating 'format changes rendering only' and clarifying the smoke test has no project inputs, reinforcing that format is the only parameter and only affects output presentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs a source-free compiler smoke test through the real Axint pipeline, using a specific verb and resource. It distinguishes itself from siblings by explicitly mentioning 'use validate or run for project checks'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to call immediately after install or first MCP connection, and that validate or run should be used for project checks. This gives concrete when-to-use guidance and names alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive. The description adds valuable context: 'read-only Swift generation; writes no files and uses no network,' clarifying side effects beyond the annotation hints. It does not contradict annotations and provides extra behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it opens with the core action, then covers supported types, token efficiency, usage alternatives, input summary, and effects. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (18 parameters, nested objects, output schema), the description is remarkably complete. It covers purpose, usage guidance, token benefits, side effects, and alternatives. The output schema handles return values, so the description doesn't need to.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds semantic meaning by explaining the 'type' parameter selects output kind and highlights the minimal JSON schema input, going slightly beyond the schema's per-field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compiles a minimal JSON schema directly to Swift, bypassing the TypeScript DSL. It explicitly lists supported output types (intents, views, components, widgets, apps) and distinguishes itself from sibling tools like compile and scaffold.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'use for token-light JSON-to-Swift generation; use compile for full TypeScript DSL control and scaffold for TS starters.' It also notes the token budget advantage, giving clear when-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With all annotation hints false, the description carries the burden and does so well by detailing write artifacts (.axint/session/current.json, AXINT_REHYDRATE.md), no auth/network requirement, and token/history continuity after compaction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Compact, front-loaded, and well-structured with Use/Inputs/Effects sections. Every sentence carries distinct information and none is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a session-bootstrap tool with 7 optional parameters and an output schema, it covers when to use, side effects, return contents, and environmental prerequisites. No major gaps; output schema handles return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds semantic value by explaining targetDir scoping and prior-token/context continuity, though 'cwd' and 'prior token/context inputs' are not explicit schema parameters, creating slight ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a specific verb and resource ('Start an enforced Axint agent session') and enumerates concrete outputs (session file, rehydration doc, memory, token, workflow.check args). This clearly identifies its unique role versus sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'Use:' instruction gives clear triggers: at the start of a tool-enabled agent session or after context compaction. It does not name exclusions or alternatives, but the usage context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it states the output is a complete, compilable file as a string, includes perform() logic and parameter definitions, and explicitly says 'read-only template source; writes no files and uses no network.' This reinforces the read-only nature and clarifies side effects, though it doesn't explore edge cases like invalid IDs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet information-dense. It uses two paragraphs: the first explains core functionality and output format, the second gives usage guidance and effects. Every sentence contributes: what it returns, what's included, when to use it, and side effects. No fluff or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter, clear annotations, and an output schema (though its content isn't shown). The description covers purpose, workflow, output composition, and side effects. Given the relative simplicity, the description is complete. It doesn't need to explain return values because there is an output schema, and the description already summarizes the output as a string source file.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of 'id' (Template id from axint.templates.list, e.g., 'send-message' or 'create-event'). The description adds context about the id's origin and format, and the note 'format changes source versus metadata rendering' hints at potential other inputs. While the schema fully covers the parameter, the description reinforces the critical validation constraint that the id must come from templates.list, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb ('Retrieve'), names the resource ('full TypeScript source code of a specific bundled template by id'), and clearly contrasts with sibling tools by stating it returns a complete, compilable defineIntent() file. The mention of the workflow with templates.list and compile distinguishes it from list (listing) and compile (compiling), fully clarifying the tool's unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides usage context: 'Use: use after templates.list to fetch a complete reference template; edit it before calling compile.' This gives a clear workflow and positions it relative to siblings. It also implies when not to use it (no need for source, just metadata/list) and emphasizes that the id must come from templates.list, preventing misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds detailed effects beyond annotations: destructive operations when apply=true (package installs, Xcode wiring refresh, writing .axint/upgrade), plus preserving agent thread and potential npm usage, providing concrete behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is structured with clear sections and front-loaded purpose, though it packs many details into a dense block; still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 params, annotations, and output schema, the description covers purpose, usage triggers, exclusions, effects, and parameter relationships, leaving no major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 7 params, and description adds conditional semantics (apply defaults false; targetVersion vs reinstallXcode/writeReport applicability), helping agents correctly configure calls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool checks the latest Axint package and optionally applies the upgrade, with a specific use case (stale server) and exclusions (not for app dependency upgrades), distinguishing it from sibling status/install tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to call (axint.status shows stale server) and when not to (app dependency upgrades), but doesn't name a specific alternative tool, so not quite a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description adds critical behavioral details: it runs 134 diagnostic rules, returns a structured JSON array of diagnostics, returns an empty array for pass, and explicitly states 'writes no files and uses no network'. This provides far more context than the annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet information-dense, with clear section labels ('Use:', 'Inputs:', 'Effects:'). Each sentence contributes unique value—purpose, return format, usage guidance, and effects—without redundancy. It is efficiently structured for AI scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage, return value semantics, and non-effect guarantees, fully compensating for the single simple parameter. Given the tool's simplicity and the rich output schema/diagnostic format description, it is complete and self-sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the one parameter 'source' thoroughly (full file, not fragment). The description's 'source is TypeScript DSL text' adds minimal new meaning. The mention of 'strictness options' is ambiguous since no such parameters appear in the schema, but schema coverage is 100%, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource ('Validate a TypeScript intent definition') and immediately distinguishes from siblings by stating it does so 'without generating Swift' and explicitly comparing to 'swift.validate'. This makes the tool's unique role unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Use:' section gives explicit guidance: 'use for TypeScript DSL diagnostics before Swift output; use swift.validate for existing Swift.' This directly contrasts with an alternative sibling and clarifies when each should be chosen, fulfilling the highest bar for usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds 'Effects: read-only inspection; writes no files; no auth or network required,' which goes beyond annotations with useful context about side effects and prerequisites. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by usage guidance, parameters, and effects. It is somewhat repetitive ('Use this when' and 'Use: call when' echo each other), but every sentence carries distinct information. Slightly longer than necessary but well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage scenarios, parameter semantics, and effects. An output schema exists, so return values are already structured. Given the tool's complexity and the rich sibling context, this is complete and self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage, so baseline is 3. The description adds semantic meaning for cwd ('selects the project') and expectedVersion ('turns a runtime mismatch into a blocker'), which is valuable beyond the schema. Format is self-explanatory in schema, so no additional detail needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Audit the current Axint runtime and project wiring' and enumerates specific inspected items (MCP version, paths, config files, Xcode registration). This is a specific verb+resource that clearly distinguishes from siblings like axint.run or axint.status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'Use this when' scenarios are provided (stale process, new project MCP proof), plus a direct alternative comparison: 'use run for build proof.' This gives clear guidance on when to call this tool vs. others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable context: 'read-only local registry search using AXINT_REGISTRY_PATH or sibling checkout; no network by default.' This goes beyond annotations by describing the data source and network behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections for purpose, usage, inputs, and effects. Every sentence provides value, but there is slight redundancy ('Use this BEFORE...' and 'Use: use before...') that could be tightened. Still concise overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Has an output schema, so return format needs no description. The description covers purpose, when to use, exclusions, parameter semantics, and effects (none), making it fully complete for a read-only search tool. No significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds relational semantics: 'query drives ranking' and 'kind and platform narrow results without changing the registry source,' which clarifies how the parameters interact beyond their individual schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search the Axint Registry for already-published packages that match a natural-language query' — a specific verb, resource, and scope. It distinguishes itself from axint.feature and axint.compile by positioning itself as the pre-step for finding existing packages before generating code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this BEFORE calling axint.feature or axint.compile' and 'not for validating local Swift', giving clear when-to-use guidance and named alternatives. This leaves no ambiguity about when to prefer this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, so the description carries full burden. It explicitly discloses effects: 'writes .axint/guard proof and may start a session' and non-effects: 'does not edit app source or use network.' This goes beyond what annotations provide and gives essential behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, checks, usage, inputs, effects). It is moderately long but every sentence provides useful information, earning a score above the mid-range, though not a perfect 5 due to some logical density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 params, many siblings), the description is highly complete: it conveys purpose, when to use, side effects, key parameter semantics, and alternatives. It doesn't need to explain return values because an output schema exists. This is a comprehensive, production-ready description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by explaining the roles of key parameters: 'stage selects the gate; modifiedFiles and notes narrow drift checks; autoStartSession defaults true.' This highlights semantics not obvious from the bare schema, justifying a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Guard an Xcode agent session against context compaction and Axint drift.' It further specifies the checks performed (project memory, active session, latest Run/proof, freshness). It also distinguishes from a sibling by mentioning 'use workflow.check' as an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'call around long Xcode tasks, context recovery, broad Swift edits, or before claiming runtime proof.' It also names an alternative tool ('use workflow.check') and clarifies when to consider it, giving clear context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses side effects beyond annotations: 'Claims are local, short-lived, and stored in .axint/coordination/claims.json,' and 'Effects: writes local coordination claims under .axint/coordination; no network.' This adds valuable context not captured by readOnlyHint/destructiveHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured: purpose sentence, usage note, and effects. No redundancy; every sentence provides distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema and 100% parameter coverage, the description is complete. It covers side effects, local/network behavior, TTL, and usage context, making it sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning for key parameters: 'files identify the claim; ttlMinutes bounds ownership and force overrides stale claims.' However, it references 'agentId' while the schema parameter is 'agent', creating a minor mismatch.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Claim files before an agent edits them so other agents do not patch the same SwiftUI/App files concurrently.' This is a specific verb+resource with a precise purpose, and it distinguishes the tool from siblings like axint.agent.release.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'use before editing shared files in parallel-agent work; release claims when done.' It also mentions the complementary release action, giving clear guidance on lifecycle.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavior beyond annotations by stating effects: 'updates local coordination claims under .axint/coordination; no network.' It also clarifies scope narrowing: 'agentId releases only its matching claims unless files narrow the release set.' No contradiction with annotations (idempotentHint=true, destructiveHint=false, readOnlyHint=false).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-organized, with clear labeled sections for usage ('Use:') and effects ('Effects:'). Every sentence provides value, and there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage timing, effects, and parameter interaction. Output schema exists, so lack of return-value detail is acceptable. The tool is a straightforward release operation with 5 optional parameters, and the description is fully sufficient for an agent to decide and execute.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters, so baseline is 3. The description adds relational meaning between agentId and files ('agentId releases only its matching claims unless files narrow the release set'), which helps select correct parameter combinations. It does not fully redefine each parameter but adds useful context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Release active local Axint file claims for this agent after finishing or abandoning a task.' It uses a specific verb-resource pair and explicitly distinguishes from sibling tools like axint.agent.claim and axint.agent.advice by mentioning when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage instructions: 'use after finishing or abandoning claimed files; use agent.claim before edits and agent.advice for next steps.' This names the tool's intended timing and contrasts it with alternatives, which fully addresses when to use this tool vs. siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses concrete side effects: 'starts child processes, writes .axint/run artifacts, may run xcodebuild/tests, and may call Cloud Check.' This complements the annotations (readOnlyHint=false, openWorldHint=true) and adds useful specifics about artifact paths and external calls, going beyond what annotations already convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of three tightly focused sentences: purpose, usage guidance, and effects. It is front-loaded with the action and resource, every sentence earns its place, and there is zero redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (32 parameters, output schema, annotations), the description provides a complete high-level orientation. It names sibling tools for alternatives, mentions background execution and artifacts, and leaves parameter-level details to the comprehensive schema. An agent has enough context to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds interpretive value by explaining the behavioral impact of key parameters (e.g., 'integration=minimal enforces local advisory no-fix behavior' goes beyond the schema's wording). This elevates it to a 4, though the schema remains the primary source for parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Run the enforced Axint Apple build loop outside the Xcode UI,' which clearly identifies the action, resource, and context. It then distinguishes from siblings by naming alternatives (swift.validate, cloud.check, fix-packet) when only one stage is needed, leaving no ambiguity about its primary role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use for the complete proof loop' and directly instructs when to use alternatives ('use swift.validate, cloud.check, or fix-packet when only one stage is needed'). It also highlights key configuration modes (integration, background, outputDir) that affect how the tool is invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

axint MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![axint MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/agenticempire/axint/badges/card.svg)](https://glama.ai/mcp/servers/agenticempire/axint)

Score Badge

Copy to your README.md:

[![axint MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/agenticempire/axint/badges/score.svg)](https://glama.ai/mcp/servers/agenticempire/axint)