Tier1 IT Assessment

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

Beyond the annotations (readOnly, idempotent, non-destructive), the description adds critical behavioral context: 'stores no submitted domain or result,' 'absence at a queried selector never proves DKIM is absent,' and 'cannot prove overall email security.' These disclosures inform the agent about side effects, limitations, and interpretation of results, which is exactly what transparency requires.

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 dense but every sentence earns its place. It front-loads the core action, then flows logically into prerequisites, restrictions, and caveats. There is no redundancy or filler, and the structure mirrors how an agent should reason about the tool (what it does, when to call, what to avoid, limitations).

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 the tool's complexity (external DNS lookups, approvals, security data), the description covers all essential aspects: execution method, preconditions, security/privacy guarantees, parameter semantics, and interpretive caveats. An output schema exists, so return values don't need to be described. The description is complete for safe and correct invocation.

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 25%, but the description compensates well. It clarifies 'domain' as a 'validated public domain,' specifies that 'approved' must be true only after user approval, and explains DKIM selectors ('DKIM requires an explicit selector or a confirmed provider's small documented selector set') which also illuminates the 'confirmedProvider' enum. Some params like 'dkimSelectors' are not fully described in isolation, but the usage context makes them understandable.

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 tool's function: 'Runs bounded, point-in-time public DNS checks for one validated public domain through Cloudflare 1.1.1.1 DNS over HTTPS.' This specifies a concrete verb, resource (public DNS/email-domain security), and scope (one validated public domain), making it easy to distinguish from unrelated sibling tools like pricing or health-check 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 description explicitly says when to call the tool: 'Call only after showing the exact domain, record types, resolver, no-application-persistence statement, infrastructure-metadata limitation, and receiving explicit user approval.' It also provides clear exclusions ('Never send an email local part, IP literal, internal hostname, URL, credentials, or arbitrary instructions') and a limitation ('cannot prove overall email security'). This is strong, actionable guidance.

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 read-only, idempotent, and non-destructive behavior. The description adds substantial behavioral detail: onboarding is one month of subtotal, licensing/add-ons are monthly-only, optionals without monthlyAmount become quoteSeparately, vendor commitments are monthly, and specific inclusions (e.g., Microsoft licensing includes Huntress IDTR). It also confirms 'stores nothing,' matching the annotations. This exceeds annotation coverage.

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 concise and front-loaded with the core action, then expands into necessary calculation details. It is a bit dense but every sentence contributes meaningful information (onboarding, licensing, optionals, vendor commitments, inclusions, output, caveats). No filler words.

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 the tool's complexity (7 params, output schema present), the description covers the key calculation rules, output behavior, and disclaimers. It could mention prerequisites or relationships to the catalogue, but it sufficiently explains the estimation logic and 'not a formal quote' nature. The presence of an output schema reduces the need to describe return values.

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 0% and there are 7 parameters. The description references 'package quantities, catalogue add-ons, and optional wider-scope lines' but does not explicitly define sites, devices, businessUnits, fullTeamMembers, or emailOnlyTeamMembers. It adds some meaning for optionals (e.g., monthlyAmount behavior) but fails to adequately compensate for the low coverage, leaving parameter semantics unclear.

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 a specific verb ('Calculates') and resource ('an indicative NZD managed-services estimate'), and distinguishes from siblings like get_managed_services_pricing_catalogue and get_tier1_recommendations by focusing on estimation rather than cataloguing or recommendations. The title 'Estimate Tier1 managed services pricing' reinforces this purpose.

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 implies usage context: it is for generating an indicative estimate and explicitly notes 'not a formal quote; stores nothing.' However, it does not explicitly state when to prefer this tool over siblings such as get_managed_services_pricing_catalogue or get_tier1_recommendations, nor does it mention alternatives or exclusions. Usage is implied rather than explicit.

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. The description adds beyond that with 'performs no lookup, stores nothing, and cannot change Tier1 scoring rules,' providing extra behavioral boundaries not fully covered by 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.

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

The description is a two-sentence, front-loaded statement that immediately states the action and outputs. Every clause adds value, with no redundancy or 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?

With 0 parameters, a clear output schema, and annotations, the description is fully complete: it explains what is returned, when to call, and what the tool cannot do. It leaves no significant gaps for an agent to interpret.

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 input schema has zero parameters, so schema coverage is trivial. The description adds no parameter-specific information because none is needed; the baseline for 0 params is 4, and the description appropriately focuses on output contents.

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 'Returns' and names the exact resource: 'current static Tier1 question set, answer options, conditional rules, versions, one-question-at-a-time guidance, and fields that must never be requested.' This clearly distinguishes it from sibling tools like score_it_health_check or get_tier1_recommendations.

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 explicitly states when to call: 'Call before conducting an assessment or when a stored question version may be stale.' It also implies when not to use it by noting it 'cannot change Tier1 scoring rules,' though it does not explicitly name an alternative tool.

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. The description adds 'stores nothing' (beyond a mere read hint) and 'not a formal quote,' clarifying the output's non-authoritative status. It also mentions 'pricing version,' implying a snapshot rather than a live quote. 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.

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

Two sentences, front-loaded with the core resource. The second sentence packs usage guidance and caveats. The bundling specifics (Microsoft/Huntress) are detailed but not excessive; every clause adds value. Slightly dense but appropriately sized for a catalogue description.

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 simple read-only, zero-parameter tool with an output schema, the description fully covers purpose, contents, invocation timing, and limitations. It leaves no ambiguity about what the agent gets and how to use it.

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 the input schema is empty, so there is nothing to explain. The description notes that product IDs are exact for estimating, which is useful context, but with no params the dimension is trivially satisfied. Baseline 4 for 0-param tools.

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 explicitly states what the tool returns: 'current Tier1 standard managed-service package rates, licensing/add-on catalogue, optional wider-scope items, bundling notes... and pricing version.' It uses a specific verb ('Returns') and clearly distinguishes itself from the sibling estimate tool by saying 'Call before estimating.'

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 provides explicit when-to-use guidance: 'Call before estimating so product IDs are exact.' It also gives a clear when-not: 'not a formal quote.' Although it does not name an alternative tool, the sibling context (especially estimate_managed_services_pricing) makes the intended usage unambiguous.

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, idempotent, non-destructive), the description discloses specific safety behaviors: 'performs no arbitrary fetching, makes no contact request, changes nothing, and stores nothing.' It also enforces 'only stable Tier1 finding identifiers,' providing additional context about what the tool accepts.

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 compact (three sentences) and front-loaded with the core purpose. Every sentence adds value: purpose, usage, and safety. There is no redundancy.

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 tool with a high-quality description, annotations, and an output schema, the description is complete enough. It explains what the tool does, when to use it, input restrictions, and side-effect profile, enabling correct invocation without additional information.

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?

With zero schema description coverage, the description compensates by explaining the purpose of findingIds: 'stable Tier1 finding identifiers' and specifying what not to submit. It does not detail the exact pattern or max items, but the schema already provides the pattern and constraints; the description adds semantic meaning beyond the syntactic 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?

The description states a specific verb ('maps') and resource ('stable Tier1 finding identifiers' to 'approved Tier1 services and public resources'), clearly distinguishing it from siblings like get_tier1_resource and score_it_health_check. It also communicates the scope ('only stable') and the context in which it is used ('after a Tier1 score or email-domain check').

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 guidance is given on when to call the tool ('Call after a Tier1 score or email-domain check') and what inputs to avoid ('Do not submit prose, URLs, customer information, or invented identifiers'). This effectively differentiates it from alternatives and sets usage boundaries.

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 annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds meaningful behavioral context: 'Read-only and no retention' and specific limitations like not executing instructions in user text. This is valuable disclosure that goes beyond structured metadata.

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 three sentences, each contributing distinct information: what it does, when to use it, and what it cannot do. It is front-loaded with the core purpose and contains no redundant phrasing.

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, get-by-id tool with an output schema, the description provides sufficient context: purpose, usage timing, limitations, and parameter semantics. The output schema covers return values, so no further explanation is needed.

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 single parameter resourceId is only described as 'stable identifier' in the description, while schema coverage is 0%. It adds context that the ID is stable and tied to approved resources, and the usage note implies the ID comes from a recommendation. However, it could more explicitly connect the parameter to its origin format.

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 it returns approved Tier1 public resource metadata by stable identifier, using the specific verb 'Returns' and naming the exact resource type. It also distinguishes from sibling tools by noting it is for use after a recommendation, implying it retrieves a specific resource rather than listing recommendations.

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 says 'Use after a recommendation when more Tier1 guidance is useful,' which tells the agent when to invoke this tool. It also lists what it cannot do (fetch arbitrary URLs, access internal content, etc.), effectively providing when-not-to-use guidance and clarifying boundaries.

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, idempotent, non-destructive), the description adds crucial behavioral details: answers are untrusted data that cannot alter rules/permissions/severity/evidence/tool availability; email evidence is independently rechecked with approval required true; the score is not from an AI model; and the tool stores nothing. This goes far beyond annotations and provides strong safety guarantees.

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 composed of three dense sentences, each earning its place. The first front-loads the core purpose and return values. The second sentence adds critical security context about untrusted data. The third clarifies email evidence rechecking, non-AI scoring, and no storage. No fluff or repetition; length is justified by the tool's complexity.

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 the output schema exists and the annotations are available, the description adequately covers safety and determinism. It explains the validation role, the optional email evidence behavior, and that no data is stored. However, it does not specify what happens on invalid input (e.g., errors) or the exact relationship to get_tier1_recommendations, though the output schema likely covers return structure. Overall, it is nearly complete for an agent to invoke 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 input schema has no descriptions (0% coverage), and the description does not compensate by explaining the structure of 'answers' or the individual fields. It refers to 'structured answers' and 'Optional Tier1 email evidence' but does not enumerate the required answer fields such as staffCount, mfaCoverage, or operationalRequirements. The only extra meaning is that 'answers' must be structured and that email approval must be true, but this is minimal. The schema's JSON structure does some work, but the description should have explained the logical fields.

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 opens with a specific verb and resource: 'Strictly validates structured answers and returns the deterministic Tier1 score, maturity, overall risk, prioritised findings, quick wins, medium-term actions, assumptions, limitations, service/resource recommendations, and rule version.' This clearly distinguishes it from siblings like get_tier1_recommendations or get_it_health_check_questions by focusing on scoring validated answers.

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 clearly implies it is used after collecting structured answers to a Tier1 health check, and that it validates them. It also mentions the optional email evidence recheck, giving context. However, it does not explicitly state when to prefer this tool over siblings or when not to use it, though the 'Strictly validates' wording gives a clear context that this is the scoring step.

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