TESSA Marketing & Technology

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

Annotations already declare the safe read-only/idempotent profile, but the description adds real behavioral context beyond them: 11 items, ~12 seconds runtime, the pass/partial/fail/could_not_check status model, and the score covering only checkable items. It also discloses a non-obvious edge case - GTM container tags that can't be read are reported as could_not_check, never as missing.

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 opening sentence front-loads the purpose and scope before any detail, and the operational facts (11 items, ~12 seconds, status vocabulary) are grouped logically. The dense tag enumeration is slightly list-heavy but each element is load-bearing for matching, so little 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?

No output schema exists, so the description must explain the return shape - and it does, describing per-item status, evidence, plain-English fix, and the aggregate 0-100 score with its caveat about unchecked items. Combined with the scoping and fallback disclosure, an agent has everything needed to call it and interpret results.

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 the single parameter is undocumented in the schema, so the description carries the burden; it supplies the meaning ('the website to check') and a concrete format example ('https://example.com'). Useful but minimal - it doesn't say whether a bare domain is accepted or whether non-homepage paths are honored.

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 ('quick ad tracking check of any website's homepage') and enumerates exactly what is inspected (GA4, GTM, Google Ads, Meta Pixel, Microsoft/LinkedIn tags, call tracking, consent, phone link, CTA, speed). This cleanly distinguishes it from siblings like assess_seo, assess_website and assess_ai_readiness without the agent opening any 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?

Gives explicit scope boundaries ('Automated, homepage only, not a full ad account audit') and routes to named alternatives with the condition for each: get_advertising_offer for the service itself, request_strategy_session to talk it through. Both when-to-use and when-not-to-use are covered.

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, openWorld and non-destructive, so the safety profile is covered. The description adds genuine behavioral context beyond that: ~15 second runtime, homepage-plus-standard-files scope, and the scoring rule that could_not_check never counts as a fail. Rate limits or auth needs are not mentioned, but this is an unauthenticated public check.

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 and the quick-vs-full distinction are front-loaded, and the item enumeration, while long, is load-bearing detail rather than filler. The return-value paragraph is slightly dense but every clause (statuses, score, fixes, cross-sell) informs the call.

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, so the description correctly explains the return shape itself: per-item status (pass/partial/fail/could_not_check) with evidence and a plain-English fix, plus a 0-100 score. It also names what the full audit adds, leaving no gap an agent would need to guess at.

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 the single url parameter, so the description must carry it. It supplies both meaning ('the website to check') and a concrete format example ('https://example.com'), which the schema omits entirely.

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 with exact scope: '12 of the 46 items in TESSA's AI Readiness audit, checked on the homepage and a few standard files in about 15 seconds.' An agent can distinguish this AI-readiness check from the sibling assess_seo / assess_ad_tracking / assess_website tools without opening a 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?

Explicitly frames itself as the quick partial check versus the full 46-item audit and names the routing alternative: 'book it with request_strategy_session.' The when-to-use-what is clear, though it does not explicitly contrast against the other assess_* siblings or state when not to run any check.

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 non-destructive behavior, so the safety profile is covered. The description adds real value beyond that: 12 items, ~12 second runtime, the four possible statuses (pass/partial/fail/could_not_check), and the non-obvious scoring rule that the score covers only checkable items. It doesn't mention rate limits or whether the result is cached, which is why this is a 4 rather than a 5.

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?

Content is front-loaded: the check scope comes first, then behavior/scoring, then sibling routing, then the parameter. The middle sentence about the 12 items is somewhat dense but every clause carries information. Slightly longer than strictly necessary, but 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?

With no output schema, the description must describe return shape and does so: a 0–100 score, per-item status, evidence, and a plain-English fix, plus the caveat about could_not_check items. Combined with the scope limits and routing guidance, an agent has everything needed to invoke and interpret the 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 description coverage is 0% and there is a single required 'url' parameter, so the description carries the burden. It supplies meaning the schema lacks: 'the website to check, for example https://example.com', which conveys the expected format and that a homepage URL is intended. Minor gap: it doesn't say whether protocol is required or whether subpaths are accepted.

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 and resource ('quick SEO check of any website's homepage') and enumerates exactly what is examined: indexability, title/meta, H1, canonical, mobile and speed. The scoping phrase 'homepage only, not a full SEO audit' plus the sibling toolbox (assess_website, assess_ai_readiness, assess_ad_tracking) makes it easy to distinguish from the other assess_* 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?

It gives explicit scope limits ('Automated, homepage only, not a full SEO audit') and names the exact alternatives for follow-up actions: get_seo_offer for TESSA's SEO service and request_strategy_session for a conversation. An agent knows both when to call this and where to route the user afterwards.

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 declare read-only/idempotent/open-world; the description adds runtime (~12 seconds), item count (12, platform reported but unscored), per-item status vocabulary (pass/partial/fail/could_not_check), evidence and fix payloads, and the important scoring caveat that only checkable items count. It also flags 'could_not_check' so the agent knows partial results are possible.

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 and scope are front-loaded, then behavior, then routing, then the parameter — a sensible order. It is somewhat dense and the routing sentence is long, but every clause adds distinct information 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 must explain returns, and it does: per-item status, evidence, and plain-English fix, plus the 0-100 score and its scoping rule. Combined with the stated limitations and siblings, an agent has everything needed to call it and interpret results.

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 the single 'url' property has no schema description, so the description carries the burden: it restates the parameter as the site to check and supplies a concrete format example ('https://example.com'). That is adequate but stops short of stating whether scheme is required or what happens for malformed URLs.

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 verb (check) and resource (a website's homepage) and enumerates exactly what is inspected: HTTPS, mobile setup, load time/page weight, platform, security headers, accessibility signals, contact form/chat, footer. It explicitly bounds scope ('homepage only, not a full website audit'), which cleanly separates it from get_wcag_audit.

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 explicit routing: full accessibility audit goes to get_wcag_audit, TESSA's offer to get_web_ai_development_offer, and a conversation to request_strategy_session. The homepage-only limitation is stated as a when-not condition, leaving no ambiguity about which sibling to pick.

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=false, openWorldHint=true, idempotentHint=false and destructiveHint=false, so the mutation/safety profile is covered. The description adds genuine behavior beyond that: an email reply SLA ('within one business day') and a validation rule that temporary inboxes are refused, plus a consent requirement. It does not address duplicate submissions, but with annotations carrying that load a 4 is warranted.

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 purpose, then usage conditions, then a compact parameter glossary; every line carries information. The indented parameter list is slightly redundant in presentation but each entry earns its place, so no real waste.

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 side-effecting, five-parameter, no-output-schema tool, the description covers purpose, consent preconditions, validation behavior and expected turnaround, which is most of what an agent needs. Only minor gaps remain, such as whether repeated calls create duplicate messages, and the annotations already imply the non-idempotent nature.

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 full burden, and it does: each of the five parameters is glossed with meaning (prospect_email required with the temp-inbox caveat, project_brief = 'the message', requested_window optional = when they want to hear back). This fully compensates for the bare schema titles.

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 ('Send a message to TESSA's sales team') and grounds it in a concrete analogue ('the same as the contact form on tessa.tech'). This clearly separates it from siblings like request_strategy_session (booking a call) and get_contact_info (retrieving details).

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 selection rule: 'Use this when the user wants TESSA to contact them but does not want to book a call', which explicitly routes against the booking sibling. It also adds a hard precondition ('Only call it when the user has asked to and has given their real email'), leaving nothing 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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely new context by describing what the payload contains — verbatim pricing-page fees, published scope/deliverables/timeline, and a booking link — which is the kind of detail annotations cannot express.

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 scope is front-loaded and the trigger sentence is placed last, which is good ordering. However, the phrase 'PPC, social media ads, display and retargeting, Google Ad Grant management' appears twice in near-identical form, which is wasted space in an otherwise single-paragraph 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?

There is no output schema, so the description must convey the return shape — and it does, listing fees, service page, booking link, and published scope/timeline. For a zero-argument read tool with full annotation coverage, this is close to sufficient, missing only a note on freshness or source of the fee data.

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 schema to document and no parameter semantics to add. Baseline 4 applies; the description correctly implies no inputs are needed to get the full offer.

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 (TESSA's online advertising/SEM offer) and enumerates its contents — management fees, service page, booking link — with enough specificity to separate it from get_seo_offer or get_web_ai_development_offer. It does not name any sibling explicitly, so differentiation is inferred from topic keywords rather than stated.

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 an explicit when-to-use trigger: questions about Google Ads, PPC, SEM, social media ads, display/retargeting, or Google Ad Grants. It offers no when-not guidance and never names the closest alternatives (e.g. get_pricing, get_seo_offer) to route the agent.

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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds only that filters are optional and case-insensitive for industry; it says nothing about result volume, ordering, or pagination 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?

Front-loaded with the resource and its content, followed by a compact filter list mapped one-to-one to the parameters. Efficient overall, though the phrase 'for example traffic and lead growth for named clients' is slightly loose compared to the rest.

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 annotations covering safety and no output schema, the description supplies the essential context: what a case study contains and how to narrow the list. It would be stronger if it noted result ordering or roughly how many studies are returned, but nothing critical is missing for 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 description coverage is 0%, so the description carries the full burden and does document both parameters meaningfully: 'industry' as a case-insensitive keyword and 'service_slug' as restricting to studies that used a given service. It stops short of explaining the expected slug format or where valid slugs come from (e.g., get_services).

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+resource ('TESSA's client results (case studies)') and even characterizes the content ('traffic and lead growth for named clients'), so an agent knows what it will receive. It does not explicitly distinguish itself from siblings like get_services or get_pricing, but the distinct resource (case studies) makes the separation reasonably clear.

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 infers it should call this when it wants proof/outcome examples, and the 'Optional filters' section hints at narrowing results. There is no explicit when-to-use statement, no exclusions, and no reference to alternative siblings for related content (services, pricing).

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, openWorldHint and destructiveHint=false, so the safety profile is covered without the description. The description adds real value by disclosing the shape of the response (the five categories of contact data), which substitutes for the absent output schema.

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, front-loaded with the returned data and followed by the trigger condition. The second sentence slightly restates the purpose already implied by the first, but there is no padding and nothing extraneous.

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-only lookup with no output schema, the description supplies everything an agent needs: what the tool returns and when to call it. Nothing about calling it correctly is missing.

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 per the rubric the baseline is 4. There is no input to explain, and the description correctly spends no effort on argument 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?

The description names a specific resource and enumerates its contents ('phone number, email, office address, business hours, and the links to book a call'), which is far more concrete than the tool name alone. However, it never contrasts itself with siblings like get_services or request_introduction, so the differentiation is implicit rather than stated.

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?

'Use this when someone wants to reach TESSA' gives a clear triggering condition, which is the useful half of usage guidance. It stops short of exclusions or alternatives, notably that request_introduction and request_strategy_session are the tools for actually initiating contact rather than just retrieving details.

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, openWorld and non-destructive, so the safety profile is covered. The description adds real value beyond them by disclosing that values are live-scraped from an external URL, implying freshness and possible network dependence. It says nothing about failure modes or caching.

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 and usage trigger are front-loaded in the first sentence set, with the parameter note last. Slightly repetitive phrasing (two "for example" constructions, price framing repeated) costs it the top score.

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-optional-param read tool with no output schema, the description covers what it returns (starting prices per service), the source, and the filter. Absent are the shape of returned records and whether unpriced or missing services are surfaced, minor for this complexity.

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%, so the description must carry the parameter, and it does: the service argument is documented as optional and as a keyword filter with worked examples ('seo', 'website'). The matching semantics (substring vs exact) are left implicit, which is the only gap.

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 (TESSA's starting prices for every service) and states the retrieval mode (read live from https://tessa.tech/pricing/), with concrete service examples. An agent can distinguish this from get_services, which covers offerings rather than prices.

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?

"Use this when someone asks what TESSA charges or wants to compare prices" gives a clear trigger condition. It stops short of naming alternatives or exclusions (e.g. when to prefer get_services for scope questions), so it is clear context but not full routing 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 readOnlyHint, idempotentHint and closed-world, so the safety profile is covered. The description adds real context: the payload contents and the honest caveat that scope/deliverables/timeline are included only 'where TESSA has published them,' signaling possible partial data.

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 statement ('TESSA's SEO offer in structured form') and reasonably tight, though the trailing clause about the pricing page and service page is slightly list-like and could be trimmed without losing meaning.

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 parameters, no output schema and full annotation coverage, the description's inventory of returned content is largely sufficient for an agent to call and interpret it. Minor gap: 'structured form' is not specified (e.g., which fields or format the agent should expect).

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

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

The tool takes zero parameters and there is nothing to document, so the baseline of 4 applies. The description correctly implies no filtering arguments are accepted.

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+resource ('get TESSA's SEO offer in structured form') and enumerates the payload (what it is, starting prices, service page, booking link). It partially differentiates from siblings like get_pricing and get_services by scoping to SEO offers, but never names an alternative directly, so it stops 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?

Gives an explicit trigger: 'Use this when someone asks about TESSA's SEO, local SEO, national SEO or Generative Engine Optimization (GEO).' Clear usage context, but no when-not conditions and no named alternative (e.g., assess_seo or get_pricing) for adjacent queries.

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 the safety profile is fully covered without the description. The description adds that both filters are optional and effectively unfiltered by default, but says nothing about return format, pagination, or ordering. Adequate, not rich, against an already-complete annotation set.

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 and usage lead, the sibling pointer follows, and the optional filters are demoted to a clearly labeled block. Every sentence earns its place and nothing is repeated from the schema.

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 two-optional-param read tool with no output schema, the description covers what is returned (the enumerated service list) and how to narrow it. The only gap is that the shape/format of the returned records is not sketched, which matters slightly more here because 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 0% and the schema declares no enums, so the description carries the whole burden. It supplies the full allowed value set for category_slug (marketing | web-development | ai-experiences | accessibility) and a concrete example for service_slug ('seo'), which is genuinely additive over the bare string types. It stops short of saying what happens when both filters are supplied or when a slug does not exist.

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 and resource ('List the services TESSA Marketing & Technology offers'), with the actual service lines enumerated so the agent knows exactly what content comes back. It is immediately distinguishable from get_pricing, which it names directly.

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 trigger condition ('Use this when someone asks what TESSA does') plus an explicit alternative for a closely related need ('For current prices call get_pricing'). The when-to-use and the sibling routing are both stated rather than inferred.

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, destructiveHint=false and a closed-world scope, so the safety profile is fully covered. The description confirms the tool returns informational offering details rather than performing anything, but adds no behavioral context 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?

A single front-loaded sentence listing the four content areas with no filler. Every word earns its place, and the member list is placed right after the resource.

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 parameters and no output schema, the description's content enumeration (scope, deliverables, timeline, price range) usefully substitutes for a return-value description. Complete for a simple read-only informational tool, with the only gap being sibling routing.

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, so there is nothing to mis-specify; baseline is 4. The description correctly implies no input is needed to retrieve the audit details.

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 resource (TESSA's WCAG 2.2 AA accessibility audit) and enumerates what the details cover: scope, deliverables, timeline and price range. Clear verb+resource, though it does not explicitly differentiate from siblings like get_services or get_pricing, which overlap on offering/price content.

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 enumerated content implies when the tool is relevant (an agent needing audit specifics), but there is no explicit when-to-use, no when-not-to-use, and no pointer to get_pricing or get_services for overlapping questions. Usage 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.

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so safety is covered structurally. The description adds genuinely useful behavioral context beyond that: prices are quoted verbatim from the pricing page and scope/deliverables/timeline are present only 'where TESSA has published them', warning the agent the payload may be incomplete.

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 opening clause front-loads what the payload is, followed by its contents and then the use case. The first sentence is long and clause-heavy, but every clause carries information about the returned data; no filler sentences.

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 describing the return, and it does so well (pricing, service page, booking link, scope, deliverables, timeline). The only mild gap is that it never states the actual shape/fields of the 'structured form' the agent will receive.

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; the schema is fully described (100% coverage). Nothing in the description is needed to disambiguate inputs and nothing is misleading.

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: TESSA's website and AI development offer returned in structured form, enumerating what it contains (pricing, service page, booking link, scope/deliverables/timeline). This distinguishes it reasonably well from narrow siblings like get_pricing or get_services, though the overlap with those two is not explicitly resolved.

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 trigger: 'Use this when someone wants TESSA to design or build a website, a web application or AI software.' That is a clear use condition, but it names no exclusion or alternative (e.g., when to prefer get_pricing or get_services instead).

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 (which only say it is a non-idempotent, non-destructive, open-world write), the description discloses real behavioral traits: an outbound email and calendar invite are created, temporary inboxes are refused, and there is a rate limit of 10 bookings per email per 7 days that returns status 'duplicate'. That is exactly 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?

The purpose and side effects are front-loaded, then a scannable parameter block, then the rate-limit caveat. It is slightly long and the parameter list partially mirrors the schema, but every line carries usable 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?

For a mutating, open-world tool with no output schema, the description covers purpose, prerequisites, side effects, per-parameter meaning, and even the failure return value ('duplicate'). Nothing an agent needs to invoke it correctly is missing.

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 full burden and does: it documents all five parameters, marks prospect_email as required with a refusal rule, and supplies concrete format examples for requested_window ('2026-10-06', an ISO interval, 'tomorrow', 'next week'). This adds meaning well beyond the bare titles 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?

The description gives a concrete verb and resource ('Book a free 30-minute strategy session with TESSA') and enumerates the observable side effects: finds a slot, creates a Google Meet invite, emails the prospect. This is unmistakably distinct from the read-only siblings like get_pricing or contact_tessa.

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 states an explicit gating condition: 'Only call this when the user has asked to book a call and has given their real email address.' That is a clear when-to-use plus a precondition, though it never names an alternative sibling to use instead when the condition fails.

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