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

Annotations already declare this is a non-read-only, non-idempotent write that is not destructive, so safety is covered. The description adds genuinely new behavioral facts: the copy lands in "edit" status, receives a new proposal number, and gets a new link. It stops short of saying the source proposal is left untouched, what permissions are required, or whether related entities (contacts, price tables) are carried over.

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 or repetition. Its brevity is a virtue structurally, though the missing detail is penalized under the other dimensions.

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 six-parameter creation-style tool with no output schema and zero schema documentation, this is too thin: the agent cannot tell what each required parameter means or what the call returns beyond a vague "new link". Only the resulting state of the copy is described.

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 six parameters, so the description carries the full burden and adds nothing. It does not explain that proposal_id is the source, what name and contact_id do on the new record, or what directory_id, contact_people, and account_user_id control.

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 ("Copy a proposal") plus the outcome of the copy, which separates it from create_proposal and get_proposal_details. It never names a sibling explicitly, so the differentiation is inferential 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?

There is no when-to-use guidance at all: nothing says when to copy an existing proposal rather than call create_proposal, nor whether the source proposal must be in a particular state. The agent must infer the intended routing 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=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true, so the mutation and non-idempotency profile is known. The description adds nothing beyond that: no duplicate-handling behavior, no required-field consequences, no error or side-effect disclosure. For a create tool with 21 optional-looking fields, this is a meaningful gap.

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 core verb front-loaded and no wasted words. It is concise to the point of under-specification, but there is no filler or structural disorder to penalize.

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 21 parameters, no output schema, and no descriptions in the schema, a one-line description is far too thin — an agent cannot tell what a successful response contains or which of the optional fields are meaningful for each contact type. Completeness is adequate only for the basic create intent.

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 21 parameters, so the description carries the full burden and largely fails it; only the type enum is hinted at via "organisation or person/individual". Nothing explains the distinction between name/firstname/lastname, the social fields, or whether vat_number/coc_number are organisation-only, leaving most parameters semantically opaque.

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 and resource ("Create a new contact") and clarifies the two contact kinds via "(organisation or person/individual)", which maps to the type enum. It does not explicitly distinguish itself from siblings like search_contact_people or update paths, but the create intent is unambiguous against those read-oriented 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?

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no mention of what to do if the contact already exists. The only implied usage cue is the organisation/person choice, which comes from the parenthetical rather than from any stated 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=false, destructiveHint=false and idempotentHint=false, so the write nature is known and not contradicted. However, the description adds nothing beyond that: it does not say whether the proposal is created as a draft or sent, what permissions or account_user_id scoping are required, what happens on failure, or what the call returns. For a multi-required-parameter mutation tool, this is a serious omission.

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 single short sentence contains no filler, so nothing is wasteful. But brevity here reflects under-specification rather than disciplined conciseness, and there is no structure carrying routing or prerequisite 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?

This is a create/mutation tool with 6 required parameters, no output schema, no annotation detail on side effects, and 0% parameter documentation. The definition gives an agent almost nothing it needs to invoke the tool correctly, which is far below what this complexity demands.

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 schema has 8 parameters (6 required) with 0% description coverage, and the description explains none of them. Cryptic fields such as contact_people (an array of numbers), design_template_id, proposal_template_id, text_template_id and account_user_id remain completely undefined, so the description does nothing to compensate for the schema 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?

The description 'Create a new proposal' is essentially a de-camelCase of the tool name and title, with no added scope, resource context, or distinguishing detail. It gives no hint of how it differs from siblings such as copy_proposal or send_proposal, so it functions as a tautology rather than a real statement of purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no prerequisites (e.g. that the referenced templates and contact must already exist), and no mention of alternatives like copy_proposal. The agent must infer entirely on its own when this tool is the right choice.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds the scoping constraint that results are limited to the current account, which is useful beyond annotations, but it says nothing about pagination, ordering, inactive-user inclusion, or the shape of the returned user records.

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 redundant or filler wording. Its brevity is appropriate, though it borders on under-specification for anything beyond 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?

For a simple zero-parameter read tool with annotations covering safety, the description covers the essential purpose and scope. However, without an output schema the agent gets no hint about what user fields are returned, whether results are paginated, or whether inactive users are included.

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?

This tool takes zero parameters, so there is no parameter meaning for the description to add. The schema is empty and fully documented by its own structure.

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 ("Lists") and resource ("account users") plus the scope ("current account"), so an agent can tell exactly what data is returned. It does not need to differentiate from siblings, since none of the listed tools deal with account users, but it also doesn't explicitly note that distinction.

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 alternatives, and no prerequisites such as required permissions. Usage is only implied by the phrase "for the current account," leaving the agent to infer when this tool is appropriate.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. Beyond that the description adds no behavior: nothing about pagination, ordering, whether all sets are returned, or whether any filtering/scope applies. It essentially restates the purpose rather than disclosing traits the annotations don't already imply.

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 front-loads the verb and resource and spends its remaining words on the consumption context. Nothing 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 this is close to sufficient, but with no output schema the agent gets no sense of what an 'automation set' object looks like (identifiers, names, fields needed for create_proposal). That missing return-shape hint is the main completeness 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 baseline is 4; there is nothing for the description to clarify. It doesn't need to compensate for any schema 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 and resource ('Lists automation sets') and adds what the result is for ('optional input to create a new proposal'). No sibling tool covers automation sets, so an agent can distinguish it from get_proposal_templates / get_design_templates without opening schemas, though it doesn't explicitly contrast with 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?

The description anchors usage by naming the downstream consumer: call this when you need automation sets to feed create_proposal. It gives clear context but no exclusions, prerequisites, or explicit statement of when the call is unnecessary (the sets are 'optional').

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. Beyond that, the description adds nothing: it doesn't say what 'all details' includes, what happens if the id is unknown (error vs empty), or whether the lookup crosses workspace boundaries despite being open-world.

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 eight-word sentence with the resource and lookup key front-loaded; nothing is wasted. It is arguably too terse rather than too verbose.

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?

This is a simple read tool with no output schema, so the description doesn't need to explain return values. However, 'all details' is left undefined, and for an open-world lookup the agent gets no sense of scope or failure behavior.

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%, but the schema is a single unconstrained string, and the description's 'by id' confirms contact_id is an identifier rather than a name. That is minimal added meaning for a one-parameter tool, so a mid score is warranted.

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 ('Get all details for a contact') and names the key input ('by id'), which separates it from search_contact_people and create_contact. It stops short of explicitly contrasting with siblings, so it lands at 4 rather than 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 search_contact_people or get_initial_context, and no mention of prerequisites such as needing a known contact_id. The agent must infer usage entirely from the name and the single required parameter.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds the useful context that these templates feed proposal creation, but says nothing about result size, ordering, pagination, or whether the list is workspace-scoped.

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 purpose arrives immediately. Slightly loose phrasing ("which are used to create new proposals") but nothing that wastes the reader's time.

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, annotation-covered read tool this is close to sufficient, but with no output schema the description could still say what a template record contains (notably the ID an agent would pass to create_proposal). That linkage is arguably the most important thing to state and is only hinted 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-parameter tool applies. No conflicting or missing parameter meaning is implied.

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 ("Lists available design templates") and adds the functional role — used to create new proposals. It does not, however, distinguish itself from the neighboring get_proposal_templates, get_email_templates, and get_text_templates, which is the main ambiguity an agent would face.

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?

Provides no explicit when-to-use guidance, no prerequisites, and no mention of alternatives. With four template-listing siblings in the toolset, the absence of routing guidance leaves the agent to guess which template list feeds a proposal-creation workflow.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds only that the templates are used for sending proposals; it says nothing about whether all templates are returned, pagination, ordering, or whether account-level custom templates are included.

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, redundancy, or restatement of the title. Nothing could be trimmed without losing 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 simple zero-parameter list tool with no output schema, the description is adequate but thin: the agent does not know if the result is paginated, filtered by account, or whether templates need to be looked up by id afterwards. A short note on return scope 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the schema is trivially complete. Baseline 4 applies for a no-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 verb ('Lists') and a specific resource ('email templates'), plus the domain purpose ('used to send proposals'). It is distinguishable from siblings such as get_design_templates or get_text_templates by the resource name, though the description never explicitly contrasts 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives, despite the sibling list containing four other template-listing tools (get_design_templates, get_proposal_templates, get_text_templates, get_automation_sets). The agent must infer from the noun 'email' alone which template tool 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=true and openWorldHint=false, so safety is covered; the description adds the genuine behavioral fact that this is a mandatory bootstrap call whose output is server usage instructions and context. It stops short of describing the shape or size of that returned content, but no output schema exists to carry that load either.

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 imperative constraint first and the payload second. Nothing is redundant and no sentence could be removed without losing 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 zero-parameter, read-only bootstrap tool this covers the essentials: when to call it and roughly what comes back. Only a hint about the returned content's format or size would improve it, which is a minor gap given the tool's simplicity.

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; the empty schema with additionalProperties=false is self-explanatory. Baseline of 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?

States a specific action and payload: it retrieves usage instructions and Offorte context for this MCP server. That distinguishes it cleanly from all the sibling data-access tools (search_*, get_*), though the phrasing 'get ... context' is slightly abstract about what the caller actually receives.

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, unconditional ordering rule: call this before any other tool. There is no ambiguity about when to use it or what the alternative would be, and the 'IMPORTANT' marker front-loads the constraint.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds real value by disclosing the shape of the result (price tables with unique IDs and rows), but says nothing about behavior when the id is invalid, permissions required, or result size.

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

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

One front-loaded sentence with no filler, and the most useful clause (what the payload contains) follows the core purpose. Nothing is wasted, though the phrase "all details" is slightly vague.

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

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

With no output schema, the description carries the burden of explaining returns and does so by naming price tables, their unique IDs, and rows. For a single-parameter read tool with annotations already covering safety, that is nearly complete; only id-provenance and failure behavior are 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 0% and the single parameter has no description, but the name proposal_id combined with "by id" in the description is self-explanatory; there is no format, range, or source detail to add. The description neither helps nor harms parameter understanding here.

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

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

States a specific verb and resource ("Get all details for a proposal by id") and even previews the payload ("price tables with their Unique IDs and rows"). It does not name the sibling search_proposals, so it stops short of a 5, but the retrieval-by-id 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?

There is no explicit when-to-use guidance, no prerequisite that the id must come from search_proposals, and no statement about when to prefer this over the sibling search tool. The only guidance is the implicit "by id", which the agent must infer.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds real value by disclosing the return grouping and enumerating the five status buckets (edit, open, won, lost, closed). It stops short of describing what a directory record contains or whether results are paginated, which matters since no output schema exists.

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

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

A single front-loaded sentence with the resource first and the grouping detail in parentheses. No filler, no restatement of the tool name, and the status enumeration is packed 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 a parameterless read-only listing this is close to adequate, and the status taxonomy is the key missing piece that it does supply. However, with no output schema the description is the only source of return-value information, and it never explains what a 'proposal directory' is or how the groups are shaped.

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 the schema is an empty object with additionalProperties=false, so there is nothing for the description to disambiguate. Baseline 4 applies per the rules for parameterless tools.

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

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

States a specific verb and resource (get proposal directories) plus the grouping dimension and the five status values. It is distinguishable from get_proposal_details and search_proposals at a glance, though the term 'directories' is left unexplained, so an agent can't be fully certain what entity is returned.

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 gives no when-to-use guidance and does not mention the sibling tools search_proposals or get_proposal_details, which an agent could easily confuse with this one. Usage is only inferable from the 'get all' phrasing — there is no stated prerequisite, scope, or exclusion.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds domain context but no behavioral details such as pagination, ordering, permissions, or what happens when no templates exist. It does not disclose traits 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?

The description is a single front-loaded sentence with no redundant wording. Every phrase contributes to identifying the resource and its 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?

For a simple zero-parameter listing tool with annotations and no output schema, the description is largely complete. It could mention whether the list is paginated or whether it returns all templates, but those gaps are modest given the tool's simplicity.

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 there is no parameter semantics to explain. The baseline for a parameterless tool is 4, and the description appropriately does not invent parameters or filters.

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: 'Lists proposal templates.' It also explains their role as starting points for new proposals. It does not explicitly differentiate from sibling template tools such as get_design_templates or get_email_templates, but the resource name is sufficiently distinctive.

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 'used as starting points to create new proposals' implies when the tool is relevant, but there is no explicit guidance on when to call it versus search_proposals, get_proposal_details, or the other template-listing siblings. Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds only that these templates feed proposal creation; it says nothing about pagination, ordering, language coverage, or whether the list is tenant-scoped.

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. It is hard to trim further, though the subclause about proposal creation could be the leading clause if usage were the priority.

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?

This is a simple zero-parameter read tool, so the bar is low, but with no output schema the description does not tell the agent what the list entries contain (IDs, language codes, text bodies) or how to use them in a subsequent create_proposal call. That missing link is what an agent most needs 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?

The tool takes zero parameters, so there is no parameter meaning to convey; baseline for parameterless tools applies. Nothing in the description contradicts or misleads about inputs.

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

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

Specific verb plus resource ('Lists available language text templates') with added scope explaining what the templates are for ('used to create new proposals'). It partially distinguishes from siblings like get_proposal_templates and get_email_templates, though the boundary between 'language text templates' and 'proposal templates' is not made explicit.

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 by the phrase 'used to create new proposals', giving a loose hint about when an agent would want this list. There is no explicit statement of when to prefer this over get_proposal_templates, get_design_templates, or get_email_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 and openWorldHint=true, so the safety profile is covered. Beyond that the description adds almost nothing: it does not say whether matching is substring, prefix, or exact, whether results are paginated or capped, or what an empty result looks like — key unknowns for a search tool.

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 sentence with the resource and matching dimension front-loaded and no filler. It is efficient, though its brevity borders on under-specification.

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 one-parameter read-only search with no output schema needs little, and the description covers the core intent. It is still incomplete on match semantics and result limits, which an agent needs to call and interpret 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 0% — the single 'search' parameter is typed as a bare string with no description. The description partially compensates by clarifying that the value is an organisation name rather than an ID, but it gives no syntax, length, or partial-match hints.

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 (search) and resource (organisations) and scopes it to matching by name within contacts, which implicitly separates it from search_contact_people. It is clear what the tool does, though it never explicitly names the sibling it differs from.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance is given: nothing tells the agent when to pick this over search_contact_people, search_proposals, or get_contact_details. The only implicit signal is the word 'organisations' in the name and description.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that: it does not say whether matching is exact or partial, whether results are capped or paginated, or how many records come back.

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 the key scope front-loaded and zero filler. It is efficient, though it leaves room for an additional clause that would have earned 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?

For a one-parameter read tool with no output schema and annotations covering safety, the definition is minimally adequate. An agent can call it, but the lack of any statement about matching behavior or return shape leaves real 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?

With one parameter and 0% schema description coverage, the description carries the burden, and it does add meaning by saying the search string is a person name rather than a generic term. However, it says nothing about substring vs prefix matching, case sensitivity, or whether multiple query forms 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 ("Search for people") and scopes it to the contacts domain, which implicitly distinguishes it from the sibling search_contact_organisations. It stops short of naming that sibling or stating the people-vs-organisations distinction 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?

There is no when-to-use guidance, no mention of alternatives such as search_contact_organisations or get_contact_details, and no stated preconditions. The agent must infer that this is the lookup path when only a name is known.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. Beyond that the description says nothing: whether "query" is exact match, keyword, or full-text, whether results are ranked or capped, and whether matching covers titles, clients, or body content are all undisclosed.

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 sentence, front-loaded with the verb and resource, with zero filler. Brevity here reflects under-specification rather than tight editing, but 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?

With no output schema and 0% parameter documentation, the description is the only place search semantics and result shape could be explained, and it explains neither. An agent can form a guess but cannot predict what it gets back or how to shape the query.

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% for the single `search` parameter, so the description must carry the burden. "By query" only restates the parameter name and adds no syntax, format, or matching-behavior detail that would tell an agent what string to supply.

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?

"Search for proposals by query" states a specific verb (search) and resource (proposals), so an agent knows the operation at a glance. It does not differentiate itself from siblings such as get_proposal_details, get_proposal_directories, or get_proposal_templates, 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?

There is no guidance about when to use this search versus get_proposal_details (fetch one known proposal) or get_proposal_directories (browse structure). The word "search" implies a lookup use case, but no condition, exclusion, or alternative is stated.

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 destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the agent knows this is an irreversible outward-facing action. The description adds nothing beyond that: it does not explain that delivery happens by email, that a resend creates a duplicate send, or what send_method 'offorte' versus 'self' actually changes about the 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?

It is a single short sentence with no wasted words and the core action is front-loaded. However, that conciseness comes at the cost of under-specification rather than efficiency, so it cannot score higher.

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?

This is a destructive, non-idempotent, open-world mutation with five parameters, no output schema, and no parameter documentation. The description supplies none of the prerequisites, delivery semantics, or parameter meaning an agent needs to invoke it safely.

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 five parameters, so the description must carry the meaning and it carries none. It never explains proposal_id, the offorte/self enum, send_message, send_message_id (likely a template reference), or password_reset — all of which materially change what gets sent.

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 ('Send') and resource ('a proposal') plus the recipient scope ('its assigned contacts'), so an agent can tell this is a delivery action rather than a read. It does not differentiate itself from any sibling (e.g., get_proposal_details or update_proposal_pricetables), leaving that to inference from the names.

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, what preconditions must hold (e.g., the proposal must exist and be in a sendable state), or what to do instead. The only implicit signal is that recipients come from the proposal's assigned contacts, but the description never says so explicitly as a usage 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?

The annotations already flag destructive=true, idempotent=true and openWorld=true. The description adds the crucial detail behind that destructive flag: rows of named tables are wholesale replaced rather than merged, while unnamed tables are untouched. It also discloses the return payload (updated tables plus proposal total), which no output schema provides.

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: the action first, the scope caveat second, the return value last. Nothing is redundant and nothing important is 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?

For a destructive write with a deeply nested row schema and no output schema, the definition covers the top-level contract (replace semantics, scope, return value) but leaves the caller guessing about row field requirements and null handling on replacement. Adequate but with a meaningful 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?

Schema description coverage is 0%, so the description must compensate and it largely does not. It hints that 'pricetables' carries table ids and row data, but says nothing about the many row fields (sku, price, quantity, discount_type, discount_value, recurring_type, vat_percentage, hide_* flags) or about whether omitted optional fields are nulled out during the full replacement.

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: 'Replace all rows of the named price tables in a proposal.' That clearly separates it from the read-only siblings (get_proposal_details, search_proposals) and from create/copy/send proposal tools. It stops short of naming an alternative for partial row edits, which is why it is not 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?

'Tables that are not named stay unchanged' implies partial-update usage and is a useful scoping cue. There is no explicit when-to-use/when-not-to-use guidance, no prerequisite that proposal_id must reference an existing proposal, and no mention of what to do if a table id does not exist.

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