WeInc

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so an agent knows the safety profile. The description adds only the semantic gloss that a client is an end-customer; it says nothing about duplicate-email handling, plan_id validation, required permissions, or whether creation is idempotent.

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 short, front-loaded sentence with no filler or repetition. It is efficient, though its brevity reflects under-specification rather than disciplined editing.

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 four-parameter mutation tool with zero schema description coverage and no output schema, the description is far too thin. An agent lacks the field-level meaning and behavioral context needed to call it confidently.

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% across four parameters (name, email, company, plan_id), and the description never mentions any of them or the fact that email is required. The description therefore fails to compensate for the schema gap in any way.

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 (create a client) and disambiguates 'client' as an end-customer for the org, which a bare name would not convey. It does not, however, differentiate itself from siblings like create_project or explain why a client is distinct from a project.

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 this tool versus alternatives such as list_clients (to check for an existing client) or create_project, nor any stated prerequisites. Usage is only implied by the name itself.

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, destructiveHint=false, and openWorldHint=false, so safety profile is covered. The description adds the useful domain fact that every project is bound to a client, but says nothing about template application, idempotency on duplicate names, or what is returned. With annotations present, a 3 is appropriate.

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 terseness is efficient rather than padded, though it borders on under-specification for a five-parameter mutation 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?

A mutation tool with five parameters at 0% schema coverage, no output schema, and no annotation-level detail about effects. The description leaves template_id, the description field, and the creation's return value (presumably the new project id needed for follow-up calls) entirely 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?

Schema description coverage is 0% across 5 parameters, so the description carries the full burden, yet it only addresses client_id and client_email and only in terms of where to source them. name, description, and especially template_id (which likely relates to list_templates/find_templates) are completely unexplained, leaving the agent to guess at required formats and 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?

Specific verb+resource ("Create a project") plus the domain qualifier "for one of the org's clients," which makes it distinguishable from create_client. It doesn't explicitly contrast with siblings like create_client or start_website, so it falls 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 conditional guidance for obtaining the client identifier: pull client_id from list_clients, or use client's email if that's what the person supplied. That's a clear routing rule to a sibling, but there's no statement of when not to use this tool or what to do if the client doesn't exist yet.

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 genuine value beyond that by listing the returned fields (id, name, description, category, features, start link) and by documenting the downstream handoff to start_website, which compensates for the absence of an 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?

Three short sentences, front-loaded with the verb and scope, then returns, then next action. No filler; every clause earns its place.

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

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

With no output schema, the description carries the return-value burden and does so adequately by enumerating the returned fields. For a two-parameter optional search tool with full annotation coverage, nothing essential is missing, though pagination or empty-result behavior is unstated.

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 100%, so both parameters (query and the enumerated category) are already fully documented in the schema. The description only adds illustrative keyword examples ('restaurant', 'portfolio', 'online store') and the 'and/or' combination semantics, which is marginal value above the baseline.

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 ('Search WeInc's website templates') with scope modifiers (keywords and/or category), and implicitly distinguishes itself from the sibling list_templates by being a keyword search rather than an enumeration. An agent can select it without opening the 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 clear usage context ('by keywords ... and/or category') and closes the loop by telling the agent what to do with a result ('Pass a chosen id to start_website as template_id'). It does not explicitly name list_templates as the alternative when browsing without keywords, so it falls short of a full when/when-not rule.

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 structurally. The description adds the org-vs-project aggregation scope, which is genuinely useful, but says nothing about whether results are cached, how heavy the query is, or what happens when the window is large.

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 tight sentence with the scope constraint front-loaded and zero filler. It is efficient, though its brevity comes partly at the cost of the missing parameter and usage information noted elsewhere.

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 and 0% parameter coverage, the description should explain what metrics are aggregated and what the time window means. It leaves the 'days' parameter, default window, and returned data shape entirely unspecified for a two-parameter analytics 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%, so the description must carry parameter meaning, and it only partially does. It implies project_id narrows scope, but never mentions the 'days' parameter at all, leaving the time window — arguably the most important control for an analytics call — completely unexplained.

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 resource (aggregated analytics) and its scope (org-wide, optionally narrowed to one project), so an agent knows what it returns. No sibling tool touches analytics, so differentiation is implicit rather than stated, which holds it back from 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?

There is no guidance on when to use this versus other tools, nor any mention of prerequisites, defaults, or how to interpret an org-level versus project-level call. The parenthetical about 'optionally one project' hints at scope selection but does not state the condition for choosing 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 readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that: it does not say whether published and preview URLs differ, how many URLs come back, or what happens if the project is unpublished.

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 short, front-loaded sentence with no filler. Nothing could be trimmed without losing content.

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 should carry the burden of explaining the return value, and it only gestures at it via 'published/preview URLs'. Acceptable for a trivial read tool but leaves the return shape and the published-vs-preview distinction undefined.

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 the description says nothing about projectId — where to obtain it, whether it is a UUID or a slug, or whether it must reference an existing project. The parameter name is self-evident, which limits the damage, but the description still fails to compensate for the zero coverage.

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 (Get) and resource (published/preview URLs for a project), so the agent knows exactly what it returns. It does not, however, distinguish itself from adjacent readers like get_project or website_details, nor clarify the published-vs-preview distinction the slash implies.

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, no prerequisites (e.g., whether the project must be deployed), and no mention of alternatives among the many sibling tools. The agent must infer context entirely from the name.

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 fully covered by structured data. The description adds nothing beyond that (no note on error behavior for unknown ids, no visibility of permission requirements), so it is baseline-adequate rather than enriching.

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 short, front-loaded sentence with no filler or repetition. It is efficient, though its brevity reflects thin content rather than tight packaging of necessary detail.

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 single-read tool with no output schema and one parameter, the definition is minimally sufficient. It leaves the returned project shape and behavior on invalid/missing ids unstated, which a more complete definition would address.

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 projectId parameter, so the description must carry that load. 'By id' does signal that projectId is an identifier, but adds no format, sourcing, or example beyond what the schema name 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 states a specific verb ('Get') and resource ('a single project'), and the word 'single' distinguishes it from the sibling list_projects. It does not, however, contrast with get_analytics or website_details, which also surface project-level information.

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 when-to-use guidance, no mention of prerequisites, and no routing between this tool and list_projects or website_details. The 'by id' phrasing only weakly implies you need an existing projectId rather than a name.

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 fully covered by structured data. The description only adds the scope qualifier 'the org's' (single-tenant listing), and says nothing about pagination, ordering, or result size limits.

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

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

One short, front-loaded sentence with no filler or repetition of the title. It is efficient, though arguably under-specified rather than truly concise.

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 trivial 0-param, read-only list tool with no output schema, the description is minimally sufficient to invoke it. It omits any note on pagination or result volume, which for a list endpoint is the most likely source of agent error, leaving a clear 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 the schema imposes no semantic burden; per the baseline for 0-param tools this is a 4. The description correctly implies no filtering is possible.

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 the verb (List) and resource (the org's clients) in a single clause, and adds a tenancy scope ('the org's'). It does not differentiate itself from listing siblings like list_projects or list_plans, nor does it say what a 'client' record contains or how the list is ordered/bounded, so the purpose is clear but thin.

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, no mention of prerequisites, pagination, or when to reach for a sibling such as create_client or get_analytics instead. The agent must infer usage purely from the name.

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 plans are 'client-facing' and scoped to the org, but doesn't disclose return format, pagination, or ordering. With annotations present, this is adequate but thin.

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 short sentence that is front-loaded and contains no wasted words.

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

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

For a zero-param list tool with annotations covering safety, the description is minimally sufficient but leaves open what a 'plan' is, whether results are paginated, and how this differs from projects/templates. No output schema exists to fill those 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?

Zero parameters, so baseline 4 applies. No parameter semantics exist to explain.

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

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

States a specific verb (List) and resource (client-facing plans), scoping to the org. Distinguishes it from sibling list tools (list_clients, list_projects, list_templates) by naming 'plans', though 'client-facing' vs other plan types is not fully clarified.

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 guidance on when to use this tool versus alternatives. It doesn't say whether plans are separate from projects or how this relates to sibling tools like list_projects or list_templates.

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 only that results are paginated and filterable, which is light but non-redundant context; it says nothing about default ordering, page size limits, or org scoping enforcement.

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. It is efficient, though the parenthetical tacks on two unexplained qualifiers rather than earning them with detail.

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 4 undocumented parameters, no output schema, and no enum constraints, the description leaves the agent without enough to invoke the tool correctly - it does not even clarify what a 'builder project' is or what fields come back. Annotations cover safety but not invocation specifics.

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 are 4 parameters (limit, offset, status, client_id), none of which the description explains. 'Filterable' vaguely gestures at status/client_id and 'paginated' at limit/offset, but no units, defaults, or accepted values are given, so it fails to compensate for the coverage 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?

States a specific verb ('List') and resource ('builder projects for the org'), which distinguishes it from get_project (singular retrieval) and from sibling list_* tools that target clients, plans, and templates. However it does not explicitly name a sibling or contrasting alternative, so it falls short of 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?

There is no guidance on when to use this versus get_project, list_clients, or other list tools, and no prerequisites or exclusions are stated. 'Paginated, filterable' hints at context but is not a when-to-use rule.

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 structurally. The description adds only the word 'org's' as scoping context, and says nothing about filtering, pagination, ordering, or result size that would go beyond the annotations.

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

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

A single short sentence with no filler, and the scope constraint is front-loaded. Nothing in it is redundant or 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 zero-parameter read tool with no output schema this is roughly adequate to invoke, but the presence of a closely related `find_templates` sibling means the description is missing the disambiguation an agent needs to select correctly.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to disambiguate, and the schema is empty and fully consistent with the description.

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 ('List') and resource ('templates') with an explicit scope ('the org's'), so the operation is unambiguous. It fails to differentiate itself from the sibling `find_templates`, leaving the agent to guess which of the two listing tools applies.

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, no exclusions, and no mention of the sibling `find_templates` or `list_projects`/`list_clients`. The agent gets no help deciding between this and the other list/find tools in the family.

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 ordering behavior ('newest activity first') and the returned field set, which is genuinely useful context beyond the annotations.

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

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

Two compact sentences with zero filler: the first front-loads scope, ordering, and return fields; the second gives the follow-up call. Every clause earns its place.

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 and no parameters, the description carries the burden of describing the return shape, and it does so by naming the fields (name, live URL if published, editor link, last updated). Nothing needed to invoke or interpret the result is absent.

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 for a no-param tool is 4. Schema coverage is 100% with an empty properties object, confirming nothing is missing.

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 with explicit scope: 'the signed-in person's own WeInc websites.' The scoping to the caller's own websites and the enumeration of returned fields distinguish it cleanly from siblings like list_projects, list_clients, and find_templates.

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 second sentence provides concrete downstream routing: 'Use the id with website_details or request_change,' telling the agent how this tool feeds the next step. It does not state when NOT to use this versus other list tools, so it falls short of 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?

Goes well beyond the annotations by disclosing the return artifact (an editor link into the WeInc chat box) and the critical safety behavior that nothing is actually sent until the user presses send. This is exactly the kind of non-obvious behavior an agent needs, and it is consistent with readOnlyHint=true and destructiveHint=false.

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

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

Three tight sentences, front-loaded with the action, followed by return behavior and required instruction content. Every sentence earns its place with no redundancy.

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

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

With only two fully documented parameters, no output schema, and no nesting, the description covers purpose, return value, and the confirmation behavior. An agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description earns an extra point by adding content guidance the schema lacks: the instruction should say what to change, where, and the exact new text. This meaningfully shapes how the agent fills the field.

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-plus-resource: 'Prepare a change to one of the person's own websites.' This clearly separates it from creation/list siblings. It does not, however, explicitly distinguish itself from the closest sibling update_project, 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?

The description implies usage ('one of the person's own websites') but never states when to reach for this tool instead of update_project or start_website, nor any prerequisites such as needing a projectId from my_websites. No when-not and no named alternative.

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 readOnlyHint=true, destructiveHint=false, openWorldHint=false; the description explains WHY that holds and what actually happens: nothing is built or charged until the person confirms in their browser, and the build starts only after that confirmation page. It also discloses the return shape (a link) and the human-in-the-loop gate, which 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?

Front-loaded with purpose, then the no-build/no-charge behavior, then parameter guidance. Four sentences, all earning their place, though the confirmation gate is stated twice ('confirms in their browser' and 'confirms on that page'), which is mild redundancy against a 10k-char brief tool that is otherwise tight.

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 only 2 params, full schema coverage, and annotations covering the safety profile, the description supplies the remaining essentials: return value (link), the deferred-build billing model, and brief content expectations. Minor gaps remain, such as link expiry or failure modes, but for an agent to call this correctly nothing critical 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 coverage is 100%, so the baseline is 3, and the description earns above that by telling the agent exactly what to pack into brief (business name, what they do, location, services, audience, tone, pages wanted, contact details) and where template_id comes from. It adds content guidance the schema's generic 'Full description of the business' does not.

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 ('Prepare a new WeInc website from a description of the business') and immediately names the observable outcome ('Returns a link'). It also routes the agent to the find_templates sibling for template_id, so it is distinguishable from create_project, create_client, and update_project without 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 clear context: call it when you want a website prepared, and feed everything known into brief. It also names find_templates as the source of the optional template_id, which is real routing guidance. It stops short of explicitly stating when NOT to use this versus siblings like create_project or update_project, so it is clear but not exhaustive.

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 flag destructiveHint=true, so the description's real contribution is the concrete consequence: values are overwritten and a status change can remove the site from normal use. That is meaningful context beyond the structured hints, though it omits whether unmentioned fields are cleared and what a success response contains.

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

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

Two sentences, zero filler, with the scope of the mutation stated first and the caution second. Every sentence carries information an agent needs.

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

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

For a four-parameter mutation with no output schema and annotations already covering the safety profile, the description supplies enough to invoke correctly and warns about the risky path. What is missing is the status enumeration and confirmation of whether omitted fields are preserved.

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, and it names three of the four properties (name, description, status). However it gives no format, allowed status values, or per-field behavior, and omits projectId entirely, leaving real gaps for an undocumented 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?

States a specific verb (update) and resource (project) plus the three mutable fields (name, description, status), which cleanly separates it from read siblings like get_project and creation siblings like create_project. No sibling is named explicitly, so it falls short of 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 a conditional caution – confirm with a person before changing status because archiving takes the site out of normal use – which implies when to be careful, but never says when to prefer this tool over alternatives such as request_change or create_project, and names no 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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds a scope constraint (only the person's own websites) and enumerates the return contents, but discloses nothing about errors, permissions, or latency beyond what annotations supply.

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 compact sentence that front-loads the resource and then lists return fields with no filler. Every clause carries information.

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

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

With no output schema, the description usefully compensates by enumerating the fields returned. For a simple single-record read tool with read-only annotations, this is nearly complete; only when-to-use guidance is absent.

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 100% and the single projectId parameter is already documented as 'Website id from my_websites'. The description adds no format, source, or constraint detail beyond the schema, so the baseline 3 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?

States the specific resource (one of the person's own websites) and enumerates the returned fields (name, published state, live URL, custom domains, last published time, editor link). The singular 'one of the person's own websites' implicitly separates it from the listing sibling my_websites, though 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 description never states when to use this tool versus my_websites or get_project, nor any prerequisite beyond needing a projectId. Usage is only inferable from the word 'one', which is weak guidance for an agent choosing among 14 siblings.

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