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

No annotations provided, so description fully carries the burden. It discloses the auto-upsert behavior (if email or old_crm_id exists, updates instead of creates). However, it does not mention required permissions, idempotency, or error handling.

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?

Extremely concise: one sentence for purpose, a bullet list for use cases, and one sentence each for auto-upsert and prerequisite. Front-loaded and every sentence earns its place.

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

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

Given 28 parameters and no output schema, the description covers the key behavioral trait (upsert) and prerequisite. However, it omits what the tool returns (e.g., contact ID) and does not address error scenarios or rate limits. Adequate but not comprehensive.

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. Description adds value by explaining the auto-upsert reliance on email and that client_source_id requires get_contact_sources lookup. No additional semantics for other parameters.

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 'Create a new contact in Propstack CRM' and provides specific use cases like registering a lead after a phone call, creating from a web form, and adding a property owner. It distinguishes from siblings (e.g., update_contact) by mentioning auto-upsert behavior.

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

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

Explicitly lists when to use (after phone call, web form submission, add owner) and provides a prerequisite: 'Use get_contact_sources first to find valid source IDs.' It also explains auto-upsert behavior, guiding the agent on when the tool will update instead of create.

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?

Without annotations, the description carries the full burden. It discloses that deals track through pipeline stages and gives example stages, but could be more explicit about side effects or state changes beyond creation.

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?

Approximately 80 words, with the core purpose stated first, followed by usage scenarios and requirements. No unnecessary sentences, every part earns its place.

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

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

Given 9 parameters and no output schema, the description covers required fields, usage scenarios, and references helper tools. It provides sufficient context for the create operation, though return behavior is not explained.

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 adds meaning by explaining the required parameters' roles and referencing helper tools for ID lookups, going 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 clearly states it creates a deal linking a contact to a property, with a specific resource ('deal') and verb ('create'). It differentiates from sibling tools like create_contact and create_property by focusing on the deal object and its pipeline tracking.

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

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

Explicitly lists when to use this tool: after a viewing, contact inquiry, or moving a lead into the pipeline. It also directs users to list_pipelines or get_pipeline for valid IDs, providing clear context and alternatives.

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?

Discloses that ownership appears on both records, but lacks details on side effects like overwriting or prerequisites, which is important for a mutation tool without 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?

Concise, front-loaded, uses bullet points effectively. No unnecessary 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?

Adequate for a simple tool with two parameters, but missing prerequisite information (e.g., contact and property must exist).

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

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

Schema coverage is 100% and schema descriptions are clear. Description adds examples but no additional parameter-specific meaning beyond the schema.

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

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

Clearly states verb 'Link' and resource 'ownership', includes examples and distinguishes from sibling tools like create_contact and create_partnership.

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 clear use cases with bullet points but does not explicitly exclude alternatives or specify when not to use this tool.

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 fully disclose behavior. It describes the core function but omits details such as whether it overwrites existing partnerships, required permissions, side effects, or error conditions. Only the function is stated.

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 very concise: two main sentences followed by bullet points. Every sentence adds value, and the structure front-loads the purpose with examples. No superfluous text.

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 create tool with three parameters and no output schema, the description covers the essentials: purpose, parameters, and examples. It could mention the expected return value (e.g., created partnership object) but is otherwise 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 input schema covers all three parameters with descriptions, but the description adds meaningful context: it explains that 'name' represents a role (e.g., 'Käufer', 'Mieter') and provides examples. This goes beyond the schema's explanation of 'Role name'.

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 that the tool links a contact as a partner (buyer, tenant, etc.) to a property, with concrete examples like 'Frau Schmidt is the buyer of Hauptstraße 12'. It distinguishes from sibling tools like 'create_ownership' or 'create_contact' by focusing on relationship creation.

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 explicitly lists three use cases (link buyer, tenant, any relationship) and explains the 'name' field. However, it does not provide guidance on when *not* to use this tool or mention alternative tools like 'create_ownership' for ownership-specific roles.

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 discloses some behavior (creation with optional owner linking and status lookup) but omits details on side effects, idempotency, auth requirements, or response format. It adds moderate value beyond the tool name.

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 well-structured with bullet points and front-loaded purpose. It efficiently covers key aspects, though some sentences could be merged for brevity.

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 creation tool with 33 parameters and no output schema, the description does not explain the return value (e.g., created property ID) or error handling. It covers parameter usage well but lacks output and completeness 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 coverage is 100%, so each parameter has a description. The description adds contextual guidance (e.g., listing rs_type enum values and examples for rs_category) but mostly reinforces schema info. Baseline 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 'Create a new property (Objekt) in Propstack CRM' and provides specific use cases like 'List a new property from an acquisition call', distinguishing it from sibling tools such as update_property or search_properties.

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 offers clear usage context (acquisition, owner inquiry, project addition) and directs to use get_property_statuses for status IDs and relationships_attributes for linking owners. It does not explicitly state when not to use this tool, but the context is sufficient.

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 should cover behavioral aspects. It discloses that feature booleans use strings ('true'/'false'/omit) and that radius search uses lat/lng/radius. However, it does not mention error conditions, permissions, or whether creation overwrites or merges with existing profiles.

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

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

The description is front-loaded with the core purpose, then uses bullet points and examples. It is longer than necessary but well-organized, with the mapping guide making it highly useful. Could be slightly trimmed but remains effective.

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 high parameter count (43) and no output schema, the description covers key aspects: required client_id, mapping guide, radius search, boolean conventions. It does not describe the return value or error handling, but this is acceptable for a create tool with many optional fields.

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% (all 43 parameters have descriptions). The description adds significant value by providing a natural language mapping guide for many parameters (e.g., '3 Zimmer' → number_of_rooms). This translates user intent into parameter values, which is beyond what the schema 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 'Create a search profile (Suchprofil) for a contact in Propstack' and provides a detailed mapping guide with example. This specific verb+resource combination distinguishes it from sibling tools like list_search_profiles or update_search_profile.

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 explicitly frames this as 'THE killer feature for an AI real estate assistant' and shows how to map natural language to structured criteria. While it provides strong context, it does not explicitly state when NOT to use this tool or mention alternatives like update_search_profile for existing profiles.

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 bears full responsibility. It only states the basic create action without disclosing side effects, permissions, rate limits, uniqueness constraints, or return behavior. Lacks depth for a mutation 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?

Three sentences, no wasted words. The core action is front-loaded, followed by context and examples. Highly efficient.

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 simplicity, the description covers the primary purpose and parameter context. However, it does not describe the return value (no output schema) or any constraints (e.g., unique name). Slightly incomplete but adequate for a straightforward create operation.

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%, but the description adds meaningful context: it explains the 'entity' parameter's purpose (tagging contacts, properties, activities) and clarifies that 'super_group_id' is optional for hierarchy. This goes beyond the brief 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 clearly states 'Create a new tag/label (Merkmal) in Propstack.' and explains the purpose of tags (categorizing contacts, properties, activities). It provides specific examples and mentions optional hierarchy, distinguishing it from other create tools that create different entities.

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

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

The description implies usage (creating tags for categorization) but does not explicitly state when to use this tool versus alternatives (e.g., other creation or categorization methods). No when-not or alternative guidance is 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?

Without annotations, the description effectively discloses key behaviors: the mode is determined by flags, body accepts HTML, and tasks are linked via IDs. It covers the four distinct creation behaviors. However, it does not mention side effects like notifications or idempotency, which would improve 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 well-structured with clear sections for each mode, using bold headers and bullet points. It is concise despite the complexity, with every sentence contributing value (e.g., examples, mode definitions). No redundant or vague statements.

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 (21 parameters, 4 modes) and the absence of an output schema, the description is adequate. It covers all key use cases, provides examples, and explains parameter dependencies. The agent can correctly invoke the tool for any of the four activity types without additional information.

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 description adds significant meaning beyond the input schema by grouping parameters into modes and providing concrete examples. It clarifies conditional requirements (e.g., due_date requires is_reminder; starts_at requires is_event). This helps the agent understand parameter relationships and usage context.

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 task, which can be a note, to-do, appointment, or cancellation. It uses the verb 'create' and specifies the resource 'task' in Propstack. It distinguishes itself from sibling tools like update_task and get_task by being the central write endpoint for all activity types.

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 explicit usage guidelines by defining four modes with examples for each: note, to-do, appointment, cancellation. It explains how to set specific flags to achieve each mode, and advises linking tasks to contacts, properties, or projects via *_ids arrays. This helps the agent choose the correct mode and parameters.

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?

Describes that Propstack will POST to target_url and mentions HMAC verification with secret, providing good behavioral context beyond the input schema. No annotations exist to contradict.

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?

Concise yet informative: purpose stated first, then behavior, event list, and examples—all in a well-structured manner 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?

Comprehensive for a 2-param tool with no output schema: covers purpose, behavior, events, and usage examples, leaving no obvious 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?

Schema coverage is 100% and description adds value by listing common events and explaining the target_url's purpose, going 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 clearly states it creates a webhook to subscribe to CRM events, differentiating it from sibling tools like delete_webhook and list_webhooks.

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 clear context on when to use the tool with examples of automation triggers and events, but does not explicitly state when not to use it or mention alternatives.

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 fully reveals the behavioral trait: it's a soft delete that moves the contact to a 30-day recycle bin with restore capability. This goes beyond the basic schema and is critical for the agent to understand consequences.

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?

Four concise sentences: first states the primary action, second explains the behavior, third lists use cases. No wasted words, efficiently structured.

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 tool with no output schema, the description covers the essential behavior (soft delete, recycle bin, use cases) completely. No gaps 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 schema already covers the single parameter 'id' with 100% description coverage. The description adds no additional semantics beyond the soft-delete context. Baseline 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 the action 'Delete a contact' and specifies it's a soft delete, distinguishing it from potential permanent deletions. It uniquely identifies the resource and verb, and no sibling tool performs the same function.

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 lists three explicit use cases (GDPR deletion, removing duplicates, cleaning test data), providing good guidance on when to use. It could be improved by mentioning when not to use (e.g., for urgent permanent removal), but the context is clear.

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 full burden for behavioral disclosure. It only states 'Delete a search profile' without mentioning permanence, required permissions, or side effects like cessation of notifications.

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 plus a bullet list, with no unnecessary words. It is front-loaded with the tool's core action and immediately provides usage guidance.

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 delete tool with one parameter and no output schema, the description covers purpose and usage scenarios adequately. It lacks some behavioral details like irreversibility, but remains fairly 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 input schema fully describes the single parameter 'id' as 'Search profile ID to delete'. The description adds no further parameter-level detail, so 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 specifies the verb 'Delete' and the resource 'search profile from Propstack'. It distinguishes itself from sibling tools like create_search_profile, update_search_profile, and list_search_profiles.

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 explicit usage scenarios: when a contact found a property, profile created in error, or contact asks to stop notifications. It lacks explicit when-not-to-use or alternative tool references, but the stated conditions are helpful.

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?

Describes effect of stopping events, but no details on irreversibility or confirmation. Adequate given simple delete operation.

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: first states purpose, second explains effect. No filler 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?

Complete for a simple deletion tool. Could mention valid ID requirement but not necessary. No output schema 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?

Schema provides 100% coverage for parameter 'id' with description 'Webhook ID to delete'. Description adds no extra meaning, baseline 3.

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?

Clearly specifies verb 'Delete', resource 'webhook subscription', and domain 'Propstack'. Distinguishes from sibling tools like create_webhook and list_webhooks.

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 explicit when-to-use or alternatives. Usage is implied but lacks guidance on prerequisites like obtaining the webhook ID.

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 description states the tool returns the full contents of the selected table, which is the primary behavior. However, with no annotations provided, the description carries the full burden of transparency and does not disclose potential limitations like rate limits, data volume handling, or whether the operation is read-only. More detail on response size or pagination would be beneficial.

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

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

The description is front-loaded with the main purpose and use cases, followed by an organized list of tables. It is concise given the number of tables, though the list could potentially be shortened if some tables are less relevant. Overall, it is well-structured and efficient.

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 export tool with no output schema, the description covers the purpose, usage, and available tables adequately. It does not detail the output format (though JSON is mentioned) or handling of large datasets, but for most use cases, the description provides sufficient context. Slight improvement could mention if the export is per-page or all-in-one.

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 the 'table' parameter described via an enum and brief description. The description adds value by grouping the enum values into categories (Core, Activities, Media, etc.), providing semantic context beyond the raw list, which aids an AI agent in selecting the correct table.

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 is for bulk exporting an entire data table as JSON, listing specific use cases (reporting, backup, migration, analytics) and providing an extensive categorized list of available tables. This distinguishes it well from sibling tools that focus on specific CRUD operations or searches.

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 explicitly mentions use cases and lists available tables, giving clear context for when to use the tool. However, it does not provide explicit guidance on when not to use it or how it compares to alternatives like search or create tools, which would be helpful for an AI agent deciding between tools.

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 full burden. It discloses that the tool combines 4 API calls in parallel and lists the categories of data returned (contact details, search profiles, active deals, recent activity). It does not mention authentication, rate limits, or potential latency, but the core behavior is transparent.

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 and well-structured: a clear purpose sentence, a bullet list of components, and a usage recommendation. No unnecessary 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?

Given no output schema, the description lists what data is returned (contact details, profiles, deals, activity). It is sufficient for understanding the tool's output. However, it could mention that the response is a composite object, but overall it is 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?

Only one parameter (contact_id) with 100% schema description coverage. The description does not add extra meaning beyond the schema. Baseline 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 the tool's purpose: 'Get a complete 360° view of a contact'. It mentions combining 4 API calls and provides a concrete example ('Tell me everything about Herr Weber'), distinguishing it from siblings like get_contact.

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 explicitly advises 'Use this when you need the full picture', giving a clear usage context. However, it does not contrast with sibling tools like get_contact or specify when not to use it.

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

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

No annotations provided, so the description carries full burden. It correctly describes the tool as a read operation (get details) and mentions the ability to include related data via the 'include' parameter. No side effects are implied, which is appropriate for a GET-like 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?

Extremely concise and well-structured: three sentences, each with a clear purpose. The first sentence states the primary function, the second lists use cases, and the third explains a key parameter. No redundant 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?

Given 2 parameters, no output schema, and no annotations, the description covers the essential aspects: what it does, when to use, and how to use the include parameter. Could optionally mention return format or required permissions, but overall sufficient for effective tool usage.

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 adds value by explaining the 'include' parameter's purpose (load related data in one request) and lists example values (children, documents, etc.), enhancing understanding beyond the schema.

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

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

The description clearly states the tool retrieves full details of a single contact by ID. It lists specific use cases (view before call, check relationships/documents/properties, see sub-contacts), distinguishing it from sibling tools like search_contacts or create_contact.

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 explicit use cases (view before call, check related data) and mentions the 'include' parameter for loading related data. However, it does not explicitly state when not to use this tool or contrast with search_contacts for listing contacts, which would be helpful.

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 bears full responsibility. It correctly implies a read-only operation ('Get... Returns the list...'), which is consistent with the tool name. It does not mention any side effects or permissions, but for a simple retrieval tool, this is adequate.

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—two sentences, no filler. The main action is front-loaded, and every word adds value. It is optimally sized for its simplicity.

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

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

With only one parameter and no annotations, the description covers the purpose and use case. However, it lacks information about the output format (e.g., list of property IDs or objects), which would be helpful given no output schema. Otherwise, it is reasonably complete for a simple get tool.

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

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

Schema coverage is 100% (contact_id described as 'Contact ID'). The description does not add any further meaning beyond the schema. It mentions 'contact' in the use case but does not elaborate on the parameter format or constraints.

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 action ('Get properties that a contact has favorited/bookmarked') and the resource ('contact favorites'), with an explicit use case ('understand which listings a buyer is most interested in'). It distinguishes itself from siblings by focusing on favorites retrieval, which no other sibling tool does.

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 explains when to use the tool ('to understand which listings a buyer is most interested in'), which provides clear context. However, it does not explicitly state when not to use it or mention any alternative tools, leaving some room for ambiguity.

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 exist, but the description correctly implies a read-only listing operation by stating it 'returns the list of sources... with their IDs'. It could mention static nature or cache behavior, but for a simple list, this is sufficient.

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 concise sentences: first states purpose, second gives examples, third provides actionable guidance. No wasted words, and the structure is logical and front-loaded.

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 zero parameters and no output schema, the description fully covers the tool's behavior: it lists sources with IDs, gives examples, and explains when to use it. Nothing essential is missing.

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

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

The tool has no parameters and the schema is empty, so the description adds value by explaining the return type and usage context, which helps the agent understand what to expect beyond the schema.

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

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

The description explicitly states 'List all available contact/lead sources in Propstack' and provides concrete examples like 'Immobilienscout 24', 'Website', 'Empfehlung', making the purpose immediately clear. No sibling tool has a similar function, so it is distinct.

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 directly advises using this tool to look up valid source IDs before creating or updating contacts with client_source_id, providing explicit when-to-use guidance and practical context.

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 full burden. It states it returns the pipeline with stages in order, which is adequate for a simple read operation but doesn't explicitly confirm no side effects or other behavioral traits.

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

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

Two sentences that are clear and front-loaded with the key action and result. No superfluous information.

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

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

The description covers purpose, usage context, and what is returned. For a simple one-parameter tool without output schema, this is nearly complete. Minor omission: no example or format details for the response.

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

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

Schema coverage is 100% and the schema already describes the id parameter. The description adds 'by ID' but doesn't significantly enhance understanding beyond the schema.

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

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

The description clearly states the tool gets a single deal pipeline by ID with its stages, which is a specific verb+resource. It distinguishes from siblings like list_pipelines by focusing on a single pipeline with stage details.

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

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

The description explicitly says 'Use this when you already know which pipeline you need and want its stage details,' providing clear context. It doesn't mention alternatives but the context with sibling tools implies them.

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 full burden. It discloses the complete return data (units, images, floorplans, documents, links) and specific details like unit statuses and prices. It does not cover auth or rate limits, but for a read operation this is acceptable.

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 and well-structured: a clear one-sentence summary followed by bullet points for usage. Every sentence adds value, and the main purpose is front-loaded.

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 no output schema and low complexity (single parameter), the description covers the necessary information: purpose, return content, and use cases. It lacks details on pagination or limitations, but those are irrelevant for a single-project retrieval.

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 covers the single parameter 'id' with description 'Project ID'. The description adds value by explaining the scope of the response (full details), which goes beyond the schema's minimal info. With 100% schema coverage, baseline is 3, and the extra context justifies a 4.

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 'Get full details of a single project by ID', specifying the verb, resource, and scope. It distinguishes from sibling tools like 'list_projects' which list multiple projects, and 'get_property' for a different entity.

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 explicit use cases in bullet points, such as checking unit statuses and viewing media. It does not mention when not to use it or alternatives, but the context is clear enough for the agent to decide.

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 full burden. It discloses that it always fetches with new=1 and expand=1, providing extra fields and custom fields. This goes beyond basic purpose. However, it does not cover authentication or rate limits.

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

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

The description is extremely concise, using a short header and bullet points. Every sentence adds value, and the main action is front-loaded.

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-property retrieval tool with no output schema, the description covers all key aspects: returned data (images, floorplans, documents, links, custom fields, project), multilingual support, and hidden parameters. It is 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 coverage is 100%, but the description adds value by explaining that include_translations is for 'multilingual texts' and that locale parameter exists. This exceeds the schema descriptions alone.

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

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

The description clearly states 'Get full details of a single property by ID' and lists specific use cases (view images, floorplans, documents) that distinguish it from sibling tools like search_properties which lists multiple properties.

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 explicit use cases and mentions the locale parameter, but does not explicitly state when not to use it or compare with alternatives. The context is clear enough for an agent to infer appropriate usage.

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 fully carries the burden. It transparently describes the tool as a list operation returning statuses with IDs, colors, and sort positions. No hidden side effects or surprises are implied.

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 paragraphs: the first states what the tool does and what it returns; the second gives usage context. Every sentence is useful and there is 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?

Despite lacking an output schema, the description specifies the return value (statuses with IDs, colors, sort positions). Given the simplicity of the tool (no parameters, no side effects), the description is sufficiently 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 has zero parameters, so schema coverage is effectively 100%. The description adds value by explaining the output structure (statuses with IDs, colors, sort positions), which compensates for the lack of an input schema. Baseline for 0 parameters is elevated.

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 that the tool lists all available property statuses, providing examples ('Verfügbar', 'Reserviert', 'Verkauft') and the data returned (IDs, colors, sort positions). It is distinct from sibling tools which create, update, or search other entities.

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 explicitly instructs when to use this tool: before filtering properties by status in search_properties or before setting a status in create_property or update_property. It names specific sibling tools and provides actionable 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?

No annotations provided, so description carries the burden. It discloses that linked entities are expanded by default and lists specific details returned. However, it does not mention read-only nature, rate limits, or authentication needs, which are typical for a get operation.

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: one opening sentence, one sentence on default behavior, and a bulleted list of use cases. No redundant information, front-loaded with 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?

Despite no output schema, the description adequately explains the return value (linked entities, specific fields like contacts, properties, projects, viewings, appointment details, todo status). For a low-complexity tool with only 2 parameters, this is fully sufficient.

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% with descriptions for both parameters. The description adds value by explaining default expansion behavior and giving examples of what the 'include' parameter controls, going beyond the schema.

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

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

The description clearly states the verb (get), resource (task), and method (by ID). It distinguishes from sibling tools like search_activities and list_* tools by focusing on a single task with full detail.

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

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

Explicit bullet points list specific use cases (view context, check linked entities, see appointment details, check completion). While it doesn't explicitly state when not to use, the context is clear and informative.

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 burden of behavioral disclosure. It does not explicitly state that the tool is read-only or mention any side effects, auth requirements, or rate limits. However, it implies a read operation ('List') and explains output structure, which is adequate but not exhaustive.

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 well-structured: a concise first sentence summarizing the purpose, followed by clear bullet-point-like explanations of categories and usage. Every sentence adds value without 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?

Given that there is no output schema, the description compensates by listing the output fields (id, name, category) and explaining their use. It also covers the relationship with create_task and search_activities, making the tool's role in the ecosystem clear.

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

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

The single parameter 'category' is described in the schema with enum values and a description. The tool description goes beyond by explaining the real-world meaning of each category and how it maps to task creation fields, adding significant context that is not in the schema alone.

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

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

The description clearly states 'List all activity/task types in Propstack.' It specifies the resource (activity/task types) and verb (list), and distinguishes from related siblings like search_activities by explaining the output (id, name, category) and how categories map to different task creation fields.

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 explicit usage guidance: it maps each category to the appropriate ID field in create_task (note_type_id, todo_type_id, event_type_id, snippet_id) and explains how categories correspond to search_activities filter values. This helps the agent decide when to use this tool and how to apply the results.

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 bears the full burden. It implies a read-only listing but does not disclose any behavioral traits such as pagination, caching, or ordering. The description is straightforward but could be more transparent.

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 short, consisting of three sentences with no fluff. Each sentence adds value: stating the action, explaining usage, and giving examples.

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?

Despite no output schema, the description provides sufficient context for a simple listing tool: it lists contact statuses and explains how to use the IDs. It is complete 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?

There are no parameters (0 params), so schema coverage is 100% by default. The description does not need to add parameter meaning since none exist, earning the baseline score of 4.

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 'List contact statuses' with a specific verb and resource, and provides examples like 'Lead', 'Kunde', 'Archiviert'. It distinguishes itself from sibling list tools by specifying 'contact statuses'.

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 explicitly instructs how to use the IDs for search_contacts and create_contact/update_contact, providing clear context of use. It does not mention when not to use, but the guidance is direct.

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 the return structure in detail (field groups, fields with name, pretty_name, type, options) and explains how to use the results. It does not mention any destructive behavior or authentication, which is acceptable for a read-only list operation.

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 well-structured with clear sections: purpose, usage, return format, cross-references. It is not overly verbose and front-loads the key information. Minor redundancy (e.g., 'IMPORTANT' and then same info) could be trimmed, but overall efficient.

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 no output schema, the description fully explains the return values and how to interpret them. It covers input, output, and usage context comprehensively. Adequate for a simple tool with one parameter.

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 coverage is 100% with the 'entity' parameter already documented via enum and description. The description does not add extra parameter semantics beyond what the schema provides, but the schema itself is sufficient. Baseline 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 'List custom field definitions for an entity type in Propstack.' It uses a specific verb+resource and distinguishes itself from sibling tools by explaining that it discovers fields before reading/writing.

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

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

Explicitly says 'Call this tool to discover what custom fields exist before reading or writing custom field values.' It also provides guidance on when to use other tools (search with expand, write with partial_custom_fields), making the usage context very clear.

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 fails to disclose pagination behavior, default sorting, or any limitations. The description focuses on what the tool lists but not on how it behaves (e.g., rate limits, response structure).

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 well-structured with a clear main purpose, followed by examples and usage guidance. It is front-loaded and informative, though slightly verbose with the bullet points. Could be trimmed but still effective.

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

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

Given the lack of an output schema and annotations, the description provides reasonable context about document types and filtering rules. However, it omits details about the return format (e.g., pagination metadata) and any behavioral constraints, which are necessary for full 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?

Schema coverage is 100%, so baseline is 3. The description adds value by emphasizing the 'exactly one filter' constraint and listing document types, which helps the agent understand parameter usage. However, it does not elaborate on page, per_page, or sort beyond the schema.

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

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

The description clearly states the tool lists documents attached to a property, project, or contact, with specific examples of document types. It differentiates well from sibling tools like upload_document and other list/search 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?

The description provides explicit guidance on when to use the tool, including concrete use cases and the critical instruction to filter by exactly one of property_id, project_id, or client_id. It does not explicitly mention when not to use it, but the positive guidance is strong.

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 full burden. It covers event states but omits pagination behavior, result ordering, scope of results (user-specific?), and whether it is read-only. Some key behavioral aspects 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 structured with a definition, bulleted use cases, and event states. It is informative but could be slightly more concise without losing clarity.

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 14 parameters, no output schema, and no annotations, the description covers usage and states but fails to describe the return format, default pagination, or sorting behavior, leaving gaps for an AI 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%, yet the description adds meaningful context by illustrating how parameters are used in practice (e.g., 'List upcoming viewings for a broker') and explaining event states, exceeding the schema's bare 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 it lists calendar events in Propstack, provides examples of event types, and enumerates specific use cases. It differentiates from sibling tools like search_activities by focusing on events.

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 includes explicit use cases and lists event states, but does not mention when to avoid using this tool or suggest alternatives for non-event 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?

No annotations provided; description adequately conveys that the tool is a read-only list operation returning IDs and names, but lacks additional behavioral details such as authentication or rate limits.

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

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

Three concise sentences front-load the core purpose and immediate usage, with no redundant or extraneous 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 parameterless list tool, the description sufficiently covers purpose, output content, and usage, despite lacking an output schema.

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

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

No parameters exist; schema coverage is effectively 100%. Description adds value by clarifying the usage context of the returned data beyond the schema.

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

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

Description clearly states the tool lists geographic areas/districts (Geolagen) and specifies the purpose for property and search profile matching, distinguishing it from sibling tools that handle other entities.

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

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

Explicitly indicates when to use the returned location IDs (creating search profiles, filtering properties), providing practical usage context, though it does not mention when to avoid this tool.

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?

Without annotations, the description carries full burden. It explains what is returned (ordered stages with IDs, names, etc.) but does not explicitly state that the tool is read-only or safe, nor does it mention any side effects or auth requirements.

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, front-loaded with the main purpose, and every sentence adds value. It efficiently covers what the tool does, why it's needed, and typical examples without unnecessary 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?

Given no output schema, the description fully explains the return values (stage IDs, positions, colors, chance percentages) and provides usage context and typical pipelines. It is complete for a simple listing 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?

No parameters exist, so baseline of 4 applies. The description adds no parameter information because there are none, but it is consistent with the schema.

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

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

The description explicitly states the tool lists all deal pipelines and their stages, with specific verb and resource. It clearly differentiates from siblings like get_pipeline and pipeline_summary by its plural nature and mention of stages.

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 clear context on when to use: before create_deal or update_deal if stage IDs are unknown. However, it does not explicitly mention when not to use it or compare with get_pipeline for a single pipeline.

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 provided, so description carries full burden. It discloses expand behavior but lacks details on pagination, rate limits, or default sorting. Adequate but not rich.

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?

Concisely written with clear structure: headline, definition, bullet use cases, and parameter note. Every sentence adds value; no fluff.

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?

Completeness is good given no output schema and 100% parameter coverage. Missing some behavioral details (e.g., pagination defaults), but overall covers purpose, use cases, and expand parameter well.

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. Description adds value for expand parameter but not for page or per_page. Overall minimal additional meaning beyond schema.

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

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

The description clearly states the tool lists development projects in Propstack and defines what a project is. It distinguishes from sibling tools like get_project by focusing on listing all active projects.

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?

Description lists explicit use cases: see all active projects, get unit counts and statuses, find by name. Lacks mention of when not to use or alternatives like get_project, but context is clear.

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, and the description only states 'list', implying read-only, but does not explicitly disclose behavioral traits like idempotency, auth requirements, or rate limits. More transparency would be beneficial.

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

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

Two sentences, no fluff. Front-loaded with purpose and immediate usage context. Every sentence adds value.

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 parameters and no output schema, the description provides all necessary context: what it lists and when to use it. No missing information.

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?

There are zero parameters, so the input schema covers 100% by default. The description adds no parameter-level detail needed, but meets the baseline of 4 as per guidelines for 0-parameter 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?

The description explicitly states it lists deal cancellation reasons and provides specific use cases (creating cancellations, filtering lost deals). This clearly distinguishes it from sibling tools like search_deals or create_task.

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 explicitly says when to use the tool: for create_task with reservation_reason_id and search_deals with reservation_reason_ids. It does not include when-not-to-use or alternatives, but the context is clear and sufficient given the siblings.

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 full responsibility. It correctly implies a read-only operation (listing) and explains the entity's purpose. However, it does not disclose pagination behavior, rate limits, or whether the tool returns all results or only active profiles (the bullet says 'all active' but the description doesn't clarify filtering). This is a moderate 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 concise and well-structured: it starts with a clear one-line summary, explains the concept briefly, lists key use cases in bullet points, and ends with a specific example filter. Every sentence adds value, with no superfluous content.

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

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

Given the tool has 3 optional parameters, no required parameters, and no output schema, the description should cover output and pagination details. It mentions 'list all active' but doesn't explain pagination limits or default behavior. It also omits what fields are returned. This is adequate but not fully 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%, providing baseline parameter explanations. The description adds contextual value for the 'client' parameter ('See what a specific contact is looking for') but does not enhance 'page' or 'per_page' beyond what the schema already provides. Overall, it meets the baseline without exceeding expectations.

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 'List search profiles' with a specific verb and resource. It explains what a search profile is and provides concrete use cases, such as filtering by client. The sibling tools list includes create/delete/update functions for search profiles, so this tool is clearly the list variant, making it distinct.

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 offers explicit usage scenarios: see what a contact is looking for, list all active profiles, review criteria before matching. It advises filtering by contact ID. However, it does not explicitly exclude alternative tools (e.g., search functions) or mention when not to use this tool, so it misses some comparative 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?

No annotations provided, so description carries full burden. It discloses return format (flat list with Name and ID) and optional hierarchical view via super_groups, adding behavioral context beyond schema.

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

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

Description is concise with two sentences plus a bullet-like list for entity options, and a note on return format. Every sentence adds value without 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?

Given no output schema, description covers return format, entity filtering, and super_groups behavior. Missing pagination/limits but acceptable for a simple list tool.

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

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

Schema coverage is 100% with descriptions. Description adds meaning by explaining entity filter purpose and hinting that super_groups may 'try' hierarchical view, going beyond raw schema.

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

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

Description clearly states 'List all tags/labels' with specific resource and filtering by entity, distinguishing it from sibling tools like create_tag.

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 context for using returned IDs with search_contacts and create_contact/update_contact, and explains entity filtering options, though no explicit when-not-to-use or alternatives are mentioned.

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 description must disclose all behavioral traits. It correctly indicates a read-only list operation, but does not explicitly state safety (non-destructive) or mention potential pagination or performance characteristics. Adequate for a simple list with no 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?

Two concise sentences that front-load the core purpose and add value with return details and usage guidance. No wasted words.

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

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

Given no parameters and no output schema, the description fully covers the tool's capability: it lists all teams, returns broker assignments, and is used for filtering and understanding structure. No missing information.

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?

There are no parameters, so schema coverage is trivially 100%. Description adds no parameter detail, but none is needed. Baseline for 0 parameters is 4.

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?

Description clearly states it lists all teams/departments in Propstack and specifies it returns broker member assignments. Distinguishes from sibling tools like list_users (which lists individual users) and list_projects (which lists projects).

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

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

Explicitly says 'Use for team-level filtering and to understand the organizational structure,' providing clear context for when to use. Does not include when-not-to-use or alternatives, but the purpose is sufficiently clear.

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 is responsible for behavioral clarity. It states the tool returns a list of users with specific fields, implying a read operation. However, it does not mention pagination, authentication, or other constraints, which would be helpful for complete 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 concise, with three clear sentences: purpose, return values, and usage scenarios. It is front-loaded with the main action and avoids unnecessary detail. Every sentence serves a 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?

Given no parameters and no output schema, the description completely covers the tool's purpose, return data, and practical applications. It is self-contained and provides all necessary context for an agent to use 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?

The input schema has zero parameters, and the description acknowledges this by focusing on output. It adds value by explaining what the tool returns and why it's useful (for getting broker IDs). Baseline for 0 params is 4, and the description meets this.

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 'List all brokers/agents (Nutzer) in the Propstack account.' It uses a specific verb and resource, and distinguishes itself from sibling tools like list_teams by focusing on users/brokers. The return fields are enumerated, aiding understanding.

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 explicitly outlines when to use the tool: to obtain broker IDs for assigning contacts/properties, filtering searches, setting email senders, and assigning tasks/events. This provides clear context, though it does not explicitly mention when not to use it or alternatives.

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 present; description discloses return fields but does not explicitly state read-only nature, authentication needs, or potential side effects.

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 with key information front-loaded; no unnecessary verbiage.

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?

Covers the essential output fields and use case; lacks mention of pagination or limits, but acceptable for a simple list 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?

With zero parameters and 100% schema coverage, the description adds no param info but explains the output meaning, which 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 the action ('list all configured webhooks') and distinguishes from siblings by focusing on retrieval vs. creation/deletion.

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 explicit usage guidance ('Use to review existing automation triggers'), though it does not mention when not to use it (e.g., if a filtered list is needed).

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 fully discloses the tool's behavior: it fetches property details, paginates search profiles capped by max_profiles, scores on multiple criteria, and returns top 20 matches. It also explains the capping rationale (limits API calls and memory).

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 well-structured with a clear overview, usage guidance, and logical steps. It is concise without unnecessary words, and every sentence contributes to understanding.

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 with multi-step matching, the description covers all necessary aspects: input, process, and output (ranked list, top 20, scores, details). No output schema is needed as the description suffices.

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

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

Schema coverage is 100%, and the description adds value by explaining the purpose of max_profiles (default 1000, caps API calls/memory) and implying property_id's role. This goes beyond the schema's brief 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 'Find contacts whose search profiles match a property', using a specific verb and resource. It distinguishes this tool from sibling search tools by focusing on matching contacts to a property, which is a unique capability.

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 explicitly provides a use case: 'Use when a new listing comes in to find potential buyers/renters', with an example question. It lacks explicit exclusions or alternatives, but the guidance is strong.

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 explains the aggregation logic (counts, totals, stale deal detection) but does not disclose potential side effects, authentication requirements, or performance considerations. The behavioral disclosure is moderate.

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, front-loaded with the main purpose, and structured into digestible bullet points. Every sentence adds value without 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?

Without an output schema, the description adequately explains what the tool returns (deal count per stage, total value, stale deals). It also covers filtering. However, it does not describe the response structure (e.g., whether it's a list of stage objects) or pagination, leaving minor 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?

The input schema has 100% parameter description coverage (broker_id and pipeline_id). The description adds usage context (filtering options) but does not provide additional semantic depth beyond what the schema already states. Baseline 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 provides a pipeline overview with deals per stage, total values, and stale deals, and includes specific query examples like 'How's the pipeline looking?'. This distinguishes it from sibling tools that list or search individual entities.

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 explicitly says when to use the tool ('use when asked: "How's the pipeline looking?" or "Give me a sales overview."') and mentions optional filters. It lacks explicit 'when not to use' or alternative tools, but the context is clear.

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 provided, so description carries full burden. It discloses that the tool combines 3 API calls in parallel and calculates specific metrics (days on market, total inquiries, deals by stage, activity breakdown). This provides good behavioral insight beyond basic purpose.

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?

Description is concise and well-structured. It uses bullet points and a clear example, making it easy to scan. No unnecessary sentences.

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

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

Despite having no output schema, the description fully explains what the report contains (specific metrics, data sources, calculations). An agent can confidently understand what will be returned.

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?

Only one parameter (property_id) with 100% schema coverage. Description does not add extra semantics for the parameter beyond what the schema already provides ('Property ID to generate report for'). The description focuses on overall behavior, not parameter detail.

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?

Description clearly states the tool generates a performance report for a property, listing specific metrics (days on market, inquiries, pipeline breakdown, activity summary). It distinguishes from siblings like 'get_property' and 'search_deals' by being a composite report.

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 a concrete usage example ('How is the Friedrichstr property doing?'), making it clear when to invoke. Does not explicitly state when not to use or list alternatives, but the context is strong.

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 description states activities are read-only, indicating a safe, non-destructive operation. No annotations are provided, so the description carries full burden; it adds no further behavioral context such as permissions, rate limits, or result volume.

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 well-structured with a clear opening, bullet-pointed use cases, and an activity type list. It is appropriately sized for the complexity, though it could be slightly trimmed without losing value.

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 no output schema and 9 optional parameters, the description covers key use cases, filter options, and activity types. It references list_activity_types for completeness, leaving no major gaps for an agent to use the tool effectively.

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

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

Schema coverage is 100%, and the description adds meaningful context beyond the schema, e.g., explaining client_id shows all activity for a contact, and listing activity types with examples. This helps the agent understand parameter usage.

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 searches the activity feed/timeline, lists what activities include (emails, notes, etc.), and provides specific use cases. It effectively distinguishes the tool's purpose from sibling tools like list_events by focusing on the broad activity feed.

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 explicitly lists when to use the tool (e.g., viewing interaction history, tracking broker activity) and suggests using list_activity_types for valid types. It does not mention when not to use or directly compare to alternatives, but the guidance is clear and contextual.

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 full burden and effectively discloses key behaviors: pagination, phone search formatting insensitivity, cross-field search for 'q', and the expand parameter for full details. It does not cover rate limits or auth but adequately describes the search 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 concise and well-structured: a header line followed by bullet points listing use cases. Every sentence adds value, and it is front-loaded with the purpose. No fluff, appropriately sized for a search tool with many 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?

Given the 26 parameters, lack of output schema, and no annotations, the description covers major use cases and adds behavioral details (phone search insensitivity, cross-field search). It mentions pagination and expand. It is nearly complete, though could mention default pagination values (but those are in schema). The sibling search_contacts_by_phone is a slight redundancy but not a 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 coverage is 100%, so parameters are documented. The description adds significant meaning beyond schema: explains the 'q' parameter searches across specific fields, details phone_number formatting insensitivity with examples, and clarifies the archived parameter's special values. This enriches understanding.

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 is for searching and filtering contacts in the CRM, listing specific use cases (find by name/email/phone, list recent leads, etc.). It effectively distinguishes from sibling tools like get_contact (single contact) and search_contacts_by_phone (phone-specific).

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 scenarios for when to use the tool (e.g., find contacts, list recent leads). However, it does not explicitly state when not to use it or mention alternative tools like get_contact for a specific contact. The bullet points offer good context but lack 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 provided, the description carries the full burden. It adds a key behavioral trait: 'Phone matching ignores formatting' with examples. However, it does not mention read-only nature, response structure, or any limits. The return statement is vague ('key details'). Adequate but not thorough.

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 four front-loaded sentences. Every sentence adds value: purpose, when to use, formatting behavior, fallback action. No redundant or unnecessary text.

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 1-param tool with no output schema, the description covers the core: what it does, when to use, formatting behavior, return summary, and no-match handling. It is nearly complete, though it could mention if multiple matches are possible or ordering. Minor 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 100%, so the schema already documents the parameter well. The description repeats the formatting behavior and adds examples of acceptable formats, which adds marginal practical value. Baseline 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 'Look up a contact by phone number' with a specific verb+resource. It further specifies the use case as 'go-to tool for voice agent caller identification', which distinguishes it from sibling tools like search_contacts (presumably for other criteria) and get_contact (for ID).

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 explicitly tells when to use the tool: 'When a call comes in, use this tool with the caller's phone number'. It also provides post-action guidance: 'If no match is found, the caller is unknown and you should create a new contact.' It lacks explicit when-not-to-use, but the context and implied alternative (search_contacts) are clear.

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 provided, so description carries full burden. It explains the concept of deals, pipeline stages, categories, and the include parameter for expanded data. As a read operation, destructive behavior is not expected, but auth needs or rate limits are not mentioned. Still, it is transparent about core functionality.

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 overly long with several paragraphs. While it provides comprehensive information, it could be tightened. The structure is logical (definition, usage, include option, examples) but lacks brevity.

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 25 parameters, no required ones, and no output schema, the description sufficiently covers the tool's purpose, filtering options, and use cases. It does not explain return format or pagination details beyond schema, but the provided context is adequate for agent selection.

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

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

Schema coverage is 100%, and the description adds significant context beyond parameter descriptions: explains deal stages, feeling scores (cold/warm/hot), category meanings (qualified, unqualified, lost), and provides common query patterns. This enriches parameter understanding.

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 searches and filters deals, defines a deal as a contact-property relationship in a pipeline, and lists specific use cases. It distinguishes from sibling tools like search_contacts or search_properties by focusing on deals.

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

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

Explicitly lists when to use the tool with examples (e.g., show all deals in a pipeline stage, find deals for a contact/property, track pipeline progress). Lacks explicit when-not-to-use or direct comparisons to alternatives, but the examples provide strong 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?

Without annotations, the description carries the behavioral transparency burden. It mentions that the tool always returns total count and optionally expand custom fields. It does not discuss rate limits, error handling, or detailed output structure. While adequate for a read tool, more transparency about pagination or defaults would improve it.

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

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

The description is well-structured with bullet points and examples, front-loading the purpose. It is somewhat lengthy but justified given the tool's complexity (39 parameters). Every sentence adds value, though a slight trim could improve conciseness.

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 large number of parameters and no output schema, the description covers usage patterns well, including examples and total count mention. It lacks description of return structure (e.g., object fields), but for a search tool, it is fairly 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?

With 100% schema coverage, baseline is 3. The description adds value by explaining the range filter pattern (from/to), grouping numeric fields, and clarifying the scope of the 'q' parameter. Examples demonstrate common usage, going beyond the schema.

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

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

The description clearly states the verb ('search and filter') and resource ('properties in Propstack CRM'), distinguishing it from sibling tools like get_property (single property) and list_projects (projects). It provides specific details about search criteria.

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 includes explicit guidance on when to use the tool, such as finding properties by address, ID, or filtering by various fields. It provides common query examples. However, it does not explicitly state when not to use it or alternatives, though sibling differentiation is implicit.

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 emails are sent through connected broker accounts, that emails can be linked to CRM objects, and that templates may contain auto-filled merge fields. This provides good insight into 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 well-structured with bullet points and clear sections. It is concise yet thorough, with every sentence adding value.

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