AI MAXX Public Passports

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds useful behavioral context by specifying the exact contents returned (countries, companies, counts) and that they are the live catalogue contents rather than a static list.

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

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

Two sentences, zero waste, and the purpose is front-loaded before the usage hint. Nothing is redundant with the title or annotations.

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 zero-parameter read tool with no output schema, the description sufficiently explains what the call returns. It could note the response shape or that results may change over time, but an agent has enough to call it correctly.

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

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

The tool takes zero parameters, so the baseline is 4; there is no parameter syntax for the description to explain.

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?

States a specific verb (read) and resource (countries, companies, record counts in the AI MAXX catalogue), plus the scope 'currently included'. This distinguishes it from the consult_* and search_* siblings, which retrieve content rather than inventorying what exists.

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

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

Explicitly frames the when-to-use case: checking geography coverage 'before searching'. It gives clear context but does not name a specific alternative tool or state exclusions, so it falls short of the 5 benchmark.

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

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

Annotations already declare readOnly, openWorld, non-idempotent and non-destructive. The description layers on genuinely useful behavioral context: coverage is the published catalogue not the whole web, these are enquiries not confirmed seasonal dates, it does not book or charge, and it returns source facts, photos, opening info, maps and an enquiry link. Funded model provider (AI MAXX) is also disclosed.

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 content is dense and largely example-driven; the actual purpose is buried behind two sentences of activity and seasonal-event examples. Every sentence is informative, but the front-loading is poor and the prose reads as a run-on block rather than progressive disclosure.

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

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

With no output schema, the description carries the return burden and does so by naming what comes back (source facts, photos, opening info, maps, enquiry link). It also covers coverage limits, follow-up behavior and the non-booking nature, leaving only the limit parameter unexplained.

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

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

Schema coverage is 75%, so the schema already documents query, country_code and response_depth. The description adds guidance on preserving the requested location and indoor/outdoor preferences/constraints and on reuse in follow-ups, but it never mentions the limit parameter or adds anything beyond the schema for response_depth.

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 verb+resource is present – it asks an AI specialist to interpret a customer need and select relevant published services from the catalogue. However, it opens with a raw list of activity examples (laser tag, Prison Break, VR) rather than a purpose statement, and it never explicitly contrasts itself with the sibling consult_events/consult_venues/consult_hospitality tools, only names get_passport.

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?

It gives clear context for use (interpret a direct or indirect need, preserve location and indoor/outdoor preferences) and routes follow-ups explicitly: refine the need after clarification, or use get_passport for full details. It also states the sending constraint (nonpersonal need only). It stops short of stating when NOT to use it versus the other consult_* siblings.

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

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

Annotations already declare readOnlyHint, destructiveHint, openWorldHint and idempotentHint. The description adds meaningful context beyond that: it names the AI MAXX model provider, states the coverage is the published catalogue rather than the whole web, clarifies it does not book or charge, and gives a privacy rule ('Send only the nonpersonal need... never conversation history or contact details'). This is richer than typical, though it stops short of covering idempotency or rate limits.

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 front-loaded with the event types and core purpose, which is good. However, it is a long single paragraph that repeats the same event examples twice ('staff party, Halloween prison experience, Christmas team dinner...') and could be tightened. Several sentences are useful but the overall length and repetition reduce efficiency.

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

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

Given no output schema, the description explains what the tool returns (source facts, photos, opening information, maps, enquiry link). It also covers provider, coverage limits, booking/charging limitations, and a follow-up path. The main gap is the lack of any parameter guidance, especially for the undocumented 'limit', but otherwise the definition is complete for this complexity level.

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

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

Schema description coverage is 75%, so most parameters (query, country_code, response_depth) are documented in the schema. The description adds no parameter-level meaning at all, and the 'limit' parameter has no schema description, leaving it undocumented. Since the description does not compensate for the one uncovered parameter, it adds little beyond what the schema already provides.

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

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

The description uses a specific verb (interprets a need and selects relevant published services) and identifies the resource domain (staff parties, celebrations, festivals). It gives concrete examples. However, it does not explicitly differentiate itself from the sibling consult tools like consult_activities, consult_hospitality, or consult_venues, so the agent must infer the boundary.

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?

Usage is implied through examples and a follow-up instruction ('Follow up with a refined need after clarification'), and it points to get_passport as an alternative for full details. But there is no explicit guidance on when to choose this tool over the other consult siblings, leaving usage context partly to inference.

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

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

Beyond the annotations (readOnly, openWorld, idempotent=false, non-destructive), it discloses that it does not book or charge, that coverage is the published catalogue rather than the whole web, that it uses the AI MAXX model provider, and a privacy rule (send only the nonpersonal need, never conversation history or contact details). That is substantial context an agent needs, though the privacy and provider facts are scattered rather than structured.

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 long and mixes purpose, examples, privacy rules, provider notes and return values into undifferentiated prose. The example list ('Halloween prison experience', 'prison-cell photography') is tangential noise that competes with the actual scoping information.

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

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

With no output schema, the description usefully states what is returned (source facts, photos, opening information, maps, enquiry link) and flags the 'not confirmed seasonal dates' limitation. Privacy handling, model provider and the no-booking boundary are covered, so an agent has enough to call it correctly, though the scattered structure weakens clarity.

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

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

Schema coverage is 75%, so most parameters are already documented. The description reinforces the query semantics ('send only the nonpersonal need and relevant constraints') and the follow-up reuse rule, but adds nothing about limit, country_code or response_depth beyond what the schema already says. Baseline 3 is appropriate.

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

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

The description names a concrete verb+resource (find/select published dining, BBQ and food-court services) and gives named anchors like Pavilion dining and Kordin BBQ, so an agent can distinguish it from consult_venues or consult_events. The core purpose is clear, though it is buried under several auxiliary sentences.

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?

It gives a follow-up path ('refined need after clarification') and routes to get_passport for full details, which is explicit alternative guidance. However it never contrasts itself against the other consult_* siblings (activities, events, venues) or states when this food-first tool is the wrong choice.

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

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

Annotations cover the safety profile (readOnly, non-destructive, open-world, non-idempotent), and the description goes well beyond them: discloses the AI MAXX provider, that coverage is the published catalogue rather than the whole web, that results are enquiries rather than confirmed dates, what is returned (facts, photos, opening info, maps, enquiry link), and a data-handling rule about not sending conversation history or contact details.

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?

Dense and front-loaded with the domain and examples first, then behavior and constraints. Every sentence carries information, though the example list and repeated caveats make it longer than strictly needed.

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?

No output schema exists, and the description compensates by describing the returned artefacts and next step. For an open-world, non-idempotent consultation tool, provider, coverage boundaries, data-handling rules and the no-booking caveat are all present, so an agent has everything needed to call it correctly.

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

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

Schema coverage is 75%, with query, country_code and response_depth already documented in the schema. The description adds meaningful semantics for the query parameter — it must be a nonpersonal need with constraints, and known constraints should be reused on follow-up — plus language handling and the instruction to respect the requested use. `limit` remains undocumented anywhere.

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?

Names a specific resource (venue hire, film/TV production spaces, historic prison photography) and the verb — interpreting a customer need and selecting relevant published services. It is clearly distinct from consult_activities/consult_events/consult_hospitality by domain, though it never explicitly contrasts itself with those siblings.

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?

Gives real usage context: send a direct or indirect customer need, follow up with a refined need after clarification, or use get_passport for full details, and states it does not book or charge. It stops short of explicit when-not-to-use routing against the other consult_* siblings.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered by structured data. The description adds real context beyond that: the enumerated exclusions (customer accounts, enquiries, private drafts, payment records) tell the agent the access boundary of a 'public' read, which prevents over-reaching calls.

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

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

Three short sentences, front-loaded with the action and resource, followed by return content and scope exclusions. No restatement of the title and 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 single-parameter read tool with a complete annotation set and no output schema, the description covers action, input provenance, return shape ('published facts and provenance') and access boundaries. The only omission is any hint of error behavior when an id is unpublished or unknown.

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

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

Schema description coverage is 0%, so the description must compensate for the single documented-free parameter. It does so meaningfully by defining the id as an 'exact id returned by search_passports', which tells the agent both the source and that fuzzy/partial matching is not supported; it does not add length or format detail, hence not a 5.

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?

States a specific verb and resource ('Read one public AI MAXX passport') and scopes it ('public', 'one'), which cleanly distinguishes it from search_passports. The follow-on sentence specifies what is returned, so an agent knows exactly what class of operation this is.

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 names the sibling that supplies the required input ('an exact id returned by search_passports'), which is an explicit routing instruction, and adds a negative scope boundary. It stops short of stating when NOT to call it (e.g. for drafts or unpubished passports, only that those data are not accessed).

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful behavior: it returns preassembled published facts, photos, routes and enquiry links with no model round trip, and explicitly states there is no live booking or payment. That 'no round trip / no booking' disclosure is the kind of context annotations cannot carry.

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?

Front-loaded with the core purpose before the examples and constraints. The three-scenario clause is dense and somewhat list-like, but each scenario earns its place by mapping to a valid intent value rather than padding.

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

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

With no output schema, the description carries the return-value burden and does so by enumerating the payload (facts, photos, routes, enquiry links). Both required parameters are accounted for and the closed-world/geography constraint is stated, though a note on what happens for unsupported country codes would close the last gap.

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

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

Schema coverage is 50% and only country_code carries a schema description, but the description compensates by decoding the opaque intent enum values into plain-language scenarios (staff party with activity and food at Kordin; Halloween prison photos and BBQ; indoor laser tag and VR in St Julian's) and by reinforcing the Malta-only geography restriction on country_code.

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?

Names a specific verb (get) and resource (quick recommendations) and immediately grounds it in three concrete route scenarios that map to the intent enum values. The closing line about 'preassembled published facts' and the routing to a specialist consultant makes it clearly distinguishable from the consult_* and catalogue_* siblings.

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?

Gives explicit when-to-use ('fast first choice for a matching common need'), a hard boundary ('use only if the specific route fits the customer geography and constraints; never substitute another country or unwanted activity'), and a fallback ('for other needs or exclusions use a specialist consultant'). It stops short of naming which specific sibling tool to fall back to, leaving the agent to pick from consult_activities/consult_events/consult_venues.

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

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

Annotations already declare readOnly/openWorld/non-destructive, but the description adds real behavioral context beyond them: it is AI-model-backed, its coverage is limited to the published catalogue rather than the whole web, it cannot book or charge, and it imposes a privacy constraint on what may be sent. That is meaningful disclosure for an LLM-backed tool.

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?

Purpose is front-loaded in the first clause, and the privacy/scope caveats close it out efficiently. The example list ('Halloween prison experience', 'prison-cell photography') is slightly decorative but does clarify the domain and breadth of acceptable needs.

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

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

With no output schema, the description compensates by summarizing returns (source facts, photos, opening info, maps, enquiry link) and by covering privacy, iteration, and non-booking behavior. The main remaining gap is alternative-selection guidance against the consult_* siblings.

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

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

Schema coverage is 75% (only 'limit' lacks a description), so baseline is 3. The description adds genuine meaning by stating what the query must and must not contain (nonpersonal need plus constraints, never conversation history or contact details) and that constraints should be reused on follow-up, which is not in the schema.

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

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

Specific verb+resource: interprets a customer need and selects relevant published services, with complementary options. It clearly distinguishes itself from get_passport (full details) and states the scope is the published catalogue. It does not differentiate against the consult_activities/consult_events/consult_venues/consult_hospitality siblings, which appear closely related.

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

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

Explicit about when it applies ('enquiries for relevant existing services, not confirmed seasonal event dates') and how to iterate ('follow up with a refined need after clarification') with a named alternative (get_passport). It also states the tool does not book or charge. It gives no routing guidance versus the vertical consult_* siblings, so it falls short of a 5.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior. The description adds genuine value beyond them: what the results contain (source links, review dates, arrival information, availability caveats) and the honesty caveat that availability is not guaranteed. It stops short of describing result shape or result-volume limits.

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

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

Three tight sentences: capability first, return contents second, scope caveat and parameter hint last. Every sentence adds information and nothing is padding.

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?

No output schema exists, and the description steps in by summarizing the return contents, so an agent knows what to expect. The missing pieces are the meaning of limit and any guidance on defaults, which leaves a small gap for a 4-parameter tool.

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

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

Schema coverage is only 50% (kind and limit are undocumented in the schema). The description partially compensates: it names the record kinds (company, service, place) that map to the kind enum and gives a usage rule for country_code. The limit parameter remains unexplained in both places.

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?

States a specific verb (search) plus the exact resource (AI MAXX published company/service/place passports) and the query basis (customer need or business name). The scope statement ('limited to its listed businesses') separates it from a generic web search, though it doesn't name a specific sibling.

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

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

Gives one concrete usage rule ('Specify country_code when the user names a country') and two useful exclusions (not the whole web, no availability guarantee). However, it never routes the agent between this and relevant siblings such as get_passport or resolve_customer_need, so alternative selection is left to inference.

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