The Outcome Layer

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

Annotations only declare the safety profile (not read-only, non-destructive, open-world); the description adds genuinely new behavioral context: the call is stateless and returns feasibility, price/risk notes and an optional alternative. It stops short of saying whether anything is persisted or what happens on an infeasible adjustment.

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 tightly packed sentences: purpose first, return shape second, calling constraint third. Zero filler and nothing buried.

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 correctly summarizes the return payload, and it flags statelessness for a nested-object input. Remaining gap is what the proposal object must contain and error/feasibility-failure behavior, but an agent has enough to invoke 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 description coverage is 0%, so the description carries the burden: it names five of the eight adjustment knobs (review level, model tier, volume, budget cap, disable steps) and clarifies that the proposal argument must be the full proposal JSON. It omits hourlyRateSek, taskDescription and consultantHoursPerMonth, and gives no detail on adjustment interaction semantics.

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 ('Adjust an existing proposal') and enumerates the adjustable dimensions, so an agent knows exactly what the tool mutates. It is distinguishable from start_proposal/get_proposal by the word 'existing', but no sibling is named explicitly.

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 'Stateless — pass full proposal JSON' note gives a usable calling convention, implying this is for re-evaluating a proposal rather than creating one. However, it never states when to prefer this over start_proposal or estimate_automation, 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 disclose that this is a non-read-only, open-world, non-destructive operation. The description adds that answers are merged into intake and remaining questions are returned, but it omits side-effect details such as idempotency, authorization needs, or what open-world behavior means here.

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 two efficient sentences with the operation front-loaded and no filler. It could be slightly more structured by separating the workflow precondition from the core behavior, but it is not bloated.

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 nested parameters, no output schema, and open-world mutation annotations, the description is too sparse. It never explains the answers payload or the return format of 'remaining questions', leaving the agent to infer important calling details from the schema alone.

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. It only explains where to get the required intake object and says nothing about the optional answers object or its fields (volume, signOff, systems, frequency), nor about the expected shape of intake.

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 operation: merge answers into the intake object and return remaining questions. It also references the start_proposal workflow, but the tool name 'ask_clarifying_questions' suggests question generation, which the description does not reconcile.

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 one useful precondition: pass the intake object from start_proposal. However, it does not explicitly state when to use this tool versus siblings like get_answer or list_answer_pages, nor does it describe when not to use it.

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/non-destructive/non-open-world, so the description's job is lighter; it adds meaningful context by stating the output is a shareable URL and that the payload carries no PII, which matters for what the agent may pass. It omits whether the link expires or what happens with an invalid `ref`, but the core behavioral profile is sound.

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 short sentences with the purpose front-loaded and no filler. The trailing clause 'For chats without MCP submit' is compressed to the point of ambiguity, costing a point.

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 correctly characterizes the return value as a shareable URL, which is the key missing piece otherwise. However, an agent still cannot confidently construct a call because `ref` is undefined and the nested `proposal` object's expected shape is unaddressed.

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 carry parameter meaning, and it only covers two of four: `proposal` and `task_summary` via 'proposal/summary prefilled'. The `ref` parameter is completely unexplained and `language` is only inferable from its enum.

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 artifact ('Build a shareable URL') plus the destination page and what is prefilled (proposal/summary), which is far more specific than the name alone. It does not name the sibling it replaces (e.g., request_free_first_task), so sibling differentiation is only implied by 'For chats without MCP submit.'

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?

'For chats without MCP submit' gives a use condition, but it is a terse fragment that assumes the agent knows what 'MCP submit' refers to and which sibling implements it. No explicit exclusions or named alternative are provided.

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 establish readOnlyHint=true, destructiveHint=false, and openWorldHint=false. The description adds useful behavioral context by calling the result 'deterministic' and 'illustrative' and explicitly warning that it is not a quote, which helps set expectations beyond the safety 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 front-loaded, compact, and free of filler. The output components are listed efficiently and the 'Not a quote' caveat follows immediately after the core purpose.

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?

There is no output schema, and the description partially compensates by naming the main output components and the illustrative nature of the result. However, it leaves the input parameters and their effects unexplained, which is a significant gap for a four-parameter estimator.

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% for four parameters, so the description must carry parameter meaning. It does not mention task_description, hourly_rate_sek, consultant_hours_per_month, or language, and only indirectly gestures at pricing concepts through the output list.

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 clear verb (estimate) and enumerates the estimate components: workflow pattern, model tier, consultant vs fixed monthly range, and running cost. It also distinguishes the output from a formal quote, though it does not explicitly name sibling tools such as get_pricing_model or start_proposal.

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 'Not a quote' gives an implied when-not boundary and suggests use for illustrative rather than formal pricing. However, it does not explicitly say when to choose this over siblings like get_pricing_model, get_offer, or start_proposal.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that the tool returns the full text of one page, but it does not discuss truncation, errors for missing slugs, or response behavior beyond that.

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, front-loaded sentence with no wasted words. It directly conveys the essential operation and selector.

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 lookup with complete schema coverage and clear annotations, the description provides enough context: it identifies the resource, selector, and that full text is returned. Minor omissions like invalid-slug behavior are not critical here.

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 100%, and the single slug parameter is fully documented with an example in the schema. The description only restates that the lookup is by slug, so it adds no meaning beyond 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?

The description clearly states the resource (answer page), scope (one page), and selector (slug), and it implicitly contrasts with list_answer_pages by specifying a single page. It does not name a sibling explicitly, but the purpose is unambiguous.

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 only implied: an agent can infer this tool is for retrieving the full text of a specific answer page when it already has a slug. It does not explicitly say when to choose this over list_answer_pages or what to do if the slug is unknown.

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, openWorldHint=false, and destructiveHint=false, so 'read-only' in the description is a restatement rather than added value. The parenthetical does add useful context about what the returned facts cover, but says nothing about format, size, or whether the content is static versus generated.

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 content enumeration is packed into a parenthetical rather than a paragraph. It is appropriately sized for a zero-parameter tool.

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-param read tool with full annotation coverage, the description is close to sufficient, but with no output schema the agent gets no sense of the return shape beyond four topic labels. A brief note on what the facts look like (prose, structured fields, single blob) would close the 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The schema is empty and fully consistent with a no-argument fetch.

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 specific resource (canonical facts about The Outcome Layer) and enumerates the content it covers: entity, positioning, illustrative scenario, disambiguation. That distinguishes it from siblings like get_offer or get_pricing_model, which target narrower commercial data, though the verb is only implied by the tool name.

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 guidance on when to call this versus get_offer, get_pricing_model, or how_to_start, nor any stated precondition. The agent must infer that this is background/orientation material from the parenthetical content list alone.

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, openWorldHint=false, and destructiveHint=false, so the safety profile is clear. The description adds that the offer is free and priced at 0 SEK, but it does not disclose return format, availability conditions, or any behavior beyond the offer label.

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 concise sentence with no wasted text. It is front-loaded with the offer name and price, though it reads as a fragment rather than a fully structured tool 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 zero-parameter read tool with annotations covering safety, the description still needs to clarify what the tool returns and when to use it instead of sibling tools like request_free_first_task. It states the offer's price but leaves the agent without enough context to confidently select or understand the call.

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, so the baseline is 4. The empty input schema is consistent with the description, and there are no parameter semantics to clarify.

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 identifies the offer as the 'Free entry offer (Free First Task)' with price 0 SEK, but it is a noun phrase rather than a clear verb+resource statement. It does not explicitly say the tool returns or retrieves this offer, and it does not distinguish the tool from closely related siblings such as request_free_first_task or get_pricing_model.

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 guidance on when to use get_offer versus alternatives like request_free_first_task or get_pricing_model. The description provides no context, prerequisites, or exclusions to help an agent select this tool correctly.

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=false, and openWorldHint=false, so the safety profile is covered. The description contributes only the content framing (ROI-first, fixed-fee packages) and says nothing about whether this returns marketing copy, a rate card, or whether pricing is negotiable.

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 waste. The parenthetical earns its place by scoping the pricing philosophy, though the fragment style makes it read more like a tagline than an instruction.

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, read-only knowledge lookup this is close to sufficient, but with no output schema the description never indicates what form the answer takes (static text, tiers, quote request path). One clause on the return shape or on when pricing must instead go through start_proposal would make it complete.

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?

Zero parameters with 100% schema coverage, so there is nothing for the description to disambiguate. Baseline 4 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 states the resource precisely: the pricing model of 'The Outcome Layer', characterized as ROI-first fixed-fee packages. That is enough to distinguish it from siblings like get_offer, get_company_facts, or get_proposal, though it phrases the action as a topic rather than a verb.

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 guidance on when to call this versus get_offer or start_proposal, and no prerequisites or exclusions. The agent must infer that this is the pre-sales 'how do you charge' lookup.

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 declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, so the safety profile is already carried by structured fields; the description adds the meaningful trait that the tool holds no state. It also lists the proposal's sections, which substitutes for a missing output schema. What it omits is whether the intake or generated proposal is persisted anywhere despite being 'stateless' while not read-only, and nothing about cost or latency of generation.

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 deliverable and zero filler; the parenthetical enumeration is efficient. It is perhaps too terse for a tool whose input schema is fully undefined, but nothing written is wasted.

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 does a reasonable job of describing the return artifact, and it flags statelessness. But against a fully unconstrained intake object and a crowded sibling set, it leaves the two things an agent most needs — the intake contract and the routing rule versus start_proposal/adjust_proposal — undocumented.

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 'intake' parameter is an open object with additionalProperties:{} and 0% schema description coverage, so the schema conveys almost nothing. The description only says 'pass intake JSON' and never names a required field, shape, or example, forcing the agent to guess at the intake contract.

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 gives a specific verb and resource ('Build a concrete indicative proposal') and enumerates the artifact's contents (steps, automation split, model tier, pricing ranges, CTA), so an agent knows exactly what comes back. It does not, however, differentiate itself from siblings like start_proposal or adjust_proposal, leaving the 'get_' prefix slightly at odds with the generative wording.

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?

'Stateless — pass intake JSON' describes an input requirement, not a usage condition. Nothing says when to call this versus start_proposal, adjust_proposal, or get_pricing_model, so an agent must infer the entry point from the name alone.

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, openWorldHint=false, and destructiveHint=false, so the safety profile is clear. The description adds the audience and topic but no additional behavioral context such as what content is returned or whether it is static guidance.

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 concise sentence with no wasted words. However, it is not front-loaded with a concrete action verb, which slightly weakens scannability.

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 lack of parameters and the presence of annotations, the description is minimally adequate. Without an output schema, though, it should say more about what the tool returns, such as whether it provides step-by-step guidance or a link.

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, so the baseline is 4. The description does not need to explain parameter semantics, and the empty schema is consistent with that.

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 identifies an informational purpose ('how ... should start engaging') and names the target audience and platform, but it does not state a concrete verb+resource like 'returns onboarding steps for buyers.' It is more specific than the bare name but still vague about what the tool actually provides.

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 explicit guidance on when to use this tool versus siblings such as get_answer, ask_clarifying_questions, or start_proposal. The phrase 'should start engaging' implies an onboarding context, but no alternatives or exclusions are named.

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, destructiveHint=false, and openWorldHint=false, so safety is covered; the description adds the meaningful qualifier that only "citable English" pages are returned. It says nothing about ordering, pagination, or how the `<slug>` scope is applied when no parameter exists to supply it.

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. Every word ("citable", "English", the path) carries scope 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?

The tool takes no input and has no output schema, so the description is the only source of return-value context — yet it never says how many pages come back, in what shape, or how results relate to get_answer. Adequate for a trivial list call, but incomplete.

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 the baseline is 4, but the description introduces an unexplained `<slug>` path element that has no corresponding input, which could leave the agent wondering whether a slug is required. That inconsistency costs a point despite the empty 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?

Uses a specific verb ("List") with a precisely scoped resource: citable English answer pages under /answers/<slug>. An agent immediately knows what it retrieves, though the reference to a `<slug>` path segment is never reconciled with the tool's zero-parameter schema.

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 guidance on when to call this versus the closely related get_answer sibling, nor any stated preconditions (e.g., needing an existing slug). The word "citable" implies a citing/answering workflow but the agent must infer that entirely.

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 only cover readOnly=false, openWorld=true, destructive=false; the description adds genuinely new behavior: an external customer-facing lead is created, a confirmation email may reach the user, and test=true suppresses that email and flags the lead TEST. It stops short of saying what happens on duplicates, retries, or what a successful submission returns.

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 one-line purpose, then a numbered precondition block, then two short directives for the consent and test flags. Every line carries an instruction an agent must follow; nothing is redundant.

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 10-parameter, nested-object, open-world submission tool with no output schema, the description covers the critical preconditions and the test escape hatch. It could still say what the tool returns (lead id, confirmation) and what to do on failure, which matters given there is no output schema.

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 already 90%, so baseline would be 3, but the description adds real semantics: consent must be true only after explicit user agreement, test means no customer email, and name/email/company must originate from the user rather than being invented. It says less about ref, mcp_client, and phone, which rely on the schema alone.

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: submits a Free First Task lead to The Outcome Layer, and the parenthetical '(same as the website form)' clarifies what the record actually is. It does not, however, differentiate itself from the sibling send_to_tol, which an agent could easily confuse with this tool.

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 an explicit precondition checklist (consent, collect real contact data, include task_summary/proposal) plus a dry-run path via test=true. What it lacks is routing guidance against the similarly named send_to_tol sibling, so the agent must guess which submission tool applies.

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 declare a non-read-only, open-world, non-destructive write, and the description adds real context beyond that: the lead is submitted to an external party, an email is sent to the user unless test=true, and test leads are marked TEST. It stops short of describing the success response or failure modes, but the consent gate and email side effect are the critical disclosures and they are present.

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-loads the identity and purpose in one sentence, then uses a numbered precondition list that an agent can follow step by step. Every sentence carries actionable content, with no filler or repetition of the title.

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 10-parameter external submission tool with no output schema, the description covers the consent gate, data-provenance rules, and test-mode behavior, which are the highest-risk aspects. What remains unstated is what a successful submission returns or how errors surface, a modest gap given no output schema exists.

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 already 90%, so the schema documents most parameters. The description still adds meaning the schema does not: consent must be set only after explicit user agreement, test implies no customer email, and task_summary/proposal should originate from prior tool calls. It does not clarify ref, phone, or mcp_client intent, which the schema handles only thinly for phone.

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 action (submit a Free First Task lead to The Outcome Layer), identifies itself explicitly as an alias for request_free_first_task, and notes the equivalent human channel (the website form). This differentiates it from siblings like get_proposal or build_handoff_link, which produce artifacts rather than submit them.

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 unusually explicit preconditions: obtain consent, collect real contact data, and include task_summary and/or proposal from prior tools before calling. It also explains test=true for dry runs. The one gap is that it never says when to pick send_to_tol over the sibling request_free_first_task, leaving an agent to guess which alias to invoke.

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 state readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so safety is partly covered. The description adds useful behavior by saying it is stateless and by naming the clarifying-question topics returned, but it does not explain side effects, whether provided fields suppress questions, or how the interaction proceeds.

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, front-loaded sentences with no filler. The purpose, return value, and stateless behavior are each stated efficiently.

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 an 8-parameter intake tool with no output schema, the description is too thin. It explains the return in general terms and one behavioral trait, but it omits most parameter semantics and gives no guidance on interaction with sibling proposal 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?

Schema description coverage is 0%, so the description must carry parameter meaning. It mentions task_description and four optional topic fields (volume, systems, frequency, sign-off), but leaves language, hourly_rate_sek, and consultant_hours_per_month completely undocumented, which is a significant gap for an 8-parameter 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?

States a specific action (begin interactive proposal intake) from a task description and describes the return value (clarifying questions). The purpose is clear, but it does not distinguish itself from the sibling ask_clarifying_questions, which sounds 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?

'Begin' implies this is the first step in a proposal workflow, giving some usage context. However, it never says when to use this versus ask_clarifying_questions, adjust_proposal, or estimate_automation, and gives no explicit exclusions.

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