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
- 75 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 passing
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds that no files are written and no network is used, reinforcing the read-only, side-effect-free nature. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is moderately concise but contains redundancy ('Use this before ...' then 'Use: use before ...'). Could be streamlined. Structure is front-loaded with purpose but the parameter inaccuracy disrupts clarity.
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?
Despite having an output schema and annotations, the description's parameter inaccuracy leaves it incomplete. It omits mention of sourcePath and the actual parameter names. For a 4-param tool with high schema coverage, this is insufficient.
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?
Schema coverage is 100% with good descriptions, but the description incorrectly mentions 'enumName' and 'accessLevel' as parameters, which do not exist in the schema. This creates confusion and undermines the value added by the description. Baseline 3 is reduced due to inaccuracy.
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 it ingests design tokens from JSON/JS/TS/CSS and returns a SwiftUI token enum. It specifies the context (before view/component generation) and distinguishes itself from any sibling tools as the only token ingestion tool.
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 'Use this before generating Swarm-style views/components' and 'use before view/component generation when a design system should be preserved'. Provides clear guidance on when to use, though no explicit alternatives or when-not-to-use are mentioned.
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 declare destructiveHint=true. Description adds that it kills active Axint child process groups and has no network side effects, providing useful context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise but contains redundancy ('Use: use only...') and an inaccurate parameter list. It could be better structured without the misleading input details.
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?
While the usage context is clear, the description fails to explain the actual parameters (id, cwd, format) that are in the schema. The output schema is mentioned but not detailed.
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 mentions 'jobId is required; signal and grace period control escalation', but the schema has id (optional), cwd, and format. This contradicts the actual parameters and would mislead an AI 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 clearly states the tool cancels an Axint run by killing child process groups. It distinguishes between latest and selected, and contrasts with sibling run.status for read-only inspection.
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 tells when to use (active run stuck after timeout/transport close) and when not to (use run.status for inspection). Mentions 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 indicate idempotent and non-destructive. Description adds that it updates specific project files, performs no network calls, and respects a dryRun flag. This adds useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description contains redundant phrasing ('Use this after... Use: use after...') and could be more streamlined. It is not overly long but has minor repetition.
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 4 parameters, no required params, and an output schema, the description covers the main use case, effects, and file scope. No significant gaps remain for the intended use.
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 refers to parameters as 'cwd' and 'targetVersion' while the actual parameters are 'targetDir' and 'version'. This inconsistency could confuse agents, 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 it updates Axint-owned project-pack version hints after upgrades, naming specific files like .axint/project.json, AGENTS.md, etc. This differentiates it from sibling tools like axint.upgrade, which performs the upgrade itself.
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 states 'Use this after axint.upgrade or npm/pip upgrades', providing clear context. Lacks explicit exclusions for other scenarios, but the use case 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 key behavioral traits: packets never include source by default, are redacted, and can be inspected before sending. It covers the dual read/write nature and privacy safety, adding value beyond the all-false 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 main purpose and uses multiple sentences that each add distinct value. Slightly wordy but efficient, covering contents, usage, parameter hints, and effects without redundancy.
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 16 parameters, 100% schema coverage, and minimal annotations, the description provides good behavioral and usage context. It explains the mode switch, source-free policy, and inspection ability. Lacks coverage of error cases or output schema details, but is adequate overall.
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?
With 100% schema description coverage, the baseline is 3. The description adds meaningful context on parameter behavior, such as 'latest' switching to read mode and source fields being excluded unless explicit, enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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, specifying the resource and dual function. It distinguishes itself by emphasizing privacy safety and excluding source code, but does not explicitly differentiate from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: use when output is weak or to read the latest packet, and never to send source. It explains the behavior of the 'latest' parameter and source-free fields, but lacks comparison to alternative sibling tools.
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 indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable behavioral context: 'reads no files and uses no network', which reinforces the read-only, idempotent nature and clarifies no side effects beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two main sentences plus structured 'Use:', 'Inputs:', 'Effects:' sections. Front-loaded with purpose. Some redundancy (e.g., 'durable docs memory' and 'workflow docs'), but overall efficient.
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?
Given the tool has 3 parameters, output schema, and rich annotations, the description is mostly adequate but has a gap due to the param mismatch (mentioning cwd not in schema). It explains use cases and side effects, which is sufficient for a read-only tool with output schema.
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 mentions 'cwd selects project docs context' but the schema has no 'cwd' parameter; it includes platform, projectName, expectedVersion. This mismatch confuses parameter semantics and fails to add meaningful guidance 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 explicitly states the tool 'Return the project-local Axint docs context' and explains its purpose: reloading after new chats or context compaction to maintain workflow memory. It distinguishes from siblings like axint.context.memory by specifying 'docs context' and 'workflow docs'.
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?
Provides clear usage context: 'use after compaction when the agent needs workflow docs without rereading the whole site.' Also mentions reloading after new chats. Does not explicitly state when not to use, but the guidance is specific and actionable.
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. The description adds that it is 'read-only generated context; writes no files and uses no network', reinforcing the safety profile. However, it does not detail potential side effects beyond annotations, so a 4 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with purpose and usage guidance. It is succinct but contains some redundancy (e.g., restating the use with different words). Still, it efficiently conveys key information without excess.
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?
Given the presence of output schema and annotations, the description adequately covers usage context and high-level behavior. However, the parameter mismatch reduces completeness; the description should align with the schema to provide a full picture.
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 has three parameters (platform, projectName, expectedVersion) all described. However, the description mentions 'cwd' and 'format' as inputs that do not appear in the schema, causing confusion. It does not clarify the actual parameters beyond the schema, which already has 100% coverage. The description's extra information is misleading rather than helpful.
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 returns 'compact Axint operating memory' and specifies when to use (new chat start, compaction, long coding drift). It distinguishes from sibling axint.context.docs by noting different use cases (operating rules vs longer workflow docs).
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 tells when to use this tool ('after compaction or session restart') and provides a clear alternative ('use context.docs for longer workflow docs'). This helps the agent choose correctly.
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?
All annotations are false, so the description carries full burden. It discloses key behaviors: writes artifacts (.axint/repair, .axint/feedback), reads local project files, and runs Cloud Check conditionally when source is provided. It could clarify whether it modifies source files (it does not).
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 logical sections: purpose, process, usage, inputs, effects. Each sentence adds value, though it is slightly verbose (4-5 sentences) for a tool with 17 parameters; still 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?
Given the complexity (17 params, many siblings, output schema exists), the description covers the tool's role, inputs, effects, and usage boundaries. It does not detail output format (handled by output schema) or compare directly to all siblings, but is sufficient for an agent to make informed decisions.
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 coverage is 100% with parameter descriptions. The description adds value by grouping inputs ('describe bug, attach logs; modifiedFiles and project index narrow the plan') and indicating how they contribute, but this is incremental over 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's purpose: 'Plan a project-aware Apple repair for existing apps.' It details the process (indexes, classifies, runs cloud check, ranks files, returns plan, writes artifacts) and distinguishes from greenfield generation, making it specific and differentiated from siblings like axint.scaffold.
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: 'use for existing app bugs with logs, UI symptoms, or runtime evidence; not for greenfield generation.' This provides clear context and exclusions, though it does not directly name alternative tools among the 35 siblings.
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 declare all false; description adds valuable behavior details: writes files, no auth/network required, continuity preservation. 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?
Description is front-loaded with purpose, uses colons for structure. It is slightly wordy but efficient 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?
Covers purpose, usage, side effects, and return components. Given output schema exists, return details are adequate. Could mention that no prior state is required.
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 coverage is 100% with detailed descriptions; the description adds minimal param meaning beyond listing inputs like 'cwd' (not a param). 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 clearly states the tool starts an Axint agent session, listing specific actions (writes files, returns memory/token) and usage context. It distinguishes from siblings by explicitly saying 'call at the start of a tool-enabled agent session or after context compaction'.
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 provides explicit when-to-use guidance ('call at the start... or after context compaction') and notes effects. It lacks explicit alternatives or when-not-to-use instructions, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only and idempotent behavior. Description adds that local mode is read-only and Pro mode may call an endpoint when configured. No contradictions; the description provides useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise with three informative sentences. It front-loads the core purpose and tucks details later. Could be slightly tighter, but avoids wordiness.
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?
Covers return format (ranked list with surfaces, complexity, description), mode side effects, and relationship between domain and description. With an output schema present, return values are well documented. Minor lack of error/edge case discussion is acceptable given the tool's complexity.
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 provides 100% description coverage for all 10 parameters with detailed descriptions. However, the tool description mentions 'prompt' and 'dir' which do not match the schema's parameter names (appDescription, domain, etc.), causing potential confusion and 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 that the tool suggests Apple-native features for an app based on its description. It uses specific verbs and resources, and distinguishes itself from sibling tools like registry.search by advising against substitution.
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 'use before generation to choose Apple surfaces' and provides guidance that domain is a weak hint. However, it could be more explicit about when not to use it, though the negative guidance is present.
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 provide readOnly, idempotent, non-destructive hints. Description adds 'no files written, no network requests, no side effects' and 'read-only template metadata', going beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is somewhat verbose with redundancy (e.g., 'no side effects' and 'read-only' repeated). Could be more concise while keeping key information front-loaded.
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 no parameters and presence of output schema, description fully explains what the tool returns (JSON array of objects), its purpose (discovery), and effects (none). No gaps for agent invocation.
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 has no parameters (100% coverage). Description says 'No input parameters required', which is clear. However, mentions 'Inputs: category and query filter metadata' which could confuse agents about parameter existence, though schema confirms none.
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?
Clearly states it lists all bundled reference templates in the Axint SDK, specifies return format (JSON array of objects with id, name, description), and distinguishes from sibling axint.templates.get by mentioning 'use to discover valid template ids before templates.get'.
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 'use to discover valid template ids before templates.get' and 'call without filters to discover every valid id'. Provides clear context for when to invoke. Lacks explicit when-not-to-use statements but is otherwise strong.
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?
Discloses key traits 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.' Annotations (readOnlyHint=false, etc.) are minimal, so description adds value 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus a usage note. Front-loaded with purpose, then details. Every sentence adds value; no fluff.
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?
With output schema present (context signals), return value explanation is unnecessary. Description covers how to use, effects, and storage. Could mention what happens if claim fails or is stale, but overall sufficient for the tool's complexity.
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 covers all 6 params with descriptions (100% coverage). Description adds: 'agentId and files identify the claim; ttlMinutes bounds ownership.' This is helpful but does not significantly enhance understanding beyond the schema's parameter 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?
Description clearly states the tool's purpose: 'Claim files before an agent edits them so other agents do not patch the same SwiftUI/App files concurrently.' It distinguishes from siblings as no other claim tool exists among the 34 siblings.
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 usage guidance: 'Use before editing shared files in parallel-agent work; release claims when done.' Provides context for when to use, though could expand on when not to use (e.g., avoid for single-agent tasks).
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?
Adds context beyond annotations: 'read-only local artifact read; writes no files and uses no network.' Consistent with readOnlyHint and no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise multi-sentence description, front-loaded with purpose, then usage, input hints, and 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?
Covers purpose, usage context, and effects adequately. Output format details are likely covered by output schema, so omission is acceptable.
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 coverage is 100% with good parameter descriptions. The description mentions 'cwd and path' but 'path' is not a parameter (packetDir is), and refers to 'latest' which isn't a parameter. Adds limited value beyond 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 'Read the latest Fix Packet' with specific verb and resource, and distinguishes from siblings like 'axint.compile' and 'axint.repair' by focusing on reading an existing artifact.
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?
Provides explicit when-to-use ('after a local compile/watch/check emitted a packet') and when-not ('not a new analysis pass'). Lacks explicit alternatives but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description reinforces annotations (readOnlyHint, idempotentHint, destructiveHint) by stating 'read-only fixed-source output; writes no files and uses no network', adding specific behavioral context beyond the annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: first states purpose, second gives usage guidelines, third lists parameters and effects. Front-loaded and efficient with no wasted words.
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 but incorrectly references parameters not in the schema. Given the tool's complexity and available annotations/output schema, the description is not fully accurate, reducing its 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% with descriptions for file, format, source, but the description mentions parameters 'codes' and 'maxPasses' that are not present in the input schema, causing confusion and misinformation. This undermines the agent's ability to use the tool correctly.
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-fixes mechanical Swift errors detected by swift.validate, specifying the verb (fix), resource (Swift errors), and distinguishing it from siblings by narrowing to mechanical errors from 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 'use after swift.validate when errors are mechanical; inspect remaining diagnostics manually', providing clear when-to-use and when-not-to-use, and implicitly directing to manual inspection for non-mechanical errors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate it is not read-only and not destructive. Description adds that it writes a local stamp, edits no app source, uses no network. No contradiction. Full behavioral disclosure, so score 5.
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, two clear sentences and a few bullet-like phrases. Front-loaded with purpose. No wasted words, so score 5.
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?
Contextual: 23 params all in schema, output schema exists, description covers purpose, prerequisites, effects, and key inputs. Sufficient for agent to invoke, so score 5.
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 covers 100% of parameters. Description only highlights a few. No additional semantic value beyond schema, so baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it records a local freshness stamp at workflow gates. It gives specific use cases but does not explicitly distinguish from all sibling tools, only mentions status and run. Hence score 4.
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?
Provides guidelines: use at stage gates for coverage, use status for version checks, run for build/test proof. Also mentions session token requirement. Lacks explicit when-not-to-use or full alternative list, so score 4.
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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that the response is read-only, may use a configured Cloud Check endpoint, and clarifies no source is sent unless (implying no retention). This provides useful 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 structured with clear sections (purpose, use, inputs, effects). It is somewhat verbose but front-loaded with essential information. Minor redundancy exists (e.g., 'Use:' and 'Inputs:'), but overall 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?
Given 15 optional parameters and an output schema (mentioned but not shown), the description adequately covers purpose, inputs, outputs, and effects. It specifies what the tool returns (verdict, findings, steps, etc.) and when to use it, making it complete for agent 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 has 100% description coverage for all 15 parameters. The description adds meaning beyond schema by advising mutual exclusivity of source and sourcePath, and that evidence fields strengthen claims. This helps the agent use parameters correctly.
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 performs a Cloud Check on Swift or Axint TypeScript source, returning a verdict, findings, next steps, repair prompt, and feedback. It distinguishes from sibling tools like axint.compile or axint.validate by focusing on cloud-based Apple-aware review.
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 provides explicit guidance on when to use (Apple-aware source review, evidence for UI/runtime claims) and how to use (provide source or sourcePath, not both; evidence fields strengthen claims). It lacks explicit mention of when not to use or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. Description adds that it 'writes no files and uses no network,' confirming safety and providing extra behavioral detail beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the main action, no redundant information. Each sentence earns its place: purpose, usage, effects.
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?
With 11 parameters and an output schema, the description adequately covers the tool's function, return type, and constraints. It could clarify 'kind' but overall provides sufficient context 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?
Schema coverage is 100%, so baseline is 3. Description mentions 'description is the feature brief; kind and platform constrain the generated package.' While helpful, 'kind' does not appear as a parameter name, causing slight ambiguity. No significant added value beyond 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 'Generate a scaffolded Apple-native feature package from a description.' It specifies the output (multiple files) and differentiates from sibling tools by noting it's for new surfaces, not bug repairs.
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: use for new Apple-native surfaces; not for repairing existing app bugs.' Provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 that the tool 'writes no files and uses no network', reinforcing the read-only nature and providing extra context about side effects. This adds value beyond 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with the main action. Every sentence adds value without fluff. It could be slightly shorter but is already efficient and 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?
Given the presence of an output schema and comprehensive annotations, the description covers purpose, usage, effects, and parameter roles adequately. It explains the tool's scope, constraints (no file writes, no network), and how it fits with sibling tools. This is complete for the task.
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 coverage is 100% with all parameters described. The description groups parameters by role ('Inputs: cwd and projectName identify the project; host choices control generated integration files'), adding semantic grouping but not significantly new information. 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 clearly states the verb 'Generate' and the resource 'Axint project-start pack for a new Apple app'. It distinguishes itself from the sibling tool 'project.index' by specifying that this tool is for bootstrapping a new project while the sibling is for inspecting existing projects.
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 says 'use to bootstrap a new Apple project with Axint instructions; use project.index to inspect an existing project.', providing clear when-to-use and a direct alternative. This eliminates ambiguity about usage 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?
The description explicitly states 'Effects: read-only Swift diagnostics; writes no files and uses no network,' which aligns with and adds context to annotations (readOnlyHint, idempotentHint, destructiveHint). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear structure: purpose, usage, inputs, effects. Every sentence adds value, and the most important information is front-loaded.
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 read-only diagnostic purpose and the presence of an output schema, the description covers all essential aspects: what it validates, when to use, inputs, and side effects. No gaps remain for an agent to select and invoke the tool 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 schema coverage is 100% and the schema clearly describes source and file, the description misleadingly mentions 'projectIndex enables cross-file checks; platform filters rules' which are not present in the input schema. This inaccuracy reduces the helpfulness for 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 clearly specifies the tool validates Swift source against Axint's Apple-specific build-time rules (AX700–AX749) including Swift 6 concurrency and Live Activities. It distinguishes from siblings by explicitly mentioning pairing with swift.fix for repairs and contrasting with other 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 provides clear context for use: 'use on generated or edited Swift before build' and recommends pairing with swift.fix for mechanical repairs. It could be improved by explicitly stating when not to use the tool, but the guidance is solid.
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 indicate idempotentHint=true and no destructiveness. Description adds that it updates local coordination claims under .axint/coordination with no network, and that agentId filters releases. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, context/use, input behavior and effects. Front-loaded, 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?
For a tool with 5 optional parameters, full schema coverage, and output schema, the description covers purpose, usage, parameter behavior, effects, and context. No 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. Description adds value by explaining how 'agent' and 'files' interact (releases only matching claims unless files narrow), and notes default output format. Exceeds 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 clearly states the tool releases active local Axint file claims after finishing or abandoning a task. It distinguishes from sibling tools by referencing agent.claim and agent.advice.
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 to use after finishing or abandoning a task, and to use agent.claim before edits. Suggests alternatives (agent.advice). Could mention when not to use, but context is strong.
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, destructiveHint, idempotentHint. Description adds return format, diagnostics on failure, and confirms no files/network. 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?
Two paragraphs, front-loaded with main purpose. Each sentence adds value, though the second paragraph mixes use cases and effects. Minor structural improvement possible.
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?
Covers compilation, return types, diagnostics, and effects. Output schema exists (not shown), so return format detail is a bonus. No major gaps given complexity.
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 coverage is 100% so baseline 3. Description adds context for format, fileName, emitInfoPlist, emitEntitlements, but mentions 'sandbox' which is not in schema, causing minor confusion. Adequate but not exceptional.
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 TypeScript DSL into native Swift code, names the specific function (defineIntent()), and distinguishes it from siblings like validate for preflight. The verb 'compile' and resource are specific.
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 when TypeScript DSL source should become Swift; use validate for cheaper preflight only.' Also clarifies no files written and no network requests, setting clear boundaries.
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?
Description discloses effects (writes .axint/context unless dryRun=true, reads local files only) beyond annotations which already indicate idempotency, non-read-only, non-destructive. No contradictions. Adds context about file-writing behavior.
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?
Four well-structured sentences: general purpose, use cases, inputs, effects. Front-loaded with key info. No redundant words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description doesn't need to explain returns. It sufficiently covers inputs, effects, and usage context. Annotations supply safety info. Complete for tool complexity with 6 optional params.
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 descriptions, baseline 3. Description adds meaning by explaining changedFiles seeds discovery and dryRun returns pack without writing. This enhances understanding beyond schema for key parameters.
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 scans an Apple project and writes a compact context pack. It uses specific verbs (scan, write) and names the resource (.axint/context pack). It distinguishes from single-file reasoning and mentions specific use cases like multi-file SwiftUI work, setting it apart from siblings such as axint.project.pack.
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:' section lists scenarios (before project-aware repair, multi-file SwiftUI, interaction-risk analysis). Does not mention when-not-to-use or alternatives, but context is clear. No exclusion criteria provided.
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 that the tool starts child processes, writes .axint/run artifacts, may run xcodebuild/tests, and may call Cloud Check. This adds valuable context beyond the annotations, which indicate openWorldHint=true and destructiveHint=false, and does not contradict them.
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 (three sentences) and front-loaded: purpose first, then usage guidance, then key effects. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (32 parameters, no required, output schema exists), the description covers the essential purpose, usage, and side effects. It does not detail return values, but that is handled by the output schema. Minor gap: could mention output format options, but schema documents them.
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 baseline is 3. The description adds minimal extra meaning beyond the schema for the majority of the 32 parameters, though it highlights a few (integration, background, outputDir). No significant additional semantics.
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: 'Run the enforced Axint Apple build loop outside the Xcode UI.' It specifies that it is for the complete proof loop and distinguishes it from siblings like swift.validate, cloud.check, and fix-packet for single-stage needs.
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 tool for the complete proof loop, and use other tools (swift.validate, cloud.check, fix-packet) when only one stage is needed. Key parameter behaviors (integration, background, outputDir) are also explained.
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 declare readOnly, idempotent, non-destructive. Description adds specifics: 'read-only built-in compiler smoke test; writes no files and uses no network', confirming and extending annotation hints.
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 concise sentences front-loaded with action and purpose. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
All relevant information included: when to use, effects, input semantics, and behavioral traits. Output schema exists so return value explanation is unnecessary.
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 covers parameter fully. Description adds that format 'changes rendering only' and the test has no project inputs, providing context beyond the enum description.
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 it runs a source-free compiler smoke test through the real Axint pipeline. It distinguishes itself from siblings like validate and run by specifying 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?
Explicitly advises using immediately after install or first MCP connection, and contrasts with validate/run for project checks. Provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, and the description adds behavioral context: 'reads local Axint context/proof and may refresh advice artifacts; no network.' This discloses side effects and safety profile beyond annotations. A slight deduction for not detailing what 'refresh advice artifacts' entails exactly.
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, well-structured into a purpose statement, usage case, and input/effects sections. No extraneous words, front-loaded with key 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 existence of an output schema, the description does not need to explain return values. It covers purpose, inputs, effects, usage guidelines, and distinguishes from siblings. Complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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: 'cwd selects local context' and 'changedFiles...to detect claim conflicts.' There is a minor mismatch: description mentions 'question and modifiedFiles' while schema uses 'issue' and 'changedFiles', but overall it enhances understanding.
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: 'Ask the local Axint project brain what this agent should do next.' It specifies the verb (ask/reads/returns), the resource (Axint project brain), and distinguishes from siblings like 'suggest' and 'repair'.
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 provides when to use this tool vs alternatives: 'use when local proof should choose the next move; use suggest for greenfield ideas and repair for known bugs.' It also lists inputs and effects, giving clear context.
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, destructiveHint. Description adds valuable context: 'Effects: read-only local registry search using AXINT_REGISTRY_PATH or sibling checkout; no network by default.' 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise multi-sentence description with key info front-loaded. No unnecessary words. Every sentence adds value: purpose, usage, inputs, effects.
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?
Complete for a search tool with output schema present. Covers purpose, when to use, parameter semantics, behavioral effects, and notes on network and registry path. No 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% with descriptions. Description adds extra semantics: 'query drives ranking; kind and platform narrow results without changing the registry source.' Provides context beyond 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?
Clearly states verb 'search' and resource 'Axint Registry' with 'natural-language query' input. Explicitly distinguishes from siblings like axint.feature and axint.compile by stating to use before them.
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 when-to-use: before axint.feature or axint.compile to find existing packages. Includes exclusion: 'not for validating local Swift'. Gives context that kind and platform narrow results without changing source.
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?
Description states 'read-only Swift generation; writes no files and uses no network,' which aligns with annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false). Adds context on safety and side effects 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: main action, capabilities, usage. No wasted words; front-loaded with key 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?
Covers purpose, alternatives, token efficiency, and side effects. With a rich schema and output schema present, the description provides sufficient context for correct tool selection.
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 detailed parameter descriptions. The description adds token-budget context and clarifies parameter roles (e.g., 'body: View/widget only'), but the schema already provides comprehensive 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 compiles a minimal JSON schema to Swift, bypassing TypeScript DSL. It specifies supported outputs (intents, views, components, widgets, apps) via the 'type' parameter, and distinguishes from sibling tools like axint.compile and axint.scaffold by naming them directly.
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: 'use for token-light JSON-to-Swift generation; use compile for full TypeScript DSL control and scaffold for TS starters.' This tells the agent when to choose this tool over 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?
Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds context: 'read-only template source; writes no files and uses no network'. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each purposeful: purpose, return value, usage, inputs/effects. No fluff, well structured with clear progression.
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?
With output schema present, return value description is sufficient. Explains what the returned string is ('complete, compilable defineIntent() file') and its relation to compile. Covers purpose, usage, parameters, effects.
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?
Single parameter 'id' has schema description coverage 100%. Tool description repeats schema details (case-sensitive, kebab-case, from templates.list) without adding new meaning beyond reinforcement, but is consistent.
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?
Clearly states verb 'Retrieve' and resource 'full TypeScript source code of a specific bundled template by id'. Distinguishes from sibling 'axint.templates.list' which lists templates.
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 after templates.list to fetch a complete reference template; edit it before calling compile'. Also specifies that 'id must come from templates.list'.
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?
Description adds details beyond annotations: destructive effects when apply=true (package installs, refresh Xcode wiring, write .axint/upgrade, may use npm). 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?
Well-structured with front-loaded purpose, then usage, inputs, effects. Slightly long but each sentence adds value.
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 7 params and destructive behavior, the description covers purpose, usage conditions, parameter roles, and effects. Output schema exists but not needed in 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 3. Description adds value by grouping parameters (e.g., 'matter only when applying') and noting defaults (apply defaults false).
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 'Check' and 'apply', the resource 'Axint package', and distinguishes from sibling tools by specifying 'not for app dependency upgrades'.
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 tells when to call: 'when axint.status shows a stale server' and what not to use for: 'not for app dependency upgrades'.
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?
With no annotations providing behavioral hints, the description effectively discloses key effects: writes .axint/guard proof, may start a session, and does not edit app source or use network. It could explicitly mention idempotency or safety, but the current disclosure is strong.
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 (three sentences) and well-structured: first sentence states purpose, second covers usage guidelines, third details effects and inputs. Every sentence provides essential information without 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 (14 optional parameters, many siblings, output schema exists), the description covers all necessary aspects: purpose, when to use/alternatives, behavioral effects, and input hints. The output schema handles return value explanation, so nothing is missing.
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 descriptions for each parameter. The tool description adds value by explaining the purpose of key parameters (e.g., 'stage selects the gate', 'modifiedFiles and notes narrow drift checks', 'autoStartSession defaults true'), enhancing 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 guards against context compaction and Axint drift, specifying checks on project memory files, active session, and freshness. It distinguishes from sibling tools by explicitly mentioning 'use workflow.check' as an alternative for different needs.
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: 'call around long Xcode tasks, context recovery, broad Swift edits, or before claiming runtime proof'. It also advises when to use workflow.check instead, offering clear guidance on 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?
Annotations declare readOnlyHint, idempotentHint, and destructiveHint. The description adds context: 'read-only inspection; writes no files; no auth or network required,' which goes beyond annotations and is consistent.
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 somewhat verbose but well-structured: first sentence audits the purpose, then usage, parameters, effects. It is front-loaded and each sentence adds value, though could be slightly more concise.
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?
Covers inputs, usage, effects, and safety. With output schema present and annotations providing mutability/idempotency, the description adds the critical 'no auth/network' detail, making it complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 schema: 'cwd selects the project' and 'expectedVersion turns a runtime mismatch into a blocker,' providing useful context about parameter behavior.
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 audits Axint runtime and project wiring, listing specific files and checks. It distinguishes from siblings by explicitly mentioning when to use this tool versus 'run' for build proof.
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 scenarios: 'Use this when an agent might be connected to a stale Axint process or when a new project needs first-try MCP setup proof.' Also names the sibling 'run' as an alternative for build proof, guiding the agent on 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?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds specific behaviors: no files written, no network requests, returns error string on invalid domain values, and output compiles with axint.compile. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that front-loads the main action. It is concise but could be slightly more structured (e.g., bullet points for use cases). Still, every sentence serves a purpose and no 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?
Given the tool's simplicity and the presence of an output schema (implied), the description covers return type, behavior, error handling, and relationships to sibling tools. It provides enough context for an agent to use it 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 extra guidance: 'name must be PascalCase', 'params define the starter contract', and 'domain defaults to general', which improves usability 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 'generate a starter TypeScript intent file' and returns a source string, distinguishing it from siblings like 'axint.compile' and 'axint.templates.get' by noting alternatives for richer examples or 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?
Explicitly says 'use to create a small TypeScript intent starter' and contrasts with 'templates.get for richer examples and compile for Swift output', giving clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds beyond annotations: 'read-only diagnostics; writes no files and uses no network,' plus details on diagnostic rules (134) and output format. 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?
Front-loaded with key purpose and usage. Slightly verbose but all sentences earn their place. Could be slightly tighter.
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?
Output schema exists; description complements it by detailing diagnostic JSON structure. No gaps in coverage for a validation tool with clear inputs and outputs.
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 the single 'source' param. Description adds important nuance: 'Must be a complete file starting with an axint import, not a code fragment,' which is not in the schema description.
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?
Clearly states 'Validate a TypeScript intent definition without generating Swift.' Distinguishes from siblings like axint.swift.validate and axint.compile. Specific verb+resource.
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 guidance: 'use for TypeScript DSL diagnostics before Swift output; use swift.validate for existing Swift.' Also mentions when inputs are appropriate and effects.
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 all side effects: writes file, may create directories, validates Swift, records guard/check artifacts. Annotations provide no contradiction; description adds meaningful 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?
Front-loaded with purpose, uses structured sentences. Slightly wordy but no redundant information; each sentence adds value.
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 high schema coverage and existing output schema, description covers use case, inputs, and effects completely. No gaps for an AI agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. Description adds value by stating defaults for createDirs, validateSwift, cloudCheck (default true) and path constraint (must be inside cwd).
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?
Clearly states the tool writes files in Xcode project via the Axint guard path. Specifically distinguishes from raw XcodeWrite, indicating a guarded, validated write with proof recording.
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 (during long tasks, for Xcode-project files) and when not (outside Xcode, patch normally and validate after). Provides clear 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?
Description details effects: 'writes .axint/agent, context, and coordination files; no network', which aligns with annotations (idempotentHint=true, destructiveHint=false). Adds behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-loading the core purpose, usage, and effects. No wasted words; every sentence adds value.
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?
Covers purpose, usage, effects, and parameter roles. With an output schema present, no need to detail return values. Complete for an installer tool.
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% parameter descriptions, but description adds functional context like 'cwd scopes local coordination' and 'projectName and hosts shape generated project-brain files', providing meaning beyond 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 'Install the local Axint multi-agent project brain' with specific verb and resource. It lists the files written, distinguishing it from sibling tools like axint.compile by noting 'not needed for one-off compile'.
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 once per project to create local multi-agent coordination; not needed for one-off compile', providing clear when-to-use and when-to-avoid 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 already declare readOnlyHint=true and destructiveHint=false. The description adds 'Effects: read-only local run/job inspection; writes no files and uses no network,' providing extra 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each serving a distinct purpose: purpose, usage guidance, and effects. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
All parameters are documented in schema, output schema exists, and description covers use case, behavior, and constraints. For a read-only inspection tool, it is fully complete.
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 parameter descriptions. The description adds that 'jobId selects a background run' and 'includeLogs changes returned detail' which adds meaning, though there is a slight mismatch: schema uses 'id', 'cwd', 'format' while description mentions 'jobId' and 'includeLogs'.
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 'Read the latest or selected Axint run job record' with a specific verb and resource. It also mentions 'including active child process IDs', and the distinction from siblings like axint.run and axint.run.cancel is clear from the context.
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: use after MCP timeouts or long builds to inspect or rejoin; it does not start, rerun, or cancel work.' This provides clear context and exclusions.
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 mark readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds further value by stating 'read-only; writes no files; no auth or network required', which goes beyond annotations to clarify operational characteristics. 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?
The description is three sentences, each adding distinct value. It starts with the core purpose, then usage guidance, then behavioral notes. 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?
Given the tool's simplicity (status report), the description covers all relevant aspects: what it returns (version, path, uptime, tool count, instructions), usage context, and behavioral effects. The presence of an output schema further reduces description burden.
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 1 parameter with 100% description coverage and enum. The description adds 'format changes rendering only' which clarifies the parameter's purpose and notes that no project path is required. This provides useful context beyond the schema's description.
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 the tool reports the running Axint MCP server version, package path, uptime, registered tool count, and reload/update instructions. It clearly distinguishes from sibling tools like axint.doctor or axint.upgrade by specifying it answers the connected server version, not a guessed npm/PyPI version.
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 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'. This clearly guides the agent on appropriate context.
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

Copy to your README.md:

[![axint MCP server](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](https://glama.ai/mcp/servers/agenticempire/axint/badges/score.svg)](https://glama.ai/mcp/servers/agenticempire/axint)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/agenticempire/axint'

If you have feedback or need assistance with the MCP directory API, please join our Discord server