AIS Gateway — the campus front desk for AIS MCP buildings

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

With no annotations, the description carries the behavioral burden. It calls out 'FREE' (cost) and states 'where this data comes from' (provenance). It doesn't explicitly state there are no side effects, but for an informational tool the read-only nature is strongly implied.

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

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

One dense sentence that leads with the most decision-relevant trait ('FREE') and packs the full scope into a compact list. No filler.

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

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

For a no-input informational tool, the description covers what the agent gets and the provenance of the data. It is slightly incomplete in not clarifying how this relates to how_to_pay or what output shape to expect, but the lack of parameters keeps the requirements low.

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

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

The tool has zero parameters and schema coverage is 100%, so the description has no parameter burden. Baseline 4 applies because there is nothing to document.

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

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

The description states the tool's subject area precisely: it covers AIS's product catalog, x402 purchasing, and data provenance. It lacks a direct action verb like 'returns' or 'provides,' but the content enumeration makes the purpose unmistakable and distinguishes it from siblings like how_to_pay and list_buildings.

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

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

The description makes the intended use context clear: an agent wanting an overview of AIS offerings and buying options. However, it never explicitly says when to prefer this tool over how_to_pay, and the included 'how agents can buy over x402' clause overlaps with that sibling.

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

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

No annotations are present, so the description carries the behavioral burden. It adds useful context: the guide is free, the Gateway door uses Authorization: Bearer at aislabs.ai/gateway, and x402 uses USDC on Base. It does not explicitly state that the tool is side-effect-free or describe its output shape, but for a zero-parameter informational tool this is only a modest gap.

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

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

The entire description is one efficient sentence with no filler. 'FREE' is front-loaded, and both payment options plus the decision criterion are packed compactly into the em-dash construction. Every word earns its place.

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

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

For a no-parameter, no-output-schema helper, the description provides enough to select and invoke it correctly: it names both payment methods, the authentication style, the settlement token and network, and the existence of a usage rule. The actual 'when to use each' rule is not spelled out, but that is precisely what the tool is intended to deliver.

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

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

The tool takes zero parameters and the schema fully documents this with 100% coverage, so the baseline of 4 applies. The description adds helpful payment context, but no parameter-level semantics are needed.

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

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

The description names the exact domain (payment) and enumerates both options concretely: Gateway key with Bearer auth at aislabs.ai/gateway and per-call x402 with USDC on Base. It lacks an explicit verb like 'returns' or 'explains', but its scope is unmistakable and clearly distinct from the unrelated sibling tools.

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

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

The closing phrase 'and when to use each' explicitly promises a decision rule between the two payment methods, which is the key usage guidance for this informational tool. It does not address when to choose this tool over siblings, but the siblings are on unrelated topics, so this omission is unlikely to cause confusion.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds 'FREE' (a cost/disclosure) and 'which key scope unlocks it' (an authorization/access trait), which go beyond a bare 'list buildings' statement. It does not mention side effects or cleanup, but for a read-only directory listing, this is sufficient. The description enriches the agent's understanding of access and cost without conflicting with any annotations.

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

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

The description is a single, compact sentence that front-loads the most important information ('FREE' and 'campus directory') and packs in every relevant detail: URL, tools, prices, free tier, key scope, and the 'Start here' usage cue. There is zero redundancy or fluff; every word earns its place.

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

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

For a 0-parameter tool with no output schema, the description fully covers what the agent needs to know: it lists every AIS MCP building with its URL, available tools, pricing, free tier, and required key scope. It also gives a strong usage hint ('Start here'). There is no missing information that would prevent correct invocation or interpretation.

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

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

This tool has 0 parameters, and the schema coverage is effectively 100% (since there is nothing to document). Per the calibration guidelines, a baseline of 4 applies. The description does not need to add parameter meaning because there are none; it instead focuses on the output content, which is appropriate.

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

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

The description clearly states the verb ('list') and the resource ('every AIS MCP building'), and then enumerates the exact content: URL, tools, prices, free tier, and key scope. It positions itself as 'The campus directory,' which immediately distinguishes it from the sibling tools about_aislabs and how_to_pay. The agent can confidently know what this tool returns.

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

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

'Start here' gives explicit guidance to use this as the entry point, which implies it should be called before about_aislabs or how_to_pay when the agent needs an overview. However, it does not explicitly name the alternatives or state when not to use it. The guidance is clear for the primary use case but lacks explicit exclusion criteria for the siblings.

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