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

With no annotations, the description carries full responsibility for behavioral disclosure. It mentions optional webhook notifications but does not explain that this persists a resource, the need for authentication, how webhooks are triggered, or what the return payload looks like. Key behavioral traits are missing.

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

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

The description is two short sentences, front-loaded with the core action. Every phrase adds meaning, and it avoids redundancy or fluff, making it highly concise for a tool with 40 parameters.

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

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

For a tool with 40 parameters, no output schema, and no annotations, the description is too high-level. It doesn't mention that all parameters are optional, what the response will be, or any important side effects or constraints. It leaves the agent without critical context for correct invocation.

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

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

Schema coverage is 100%, so baseline is 3. The description groups parameters into location, price, size filters, and webhook endpoints, which adds a helpful conceptual structure but doesn't explain individual parameters beyond what the schema already provides.

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

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

The description clearly states the tool creates a saved search, with a specific verb and resource. It distinguishes from sibling read/search tools by emphasizing creation and optional webhook notifications, though it doesn't explicitly compare with update-search or delete-search.

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 is provided on when to use this tool versus alternatives like search-properties for immediate results or update-search for modifying existing searches. The description focuses purely on what the tool does, not on selection criteria.

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?

Since no annotations are provided, the description must convey behavioral traits. It states the deletion action but fails to disclose whether deletion is permanent, reversible, or whether it has side effects (e.g., deleting alerts or favorites). For a destructive operation, this is a lack of transparency.

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, direct sentence with no unnecessary words or redundancy. It is highly 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?

The tool is simple (one parameter, no output schema), but the description lacks any mention of expected response, error handling, or irreversible consequences. Although minimal, it leaves gaps for an agent without annotations.

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 input schema fully documents the single parameter 'id' with the description 'Search ID,' and the tool description simply restates that the deletion is by ID. The description adds no additional semantic information beyond the schema, so it meets 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?

The description uses the specific verb 'delete' and identifies the resource as 'saved search' with the criterion 'by its ID,' clearly differentiating from sibling tools like get-search, update-search, and create-search.

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 explicit guidance on when to use this tool instead of others, nor any prerequisites or exclusions. It only implies usage by the tool's name and the action 'delete,' so the usage context is implied but not 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?

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the high-level action without explaining what 'similar' means, how results are ordered, or any side effects. This is a significant gap for a tool with pagination and sorting parameters.

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 concise, with the core action front-loaded in the first sentence. The second sentence adds usage context but is somewhat generic. Overall, it is appropriately sized without unnecessary verbosity.

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

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

With no output schema and 9 parameters, the description should explain what results look like and how similarity is determined. It only states 'find properties similar' without detailing the return structure, pagination behavior, or sorting options, leaving significant gaps for the agent.

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. The description does not add parameter-level meaning, but the schema already documents all 9 parameters including the required 'id' field. No further compensation is needed.

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 specifies a clear verb ('Find') and resource ('properties similar to a given property'), differentiating it from siblings like search-properties (general search) and get-property (single property by ID). It uniquely identifies the tool's purpose for similarity-based lookup.

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 provides context by stating the tool is 'useful for market comparisons and finding alternatives,' which implies when to use it. However, it does not explicitly mention alternatives or when not to use it, falling short of a 5.

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?

No annotations are present, so the description carries full burden. It tells the core behavior (searching cities and returning IDs), but lacks details about pagination, result limits, or side effects. It is not misleading, but it does not disclose much beyond the basic function.

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

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

The description is two sentences, front-loaded with the action and criteria, and a second sentence on purpose. Every word earns its place; no repetition of schema details.

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

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

Given the tool has 11 parameters, no output schema, and no annotations, the description is somewhat minimal. It clarifies the primary use case and return value, but does not mention pagination, sorting, or other filter options, leaving the agent without full context for a more complex search.

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 only 45%, and the description partially compensates by listing search criteria (name, zipcode, INSEE code, polygon). However, it does not explain parameters like page, slug, sortByName, or excludeGroupedCities, leaving gaps for an agent to interpret.

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

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

The description clearly states the tool's function: 'Search French cities by name, zipcode, INSEE code, or geographic polygon.' It also specifies the output's purpose ('Returns city IDs needed for property search filters'), which distinguishes it from sibling tools like search-properties or get-points-of-interest.

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 when to use the tool: when city IDs are needed for property search filters. It provides context by mentioning the search criteria and the output, but it does not explicitly rule out alternatives like location-autocomplete, which could also be used for city lookups.

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?

No annotations are provided, so the description carries the full burden. It states 'Returns facilities within a radius' but does not disclose read-only nature, auth requirements, default radius, or edge cases, leaving gaps.

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 concise sentences, front-loaded with the purpose. No redundant wording.

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 lookup tool, it states it returns facilities within a radius, but lacks details on response format, radius defaults, or pagination. Since no output schema exists, the description should provide more, but it is not severely incomplete.

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

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

Schema description coverage is 100%, so baseline is 3. The description rephrases the coordinate/radius concept but does not add meaningful details beyond what the schema already provides.

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

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

The description uses a specific verb 'Find' with a clear resource 'points of interest' and lists examples (schools, hospitals, restaurants, parking). It is distinct from sibling tools which are property-related.

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

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

The description clearly implies usage for finding facilities near a location within a radius. It doesn't explicitly exclude alternatives, but the context is clear and no similar sibling exists.

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?

No annotations are provided, so the description must carry full behavioral transparency. It states the output is statistics but does not disclose whether filters are required, how aggregation works, or what the time series structure looks like. This leaves the agent uncertain about invocation prerequisites.

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

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

The description is two sentences, front-loaded with the action and output, and the second sentence provides a relevant use case. Every word 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 77 optional parameters and no output schema, the description is too thin. It does not explain the response structure, whether any location or date filters are required, or how time series data is grouped. Additional context about the aggregated nature and expected response format is needed.

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 input schema already provides descriptions for all 77 parameters, so the description adds no additional parameter-specific meaning. Since schema coverage is 100%, the baseline applies; the description only generically refers to 'filters' without highlighting which parameters are most relevant for price-per-meter analysis.

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

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

The description uses a specific verb 'Get' and identifies the exact resource 'price per m² statistics' with output types (average, median, time series). It clearly distinguishes this from sibling tools like search-properties or get-property by focusing on aggregated statistics.

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 a use case ('market analysis and property valuation') but no explicit guidance on when to use this tool versus alternatives like search-properties. It implies overlap by mentioning 'filters' but does not clarify the key distinction between aggregate stats and individual listings.

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?

With no annotations, the description carries the burden of behavioral disclosure. It clearly states the data included (adverts, price history, photos, contact info, transit stations), which gives useful context. However, it does not disclose potential error cases, authorization requirements, or whether the operation is strictly read-only, leaving some transparency gaps.

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, focused sentence that front-loads the purpose ('Get full details for a single property') and then lists specifics. Every clause adds value with no filler.

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

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

For a single-parameter lookup tool, the description is largely complete: it names the input (UUID) and describes the output scope in enough detail to inform use. While there is no output schema, the enumerated content list compensates. Minor lack of error/edge-case handling prevents a perfect score.

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 already documents the sole parameter 'id' as 'Property UUID', and the description reinforces that by saying 'by UUID.' Since schema description coverage is 100%, the description adds no additional parameter-level meaning beyond emphasizing the identifier's role.

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

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

The description uses a specific verb 'Get' with a clear resource 'single property by UUID' and enumerates the scope: 'full details ... including all adverts, price history events, photos, contact info, and nearby transit stations.' This distinguishes it from sibling tools like search-properties and get-points-of-interest, which target different operations or resources.

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 'by UUID' implicitly tells the agent to use this when a known property ID is available, but there is no explicit statement about when to prefer it over siblings such as search-properties or find-similar-properties. No exclusions or alternative conditions are given.

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?

No annotations are present, so the description carries the full burden of behavioral disclosure. It only says 'Get details,' which gives minimal insight into return format, possible error behavior, or permissions, and does not enumerate what 'details' 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?

The description is a single, front-loaded sentence that states the action and resource with no redundant wording.

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 one-parameter get-by-ID tool, the description is minimally adequate but incomplete: it does not specify what fields the returned details include, nor behavior when the ID is not found. The tool's low complexity partially compensates for this 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 schema already fully documents the single parameter with 100% coverage, describing 'id' as 'Search ID.' The description adds little beyond this, merely reinforcing that the ID identifies a specific saved search without providing format examples or additional nuance.

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

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

The description uses the specific verb 'Get' with the resource 'specific saved search' and identifies the selection mechanism by ID. This clearly distinguishes it from sibling tools like list-searches and delete-search.

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 'by its ID' establishes a clear context for when to use this tool: to retrieve one saved search when the ID is known. It implicitly contrasts with list-searches for listing all searches, though it does not explicitly name alternatives or exclusions.

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

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

With no annotations, the description carries the burden. It discloses that the operation is scoped to the authenticated user and supports filtering, but it does not specify behavior such as pagination defaults, whether the list is empty-safe, or if this is a read-only operation, though 'List' implies non-mutating.

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

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

The description is a single concise sentence that immediately states the core function and provides useful filter context without extraneous 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 simple list operation with no annotations or output schema, the description gives the essential purpose but omits details about the return structure or pagination behavior, which the page parameter hints at but doesn't clarify.

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. The description mentions filtering by notification status and title, echoing two parameters, but adds no extra semantic detail beyond the schema descriptions.

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

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

The description uses a specific verb 'List' and identifies the resource 'saved searches for the authenticated user' with the ability to filter, distinguishing it clearly from sibling tools like get-search or create-search.

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 clearly states this tool lists saved searches for the authenticated user, providing context on when it should be used. It does not explicitly exclude alternatives like get-search for individual searches, but the scope is clear enough.

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?

No annotations are provided, so the description must carry the burden of behavioral disclosure. It mentions that it returns IDs needed for filters, which is useful, but it doesn't describe the response structure, whether cities and departments are returned together, ordering, pagination, or edge cases like empty results.

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, well-structured sentence that immediately states the purpose and the output's role, with no filler or 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?

For a simple autocomplete tool with full schema coverage, the description adequately explains what the tool does and how the output is used downstream. However, without an output schema, a bit more detail about the response format would improve completeness.

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 input schema has 100% coverage, with clear descriptions for all three parameters (query, excludeCities, excludeDepartments). The tool description itself doesn't add meaning beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description clearly states it autocompletes cities and departments by search query, and explicitly mentions that it returns IDs needed for location filters in search-properties and create-search. This specific verb+resource combination distinguishes it from sibling tools like get-cities.

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

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

It explicitly says the returned IDs are needed for location filters in search-properties and create-search, giving clear context on when to use the tool. While it doesn't mention when not to use it or name alternatives, the downstream consumer tools are referenced, providing sufficient guidance.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It reveals that results are paginated and include property details, adverts, photos, and nearby stations. It also hints at a dependency on location-autocomplete for ID resolution. It does not mention auth, rate limits, or read-only nature, but 'search' implies non-mutating behavior.

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

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

The description is three sentences, front-loaded with purpose, then return content, then a practical tip. Every sentence earns its place with no redundancy or filler.

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

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

For a complex tool with 81 parameters and no output schema, the description provides a solid overview of the search capability and return payload. It covers filter categories and pagination, but does not detail parameter combinations (e.g., radius requires lat/lon), though the schema handles those details.

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%, giving a baseline of 3. The description adds value by advising to use location-autocomplete for city/department IDs, which directly informs parameters like includedCities and includedDepartments. This extra guidance goes beyond the schema's descriptions.

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

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

The description clearly states the tool 'Search French real estate properties' with a specific verb and resource, and enumerates extensive filter categories. It distinguishes itself from siblings like get-property (single property) and find-similar-properties by framing this as a general search tool. The return content (pagination, details, adverts, photos, nearby stations) further clarifies scope.

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 a clear usage context: searching properties with filters, and provides a prerequisite: 'Use location-autocomplete first to resolve city/department IDs.' However, it does not explicitly state when not to use this tool or name alternatives, so it lacks 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?

No annotations are provided, so the description carries the full burden. It discloses that the tool sends a simulated payload, which is a test action with no persistent side effects. However, it does not mention potential response behavior, authentication requirements, or error handling, leaving some behavioral ambiguity.

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

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

The description is two sentences, front-loaded with the core action, and every word earns its place. No fluff or 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?

The tool is simple with 2 parameters, both fully described in the schema, and an enum for event type. The description covers purpose and usage. It might be slightly improved by noting the response format after sending, but given the low complexity, it is largely 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?

Schema description coverage is 100%: both 'endpoint' and 'type' have descriptions in the schema. The description adds minimal extra meaning beyond the schema, only framing the payload as 'simulated match or event.' The baseline of 3 applies because the schema already documents the parameters adequately.

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

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

The description clearly states the tool's purpose: 'Test webhook delivery by sending a simulated match or event payload to an endpoint.' It uses a specific verb ('Test') and resource ('webhook delivery'), and the mention of 'simulated payload' distinguishes it from sibling tools, which are all property-related.

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

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

The description provides clear usage context: 'Useful for verifying webhook integration.' This implies when to use the tool, and the sibling tools (e.g., search-properties, get-property) are unrelated, so no explicit alternatives are needed. However, it lacks explicit when-not-to-use guidance.

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

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

With no annotations provided, the description must disclose behavioral traits but only says 'update'. It does not specify whether the update is partial (only provided fields) or full replacement, nor does it mention side effects, error handling, or idempotency. For a mutation tool with 41 optional parameters, this is a significant transparency 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?

The description is a single concise sentence that captures the core purpose without redundant wording. It is front-loaded with the primary action and resource, making it easy to parse quickly.

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

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

Given the tool's complexity (41 parameters, no output schema, no annotations), the description is far too minimal. It does not explain update semantics, return values, or error conditions. While sibling tool names provide some context, the description alone is insufficient for an agent to safely and correctly invoke this 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?

The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds high-level categorization (criteria, filters, webhook configuration) which helps users mentally organize the many parameters, but it does not deepen understanding of individual parameters beyond what the schema already provides.

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

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

The description clearly states the verb 'update' and the resource 'existing saved search', making it distinct from sibling tools like create-search and delete-search. The scope 'with new criteria, filters, or webhook configuration' adds specificity without ambiguity.

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 'existing saved search' implies this tool is for modifying already-created searches, which differentiates it from create-search. However, it does not explicitly state when not to use it or mention alternative tools, leaving some room for interpretation.

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