ICONIC Intelligence Reserve — Free Agent Assessment

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

The annotations already declare readOnlyHint=true and openWorldHint=false. The description adds that the tool is 'free' and 'stateless', which usefully clarifies that no state is persisted and there is no cost. However, it says nothing about what the assessment process involves, what input data it expects, or how the resulting plan is delivered.

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 definition is a single short sentence with no wasted words, and the key selling point ('free, stateless') is front-loaded. However, the terseness leaves critical concepts undefined, so it is concise but under-specified rather than clear.

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 tool with 7 parameters (5 required) and no output schema, the description is far too thin. It doesn't explain what information the required parameters should contain, what form the 'outcome-linked workflow plan' takes, or how the 'fit assessment' is presented. The annotations cover safety, but the description leaves major input/output gaps.

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?

There are 7 parameters with 0% schema description coverage, so the schema itself provides only bare names. The description fails to mention or explain any of them—not the required business_type, problem, systems, recurring_workflow, or measurable_outcome, nor the optional sensitive_data/existing_memory flags. An agent gets no help mapping inputs to meaning.

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 an 'assessment' and a 'workflow plan', but the core concept ('fit') is undefined, and it doesn't differentiate this tool from siblings like reserve_plans or reserve_quote. An agent can infer it produces some kind of evaluation, but the exact purpose remains vague.

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?

No when-to-use guidance or alternatives are given. The only contextual clue is 'free, stateless', which is a reason to use it, but there is no indication of when to choose this over reserve_describe, reserve_plans, or reserve_quote, nor any prerequisites or exclusions.

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=true and openWorldHint=false. The description adds useful context that data is ephemeral and synthetic, but it does not explain what the tool returns or whether 'operations' are simulated versus merely read-only queries.

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 with no filler. Its weakness is under-specification rather than verbosity.

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 tool with annotations and no output schema, the description is minimally adequate. However, it leaves unclear what a caller gets back and why this tool exists alongside six related Reserve tools.

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 parameters, there is no parameter semantics burden. The schema is empty and fully described by its structure, so the baseline score applies.

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 indicates a demo/sandbox execution context with 'ephemeral synthetic data,' but 'Run real Reserve operations' is vague and does not identify what operations are run or how this differs from siblings like reserve_assess, reserve_quote, or reserve_plans.

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 safety constraint ('no confidential inputs') but does not state when to choose this tool over the other Reserve-family tools or what conditions make the demo appropriate.

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=true and openWorldHint=false, so the safety profile is covered structurally. The description adds something annotations cannot: what information comes back (status, endpoints, capabilities), which is meaningful since no output schema exists. It still omits whether endpoints are live/authenticated or how fresh the status data is.

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?

A single front-loaded sentence with no filler. The returned-content list is packed efficiently into the clause after the verb, and nothing needs to be trimmed or moved.

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, no-output-schema read tool, the description must carry the burden of saying what comes back, and it does name three return categories. The gap is that "ICONIC Reserve" and "machine endpoints" are unexplained, so an agent without external context cannot tell what these endpoints are for.

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 there is nothing for the description to disambiguate; baseline 4 applies. It correctly implies a no-argument call by not mentioning any inputs.

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 ("Discover") tied to concrete resources: status, machine endpoints, and capabilities of ICONIC Reserve. This distinguishes it from domain-action siblings like reserve_quote or reserve_plans, though it never names or contrasts them explicitly, leaving the agent to infer that this is the introspection entry point.

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?

"Discover" implies this is a first-call, exploratory tool, so usage is inferable rather than stated. There is no explicit when-to-use or when-not-to-use guidance and no pointer to reserve_assess or the other siblings as follow-ups, which would have made the routing decision 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds a meaningful behavioral detail: no outreach is sent, so the call does not contact a human. It also signals that the returned steps are 'approved,' though it does not say who approves them or what the response looks like.

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 sentence, front-loaded with the return value followed by the key safety clarification. Every clause earns its place and nothing is repeated from 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 parameterless, read-only retrieval tool with no output schema, the definition supplies enough to call it correctly. The only gap is that 'approved' and the shape of the returned steps are not elaborated, but the tool's low complexity makes that a minor omission.

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?

There are zero parameters, so the baseline is 4. The description correctly does not waste space inventing parameter semantics for a no-argument tool.

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 (Return) and resource (approved human consultation and pilot-onboarding steps), so the agent knows this is a read of handoff content. It does not name or contrast itself with any of the reserve_* siblings, which keeps it short of a 5.

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 phrase 'approved human consultation' implies this is used at the handoff stage after approval, and 'no outreach is sent' hints it is safe to call. There is no explicit when-to-use versus reserve_demo/reserve_quote guidance and no stated prerequisites, so usage is only implied.

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?

The annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds value by clarifying that results are restricted to actually callable offers and distinguish free work from unavailable paid products, but it does not describe ordering, pagination, or other list behavior.

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 definition is a single front-loaded sentence with no wasted clauses. The phrasing 'actually callable offers' is slightly cryptic, but the sentence remains compact and purpose-driven.

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 list tool with read-only annotations, the definition explains the result categories at a high level. However, without an output schema, it does not clarify the structure of returned offers or what makes an offer 'actually callable,' leaving some result-shape ambiguity.

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 behavior to clarify beyond what the empty schema already conveys.

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 provides a specific verb, 'List,' and the resource, 'offers,' with an additional scope distinction between free and unavailable paid products. It is clear what the tool does, but it does not explicitly differentiate itself from siblings such as reserve_plans or reserve_quote.

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 by saying the tool lists actually callable offers and distinguishes free work from unavailable paid products. It does not state when to use this tool instead of the sibling reservation tools or provide explicit exclusions.

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=true and openWorldHint=false, so the safety profile is covered. The description does add one genuinely useful behavioral fact – that returned plans are indicative rather than live paid figures – which warns the agent against treating output as authoritative pricing. It says nothing about how the assessment availability is determined or what form the response takes.

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?

It is a single short sentence with no padding, which is good, but the elliptical phrasing ('indicative, NOT live paid plans') reads as a fragment and forces the agent to infer the missing nouns. Brevity is achieved at the cost of parseability.

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 burden of explaining what comes back, and it does not – an agent cannot tell whether the result is a plan list, a boolean about assessment availability, or prose. For a zero-parameter read tool the safety side is adequately covered by annotations, but the return-content gap is significant.

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 there is no parameter semantics to explain and the schema is trivially complete. Baseline 4 applies; nothing in the description could add parameter meaning here.

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 'Clarify' is soft and the object is ambiguous – it is unclear whether the tool returns plan listings, pricing indications, or a textual clarification about assessment availability. The phrase 'NOT live paid plans' hints at indicative plan data, but the description never states plainly what the tool returns and does not distinguish it from siblings like reserve_offers or reserve_quote.

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?

There is no when-to-use guidance and no reference to any alternative tool among the six siblings. The only scope statement ('NOT live paid plans') is a caveat about data freshness rather than an instruction on when to select this tool over reserve_offers or reserve_quote.

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=true and openWorldHint=false, so the description does not need to argue safety. It does add real behavioral value by naming the failure mode (NOT_ON_SALE) and asserting the quote is exact and executable at $0, but it says nothing about quote validity duration, error behavior for invalid offer_ids, or what fields come back (no output schema exists).

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 front-loaded sentence with no filler; the success case and the terminal failure case are both stated. It is terse to the edge of cryptic, since '$0 executable quote' and 'NOT_ON_SALE' are unexplained jargon, but nothing is padded.

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 one-parameter read tool with annotations covering the safety profile, this is close to adequate, but the total silence on the required offer_id and on where that identifier comes from leaves a genuine hole. No output schema exists, so some statement of what a quote contains would have helped.

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 is required with 0% schema description coverage, yet the description never mentions offer_id at all. This leaves the parameter undocumented, so the score is limited to a 4 rather than a 2.

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 outcome: 'get an exact $0 executable quote' with an explicit alternative terminal state, 'NOT_ON_SALE response.' It never names or distinguishes itself from siblings like reserve_offers or reserve_describe, so the agent must infer that this is the pricing step downstream of an offer.

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?

There is no when-to-use or when-not-to-use guidance, no prerequisites, and no reference to alternatives. The only signal is implicit: call this when you have an offer and need an executable price rather than an assessment or a plan.

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