axint

axint.cloud.check

Read-onlyIdempotent

Run a Cloud Check on Swift or Axint TypeScript source to get Apple-specific diagnostics, verdict, and repair prompts. Provides evidence for UI and runtime claims.

Instructions

Run an agent-callable Cloud Check against Swift or Axint TypeScript source. Accepts inline source or a sourcePath, then returns a Cloud-style verdict, Apple-specific findings, next... Use: use for Apple-aware source review and repair prompts; provide evidence for UI/runtime claims. Effects: read-only response from provided source/path; may use configured Cloud Check endpoint; no source is sent unless provided.

Input Schema

TableJSON Schema

Name	Required	Description
`source`	No	Inline Swift or Axint TypeScript source to check. Prefer sourcePath when possible; inline source should be...
`sourcePath`	No	Optional file path to read and check. Use this from Xcode agents after writing a generated Swift file.
`fileName`	No	Optional display name for diagnostics when passing inline source. Defaults to sourcePath or <cloud-check>.
`language`	No	Optional language override. Omit to infer from file extension and source contents.
`platform`	No	Optional target platform hint. Use macOS to catch common iOS-only SwiftUI modifiers in Mac app work.
`expectedVersion`	No	Optional expected Axint version for this project/session. Cloud Check also reads .axint/project.json when...
`localPackageVersion`	No	Optional local CLI/package version when the caller knows it. Used only for version-truth reporting.
`cloudRulesetVersion`	No	Optional hosted/cloud ruleset version when different from the local compiler package.
`xcodeBuildLog`	No	Optional short Xcode build excerpt. Pass only the failing lines or focused proof summary; full logs should...
`testFailure`	No	Optional short failing unit/UI-test excerpt. Use this when static checks pass but Xcode tests still fail;...
`runtimeFailure`	No	Optional crash, freeze, hang, launch timeout, console, preview, or runtime failure text. Include the...
`expectedBehavior`	No	Optional expected behavior for behavior-gap checks. Pair with actualBehavior when the bug is semantic rather...
`actualBehavior`	No	Optional observed behavior for behavior-gap checks. Pair with expectedBehavior so Cloud Check can return a...
`projectContextPath`	No	Optional path to a local .axint/context/latest.json pack written by axint.project.index. Omit when...
`format`	No	Output format. markdown returns the report, json returns structured data, prompt returns only the repair...

Output Schema

TableJSON Schema

Name	Required	Description	Default
`text`	Yes	Primary Axint tool response text, matching the first text content block.
`isError`	No	Whether Axint marked the tool response as an error.

Tool Definition Quality

A4/5.0

Behavior5/5

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

Annotations already declare readOnlyHint and idempotentHint. The description adds valuable details: 'read-only response', 'may use configured Cloud Check endpoint', 'no source is sent unless provided'. 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?

The description has some verbose elements (e.g., 'next...') and could be more concise. While structured with 'Use:' and 'Effects:', it is not as tight as it could be.

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

Completeness4/5

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

Given 15 optional parameters, no required ones, and an output schema existing separately, the description adequately covers purpose, return types, and effects. It mentions 'cloud-style verdict, Apple-specific findings' which clarifies the output.

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 for each parameter. The description only reiterates that inline source or sourcePath can be used, adding no new semantic insight 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?

Clearly states it runs a Cloud Check against source and returns Apple-specific findings. The verb 'check' and resource 'source' are specific. However, it does not explicitly distinguish from siblings like axint.compile or axint.validate, which are related but different in scope.

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 'Use:' section for Apple-aware source review and repair prompts. Lacks when-not-to-use or alternative tool mentions, but the context is clear enough for most agents.

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

Install Server

Latest Blog Posts

Lightport: Open-Sourcing Glama's AI Gateway
By punkpeye on April 27, 2026.
open source
OpenAI
Tool Definition Quality Score (TDQS)
By punkpeye on April 3, 2026.
mcp
The Hackers Who Tracked My Sleep Cycle
By punkpeye on March 26, 2026.
security

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