Qobrix CRM MCP Server

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

With no annotations provided, the description carries the full burden and does well by disclosing server-side pagination with a 20,000-row cap and in-process computation. This goes beyond schema info. It does not mention what happens when the cap is exceeded or any side effects, but for a read-only aggregation tool these are relatively minor gaps.

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

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

The description is front-loaded with the core function, followed by behavioral details and three illustrative examples. It is longer than a minimal description but every sentence contributes meaningful information, making it 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?

The description covers purpose, behavior, and parameters comprehensively with examples. However, since there is no output schema, it does not explicitly describe the return format (single aggregate vs. bucket list), nor does it address behavior when pagination cap of 20,000 rows is reached. These omissions leave some context incomplete for a complex aggregation tool.

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

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

Schema description coverage is 100%, and each parameter already has detailed semantics (op enum, search DSL, group_by, resolve, resource list). The tool description adds value through examples but does not introduce new parameter meaning beyond what the schema provides; it reinforces usage rather than expanding semantics.

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

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

The description clearly states the tool's function: aggregating a numeric field via sum/avg/min/max/count across records, with optional grouping and top-N buckets. It provides concrete examples (total 2026 closed-sale volume, agent leaderboard, average list price) that distinguish it from sibling list/search tools and specialized aggregation tools like qobrix_count or qobrix_top_values.

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

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

It explicitly mentions 'which is how to get totals on Qobrix fields the API won't sort', giving a clear when-to-use signal. Multiple examples illustrate real use cases. However, it does not explicitly state when not to use it or name alternative tools for simpler counts or time-series aggregations, so it stops short of full exclusions.

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

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

With no annotations, the description carries full burden. It discloses that without a prefix the entire cache (memory + Redis) is cleared, with a prefix only matching keys are cleared, the default TTL of 300s, and that the return value indicates cleared entries per tier. This is strong coverage, though it stops short of discussing the broader performance impact of clearing the whole cache.

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

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

The description is three sentences that efficiently cover purpose, trigger condition, mode behavior, examples, and return value. There is no filler; every sentence contributes meaningful 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 tool with a single optional parameter, the description is fully self-sufficient. It explains what the tool does, when to use it, how to use it in both modes, with examples, and what it returns. No output schema is needed because the return behavior is described.

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

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

The schema already documents the optional 'prefix' parameter with full coverage. The description adds value beyond the schema by providing real-world examples (e.g., 'v1:request:opportunities' for lead lists) and clarifying the behavior difference between including and omitting the prefix.

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 'Invalidate cached Qobrix responses' with a specific verb and resource. It is distinct from all sibling tools, which are read/search/analysis operations, by focusing on cache invalidation.

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 this tool: 'when CRM data was edited in Qobrix and you need fresh reads before the TTL expires.' It also gives concrete examples for prefix usage. However, it does not mention when not to use it or alternative tools like qobrix_cache_stats.

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 stats are process-local and reset on restart, and it describes what the tool reports. It does not explicitly state that it is read-only, but 'Inspect' implies this, and no side effects are mentioned. The process-local caveat is valuable behavioral context.

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 what it does, second gives usage guidance, third notes a critical limitation. No filler, front-loaded with the action and resource, 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?

For a zero-parameter, no-output-schema diagnostic tool, the description is nearly complete. It names all key metrics and gives a caveat about process-local resets. It could theoretically specify the exact return shape, but the listed metrics suffice for an agent to know what to expect.

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

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

The tool has zero parameters, so schema coverage is complete. The description adds semantics by detailing exactly which stats are returned, effectively describing the output fields. Baseline for 0 params is 4, and the description meets that by providing meaningful return-value 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 opens with 'Inspect the response cache' and enumerates specific metrics (hits/misses, in-memory size, in-flight coalesced requests, TTL, Redis tier status). This clearly differentiates it from sibling tools, especially qobrix_cache_clear, by focusing on inspection rather than mutation.

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

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

It explicitly says when to use the tool: 'to verify the cache is paying off' and 'to diagnose why a query feels slow', giving concrete scenarios (high hits, low misses, cold cache, Redis degraded). It does not name alternatives because none exist for stats, but the usage 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the internal logic for each mode (e.g., 'walks closed contracts → opportunity_id → opportunities.contact_name') and details the exact return fields (deal_count, total_volume, etc.). It does not mention authentication, rate limits, or cost, but for a read-only reporting tool, the disclosed behavior is solid.

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 and every sentence adds value: overview, mode explanations, return fields, and concrete examples. It is longer than a trivial sentence but appropriate for a tool with 9 parameters and three modes. The examples are concise and directly illustrate usage.

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

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

The tool has 9 optional parameters, no output schema, and no annotations. The description covers the core functionality, all three modes, and the return data shape, which is sufficient for most usage. However, it doesn't explain how parameters interact (e.g., 'year' vs 'from/to' vs 'since_days') or edge cases like conflicting windows, which would be helpful for complete guidance.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the 'kind' parameter's three modes in depth and providing example values for 'year', 'min_count', and 'since_days' in context. It also clarifies the meaning of 'buyers' vs 'sellers' vs 'leads' beyond the enum names. However, it does not add extra nuance for parameters like 'contract_types' or 'contract_statuses' beyond what the schema already states.

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

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

The description clearly states the tool's function: finding contacts that appear on multiple deals or opportunities, with a specific verb ('Find') and resource ('contacts'). It distinguishes itself from sibling list/search tools by focusing on repeat-customer cohort analysis across deals and opportunities, and describes three distinct modes.

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

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

The description gives concrete example use cases with parameter combos (e.g., '2026 repeat buyers', 'All-time loyal customers'), making when to use the tool clear. However, it does not explicitly contrast with alternative sibling tools like qobrix_deals or qobrix_aggregate, which could also be used for similar analytical queries.

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

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

With no annotations, the description carries the safety/behavior burden. It discloses that the tool returns only a count and no data payload, and that it's faster/lighter, which is the key behavioral trait. It does not mention error cases or auth requirements, but for a count operation these are less critical.

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, quickly states the performance benefit, then provides three compact examples. Each sentence serves a distinct function; no redundant or filler 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?

The description explains the return type (total count, no payload) and gives representative examples for the search DSL. It could mention output format or edge cases, but the examples and performance note cover the main usage scenarios adequately.

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 with three concrete example search expressions spanning different resources and operators, illustrating how to combine filters and use shortcuts like THIS_MONTH. This exceeds the schema's already detailed parameter documentation.

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 opens with a specific verb and resource: 'Count records matching a search expression', explicitly distinguishing from list/fetch tools by stating it returns only the total count, no data payload. This clearly separates qobrix_count from sibling search/list tools.

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

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

It explicitly says 'Faster and lighter than fetching records when you only need a number', giving clear when-to-use context. It doesn't name specific alternative tools or exclusions, but the general fetch vs count distinction 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?

With no annotations to fall back on, the description discloses the join, computation, defaults for kind and listing_date_field, the per-row fallback chain, valid group_by fields, outlier behavior, and example combinations. This gives a complete picture of how the tool behaves beyond the raw 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?

Front-loaded with a one-sentence purpose, then dense, purposeful details: defaults, fallback, grouping, outliers, and examples. Every sentence adds information or practical guidance; nothing is wastefully verbose.

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

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

Without an output schema, the description explains the aggregate metrics returned and mentions outlier deals, which covers the main return behavior. It stops short of specifying output ordering or pagination, but for an aggregation tool this is reasonably 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 covers 100% of parameters with descriptions, so baseline is 3. The description adds practical value by showing realistic parameter combinations (e.g., { kind: 'sold', year: 2026, group_by: 'city', include_outliers: true }) and reinforcing the meaning of group_by and include_outliers.

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

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

States 'Days-on-market analytics' with explicit formula (close_date - listing_date), join logic, and aggregation metrics (count/mean/median/p75/p90/min/max). Clear verb+resource and distinct from sibling analytics tools like funnel or timeseries.

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 four concrete example uses (overall DOM, by property type, by city with outliers, reservation cycle) that clearly convey when to call this tool. Does not explicitly name alternatives or exclusion criteria, 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?

No annotations are provided, so the description carries the burden. It discloses defaults, overridability, sorting behavior, field resolution, and the in-process nature of sorting. It does not explicitly state read-only behavior, but that is implied for a query tool. It also omits details about pagination or return format, but the examples imply a list of deals.

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 long but packed with valuable information: purpose, defaults, overridable parameters, and seven distinct example uses. It is front-loaded with the core purpose and defaults, then examples. While it could be formatted more cleanly (e.g., bullet points), 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?

For a complex 19-parameter tool with no output schema, the description is quite complete. It covers defaults, parameter relationships, sorting, field resolution, and provides realistic usage scenarios. It does not explain the return structure, but the examples and schema descriptions cover the essentials. Minor gap: no mention of pagination or how the top parameter interacts with the summary block, but that is in the 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?

Schema description coverage is 100%, so baseline is 3. The description adds meaningful semantics by explaining how kind sets contract_types defaults, default date_field behavior, and the effect of include_reserved. The examples demonstrate how parameters combine for real use cases, adding value 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 is a flexible 'deals' tool over the Contracts table covering sales, rentals, listing agreements, and pipeline reservations in a single call. It provides multiple example uses that illustrate its scope and differentiates it from sibling tools like list/search by emphasizing its aggregate/filtering capabilities and ability to resolve 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 gives explicit default behavior (kind='sale', contract_statuses=['agreed']) and a wide range of usage examples (best 2026 closed sales, rentals, pipeline, my deals, revenue >€1M, leaderboard). It even names an alternative approach for a single page of highest prices using list/search with sort='-final_selling_price_amount', providing clear when-to-use guidance.

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

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

With no annotations provided, the description carries the full burden of disclosure. It transparently explains the pagination ('Paginates GET /{resource}/{id}/changes'), filtering logic, return shape (including optional 'user_name'), sorting order, and the resolve_users behavior. It does not mention error handling or rate limits, but covers the core behavioral traits expected of a read-only history 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?

The description is compact and front-loaded. The first sentence states the core purpose, the second details the mechanics, and the final sentence offers a concrete use case. No filler or redundancy—each 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?

For a tool with 5 parameters and no output schema, the description is remarkably complete. It documents the return shape inline, pagination defaults, and a real-world scenario. It omits edge-case behavior like empty results or error conditions, but those are less critical for a simple query 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%, so baseline is 3. The description adds contextual value beyond the schema: it clarifies that 'field' is not the LogAudit.source column, explains the resource-to-URL mapping, and states defaults for max_pages and resolve_users. This helps select and invoke parameters correctly.

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 opens with a specific verb+resource: 'Build a chronological timeline of edits to one field on one CRM record.' This clearly distinguishes it from sibling tools like get_changes or search_changes, which handle broader change queries. The concrete use case 'who changed source on this opportunity and when?' further anchors the tool's purpose.

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

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

The description provides a clear, explicit use case ('who changed source on this opportunity and when?') that signals when to apply the tool. It does not explicitly name alternatives or exclusions, but the focused purpose implies when it is appropriate relative to more general change-history 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?

The description discloses stage definitions, date-window scoping, optional assigned_to/agent scoping, and stage_overrides behavior. Since no annotations exist, this carries the transparency burden; it's mostly clear, though 'cos' in the Closed stage definition is ambiguous.

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?

At around 150 words, the description is dense but well-structured: state chain, scoping rule, override mechanism, then three examples. No redundant information; each 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?

Given no output schema, the description compensates by specifying the six stages and conversion %, the scoping rule, and override capability. The examples cover common use cases, making it sufficiently complete for an AI agent to select and invoke 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 schema already covers all parameters with 100% coverage, but the description adds meaningful examples showing parameter combinations ({year}, {assigned_to, since_days}, {agent, year}) and clarifies stage_overrides semantics. This elevates understanding beyond the 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?

The description clearly states this is a sales funnel tool aggregating six stages (Leads, Qualified, Viewing, Offer, Reserved, Closed) with conversion percentages, distinguishing it from sibling list/search tools. It uses a specific verb 'Canonical sales funnel in one call' and details each stage's definition, making the purpose unmistakable.

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

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

It provides three concrete example uses covering year, rolling days with CURRENT_USER, and agent-specific scoping, demonstrating when to invoke this tool. It doesn't explicitly compare against alternatives like qobrix_deals, but the examples imply this is the go-to for funnel metrics.

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

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

With no annotations, the description carries the burden of disclosing behavior. It reveals the return shape ('Returns { data: { id, ref, ... } }'), lists verified include options, and explains the agent's relationships (e.g., parent brokerage). It does not explicitly state that it is read-only, but 'Get' implies a non-mutating operation. Lacks error/rate-limit details, but the provided context is substantial.

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 longer than average but every sentence adds useful information: purpose, return shape, include options, and a detailed usage pattern. It is front-loaded with the primary purpose, and the pattern section is a structured list that is easy to scan. Slight redundancy in the pattern 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?

For a single-resource fetch with only two parameters, the description is remarkably complete: it covers return format, expand options, and provides a full '360°' workflow with sibling tools. Even without an output schema, an agent can reasonably understand what to expect and how to integrate this call.

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 covers both parameters with descriptions, but the tool description adds value by elaborating the 'include' options (verified list) and showing how the UUID is used in related tool calls (e.g., agent == '<uuid>'). This goes beyond the schema's minimal descriptions, enhancing understanding of 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 'Get a single agent by UUID', specifying the exact resource and operation. It differentiates from sibling tools like qobrix_list_agents and qobrix_search_agents by emphasizing single-agent retrieval by UUID, and from qobrix_get_contact by noting this returns a RESO Member/ListAgent.

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 strong usage guidance: it says to resolve an agent from a listing or lead, and offers an 'Agent 360° pattern' with explicit tool names and filter examples (e.g., qobrix_search_properties with agent == '<uuid>'). This implicitly tells when to use this tool versus alternatives, making it highly 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?

With no annotations, the description carries the full burden. It discloses the return shape as '{ data: { id, ... } }', which is a behavioral trait beyond what the schema provides. It also lists the expandable include associations. It does not mention errors, read-only safety, or pagination (though for a single record this is less critical), so it is not a 5 but is above average.

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 compact and front-loaded with the purpose. The first sentence is the core action, the second provides return structure, and the third lists includes. However, the include list is redundant with the schema's parameter description, so a small amount of the text is wasted. Still, overall it is efficient and readable.

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

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

For a simple single-record get tool with 2 parameters, no output schema, and no annotations, the description provides the essential return shape ('{ data: { id, ... } }') and the expandable associations. It lacks error behavior or explicit read-only confirmation, but these are less critical for a get operation. The description is sufficiently complete for an agent to invoke the tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description repeats the include options that are already fully documented in the schema, adding no additional meaning or syntax details. It does not clarify usage nuances beyond what the schema already states, so it neither improves nor degrades 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 uses a specific verb+resource construction: "Get a single call record by UUID." It clearly identifies the exact scope (single vs. list) and the identifier required, distinguishing it from sibling list/search tools. The addition "call detail in the Activity Tracking workflow" provides contextual framing without ambiguity.

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

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

The description implies when to use this tool (when you need a single call's details by UUID) but does not explicitly state alternatives or exclusions. It does not mention that for multiple calls you'd use qobrix_list_calls, nor does it provide any 'when not to use' guidance. The context of 'Activity Tracking workflow' gives some indication, but it's not explicit.

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 of behavioral disclosure. It describes the response structure (original, changed, user_id, timestamp, type) and clarifies a potential naming pitfall about LogAudit.source. However, it does not explicitly state that the operation is read-only or mention any rate limits or auth requirements, though the GET endpoint implies safety.

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 compact despite covering multiple aspects: purpose, endpoint, output structure, a critical disambiguation, and a cross-reference. Every sentence contributes meaningful information with no filler. The 'IMPORTANT' note is justified and placed appropriately.

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 there is no output schema and no annotations, the description provides a solid overview of what the tool does and returns, including the row fields and the endpoint. It addresses a common confusion and suggests an alternative, making it adequately complete for a moderately complex tool with 7 parameters.

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 baseline is 3. The description does not add significant per-parameter information beyond the schema; it focuses on response structure and a usage caveat. It indirectly clarifies what 'fields' might contain by listing row fields, but this is marginal added value.

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 audit/change-log entries for a single CRM record, specifically naming the Qobrix LogAudit and the endpoint. It distinguishes itself from sibling tools by noting the alternative qobrix_field_change_history for one-field timelines, and implies it is for full audit logs of a single record.

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 provides a use-case alternative: 'For a filtered timeline of one field use qobrix_field_change_history.' This tells the agent when to choose another tool. It also clarifies the intended scope (single record) and gives an important caveat about the LogAudit.source field, which prevents misuse.

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. It discloses the return structure and verified includable associations, which is helpful. However, it omits behavior on not-found, error handling, authentication requirements, or rate limits—context a user might need. It does not contradict any annotations (none exist).

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 first sentence and numbered list, but it is lengthy. The 360° workflow steps, while useful, go beyond the immediate tool description and could distract from the core get operation. Several sentences could be trimmed without losing primary functionality.

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 get tool with no output schema and no annotations, the description provides the return shape, include options, and links to related search tools. It is reasonably complete for an agent to invoke and interpret results, though some edge cases (e.g., missing UUID behavior) are not covered.

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

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

Schema coverage is 100%, so the description adds extra value by listing 'Verified include: AssignedToUsers, User, Language, Organizations' and decoding the return object shape. The 'id' parameter meaning is already in the schema, but the verified include options are additional, actionable details beyond the generic 'Associations to expand'.

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 a single contact by UUID' with a specific verb and resource, and distinguishes it as 'the person/company detail view' from list/search tools. It explicitly positions itself within the Lead-Contact Lifecycle, making its purpose obvious.

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 for a known UUID ('detail view') and provides a detailed 360° journey with alternative tools for related data. However, it does not explicitly say when NOT to use this tool (e.g., for search) or compare with qobrix_list_contacts/qobrix_search_contacts beyond the UUID pointer.

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 does well: it discloses the return shape ('Returns { data: { id, ... } }'), enumerates verified include options with their meaning, and gives a practical usage hint. It doesn't cover error cases or authentication, but for a simple GET tool this is solid behavioral disclosure.

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 long, front-loaded with the core purpose, then return shape, then include semantics, then a practical example. Every sentence earns its place with no fluff or repetition.

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

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

For a tool with just two parameters, no output schema, and no annotations, the description fully covers the essential context: what it does, what the response looks like, what the include parameter options mean, and a concrete usage scenario. There are no obvious gaps for an agent to invoke 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?

Although the schema already documents both parameters with descriptions (100% coverage), the description adds significant semantic value by explaining what each verified include option represents (e.g., Contacts = buyer/seller, PropertyIdProperties = listing). This goes beyond the schema's generic 'Associations to expand'.

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 a single contract by UUID' with a specific resource and action. It also distinguishes itself from sibling list/search tools by describing it as the 'deal close detail view' and specifies the unique purpose in the Transaction Lifecycle context.

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 context for when to use the tool (fetching a single contract detail) and even suggests a specific use case ('Use include=['PaymentInstallments'] to audit the payment timeline'). It doesn't explicitly mention when not to use it, but the context is sufficient for an agent to differentiate from list/search 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 are provided, so the description carries the full burden. It discloses the return shape ({ data: { id, ... } }) and the include options, which is helpful. But it doesn't explicitly state that this is a read-only operation, nor does it mention error handling, pagination, or rate limits. For a simple GET, this is 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?

The description is concise, about 30 words, and front-loaded with the core action. It includes only necessary extras: return format and include options. No fluff or redundancy. The structure is clear and scannable.

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 get-by-ID tool with a well-specified schema, the description is mostly complete. It provides the return format and include options, and the Activity Tracking workflow context adds background. It lacks explicit read-only confirmation and error handling, but given the simplicity and absence of output schema, these are 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 already provides descriptions for both parameters (id and include) with 100% coverage. The description's 'Include: Properties, ...' line essentially repeats the schema's options, adding little new meaning. The return format hint is somewhat useful but not parameter-specific. 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 uses a specific verb+resource: 'Get a single email message by UUID'. This clearly differentiates it from sibling tools like qobrix_list_email_messages, which list multiple messages. The phrase 'email detail in the Activity Tracking workflow' adds contextual clarity about its intended use.

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 context: it's for retrieving one specific email by UUID, which implies use when you have a UUID and need detail, versus a list tool. It mentions the Activity Tracking workflow, giving a concrete scenario. However, it doesn't explicitly exclude alternatives or state 'use this instead of list when you have a UUID'.

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. It discloses the return structure ('Returns { data: [...], pagination: { ... } }'), the per-item fields (id, resource, field, label, value), and provides example queries. This gives useful behavioral insight beyond the name, though it doesn't mention pagination mechanics or potential errors.

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 and front-loaded. It starts with purpose, then return format, item fields, and key examples, ending with a pairing suggestion. Every sentence contributes practical value, and the examples are concise yet informative.

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 read-only lookup tool with 3 parameters and no output schema, the description is complete. It covers purpose, return format, item structure, practical usage examples, and complementary tools. There are no significant 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?

Schema description coverage is 100%, so the baseline is 3. The description adds value by providing concrete search expression examples that clarify the 'search' parameter semantics, and it explains output item structure, which helps infer parameter usage. It doesn't add much beyond schema for page/limit but the examples are a meaningful addition.

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 dropdown/enum field options — discover valid values for status fields, types, and categories.' It uses a specific verb and resource, and the mention of enum options distinguishes it from sibling tools like qobrix_get_schema and qobrix_top_values.

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 context: 'Essential for building correct search expressions in any workflow' and shows concrete examples for common use cases (listing statuses, lead statuses, etc.). It also suggests pairing with qobrix_get_schema for complete field discovery, implying when to use this tool versus the alternative. However, it doesn't explicitly state 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 are present, so the description itself discloses behavior. It explains that the tool returns properties attached to an opportunity in the canonical RESO Demand/Solution matching pattern, and clarifies that it is the demand-side matching tool. It doesn't cover edge behaviors like pagination or auth, but for a simple 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 longer than one sentence but is well-structured: main purpose, then use-case context, alternatives, stage, and parameter clarification. Every sentence adds value, though it could be tightened slightly.

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 a single parameter, no output schema, and no annotations, the description is remarkably complete. It explains what the tool does, when to use it, what the id refers to, and how it fits into the broader process. An agent should be able to select and invoke this tool 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 defines 'id' as 'Opportunity/Lead UUID', which is ambiguous. The description adds precision: 'The id is the Opportunity UUID.' This resolves the ambiguity and adds 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?

The description opens with 'Get properties linked to a lead' which is a clear verb+resource+scope. It further explains the purpose by answering 'What properties does this buyer want?' and distinguishes from the reverse tool qobrix_get_leads_by_property. However, the sibling qobrix_get_properties_by_lead is not mentioned, which could cause ambiguity.

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

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

The description explicitly states when to use this tool: at the Solution/Viewing stage of the buyer journey, and contrasts it with alternatives: for free-language/ranked demand→supply, use qobrix_search_properties/qobrix_search_projects; the reverse operation is qobrix_get_leads_by_property. This gives clear when/when-not guidance.

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

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

With no annotations provided, the description carries the full burden. It discloses that the tool returns paginated results, identifies the matching pattern, and clarifies the propertyId requirement. However, it does not explicitly state read-only behavior or performance trade-offs (e.g., fast path vs. boost), which are left to the 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?

The description is somewhat long (7 sentences) but each sentence provides distinct value—purpose, business question, domain pattern, usage timing, alternatives, parameter clarification, and pagination. Minor redundancy exists between the first and third sentences, but overall it is well-structured 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?

Without an output schema, the description appropriately confirms that the tool returns matching leads and notes pagination. The schema covers page/limit mechanics thoroughly, and the domain context makes the meaning of 'matching' clear enough. It could be even more complete by specifying what fields each lead includes, but this is a 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?

The schema already provides 100% coverage with detailed descriptions for all three parameters, including page/limit behavior with boost. The description's mention that 'propertyId is the Property UUID' largely duplicates the schema's 'Property UUID to find matching leads for' and does not add meaningful new semantics.

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

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

The description uses a specific verb-object structure with a clear resource: 'Get matching leads for a property.' It also explicitly differentiates from siblings by naming itself the 'supply-side matching' tool and referencing complementary tools like qobrix_get_lead_properties and qobrix_search_opportunities.

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 when-to-use guidance: 'Use after listing a new property to find potential buyers in the existing lead database.' It also names specific alternatives for reverse matching and ranked matching, making it clear when this tool is preferred versus the 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 carries the burden of behavioral disclosure. It discloses the return type ('media metadata including URL/path') and the effect of the optional size parameter. However, it does not mention error handling (e.g., not-found behavior), authentication requirements, or any side effects, which leaves some gaps for a read 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 sentences, front-loaded with the main action and resource, followed by targeted parameter guidance. No repetition of schema fields or filler, and every clause contributes actionable information.

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

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

For a simple two-parameter getter with no output schema, the description covers the core purpose, the return value, and the optional parameter semantics. It could mention not-found behavior or clarify the 'Media Lifecycle' context more, but it is sufficiently complete for typical use.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds practical value by explaining the use of the 'size' parameter with concrete examples ('thumbnail', 'medium', 'large') and describing their intended use cases ('preview grids', 'full-resolution display'), going beyond the schema's generic 'Image size variant'.

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 ('single media item by UUID'), and purpose ('media detail view in the Media Lifecycle'). It distinguishes this from sibling tools like qobrix_list_media by emphasizing 'single' and by specifying the return of metadata including URL/path.

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 ('media detail view in the Media Lifecycle') and explicit guidance on when to use each size variant ('thumbnail' for preview grids, 'large' for full-resolution display). It does not explicitly name alternatives or state when not to use, but the 'single' wording implies a contrast with list operations.

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 reveals the return format ({ data: { id, ... } }) and the meaning of the include parameter, plus the caveat 'if it wraps a showing'. However, it omits error behavior, auth requirements, and potential null results, making it only partially 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 two sentences long, with the first sentence providing the core purpose and return shape, and the second listing include options. No unnecessary words, and it is front-loaded with the main action.

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 get-by-ID tool with no output schema and no annotations, the description covers the essential aspects: purpose, return shape, and include details. It doesn't explain error responses or what happens when the meeting is not found, but given the simplicity and available schema, it 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?

Schema description coverage is 100%, so both parameters are already documented. The description adds value by explaining the include associations and adding the nuance 'ViewingPropertyViewings (if it wraps a showing)' which goes beyond the schema's flat list of options. This extra context justifies a 4 over the 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?

The description clearly states 'Get a single meeting by UUID' with the specific resource (meeting) and action (get). It also notes the meeting detail in the Activity/Showing Lifecycle and provides the return shape, which distinguishes it from sibling tools like list_meetings or search_meetings.

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 when you have a meeting UUID and need a single meeting's details. It doesn't explicitly mention when not to use it or point to alternatives, but the clear scope and sibling list provide sufficient context. Missing explicit exclusions keeps it from a 5.

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

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

With no annotations provided, the description must carry the transparency burden. It does so by disclosing the return format ('Returns { data: { id, ... } }') and the available include options (OpportunityOpportunities, PropertyProperties, etc.). It does not cover error handling or auth, but for a simple get operation 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 total. It front-loads the core purpose, then adds include semantics and a use case. No wasted words, and 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 get-by-UUID tool with 2 parameters and no output schema, the description is complete: it states the purpose, return shape, include options, and the transactional context (deal chain). No critical information 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 schema has 100% coverage, so baseline is 3. The description adds meaningful semantics to the 'include' parameter by explaining what each option represents (e.g., 'OpportunityOpportunities (the lead/buyer intent), PropertyProperties (the listing)'), going beyond the schema's list of options.

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 starts with 'Get a single offer by UUID' which is a specific verb+resource combination. It also clarifies it as the 'offer detail view in the Transaction Lifecycle', distinguishing it from list/search siblings like qobrix_list_offers and qobrix_search_offers.

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 context: 'Use to trace the deal chain: Offer → Opportunity → Contact + Property → Contract.' This explains a primary use case without explicitly stating when not to use or naming alternatives, but it strongly implies a detail-view role compared to broader list/search 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 fully handles transparency. It discloses the return structure, RESO status mapping, verified include options, and FK relationships. This goes well beyond a simple 'get by ID' and gives the agent deep insight into tool 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 long but well-structured: core purpose, return shape, mapping, include options, and workflow. Every sentence contributes value, and the front-loaded first sentence states the main action. A slight deduction for density, but it remains focused.

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-getter with no output schema, the description is remarkably complete. It covers the return value shape, status semantics, include behavior, and integration with the broader workflow. This fully compensates for the missing output schema and meets the needs of an agent selecting and invoking the tool.

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

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

Although schema coverage is 100%, the description adds significant meaning to the 'include' parameter by listing verified options and recommending a canonical include pattern. It also explains the meaning of 'id' as UUID and provides contextual mapping for status values, enriching 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 identifies the tool as a single-record getter ('Get a single lead/opportunity by UUID') and distinguishes it from list/search siblings by focusing on individual deal drill-down. It also names the resource type explicitly, making its purpose unambiguous.

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

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

Provides explicit context on when to use this tool: to drill into a pipeline deal as part of a canonical workflow. It names alternative/complementary tools (qobrix_list_viewings, qobrix_search_offers) and gives a step-by-step pattern, which is exemplary usage 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 are provided, so the description carries the full burden. It discloses the return shape ('Returns { data: { id, ... } }') and lists verified include options, which is useful behavioral context. However, it does not explicitly state read-only safety, error behavior, or permission requirements, though these are minimally expected 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 three concise sentences. The first sentence states the core purpose and return shape, the second lists verified includes, and the third provides cross-tool references. Every sentence earns its place with no redundant or filler 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 moderate complexity (single resource, two parameters) and no output schema, the description provides essential context: purpose, return shape, includes, and related tools. It lacks error/not-found behavior and authentication notes, but these are not critical for a getter tool and the description is otherwise thorough.

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 describes both parameters (id and include) with clear descriptions, giving high coverage. The description adds value by confirming the verified include options (Agents, Developer, etc.) and providing usage patterns like `project == '<uuid>'` and `related_model='Projects'`, which clarifies how parameters relate to other 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 opens with 'Get a single project by UUID — development detail view for off-plan/new-build listings', which uses a specific verb and resource and clearly distinguishes it from sibling tools like qobrix_list_projects (list) and qobrix_get_property (different resource). The phrase 'development detail view' adds domain-specific context, making the purpose unambiguous.

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

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

The description explicitly states when to use this tool ('Get a single project by UUID') and directs users to alternatives for related data: 'To see project units: qobrix_search_properties with project == '<uuid>'' and 'To see project media: qobrix_list_media with related_model=''Projects'' and related_id=<uuid>'. This provides clear usage guidance and differentiates from 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?

With no annotations provided, the description carries the full burden. It conveys that the tool is a read operation ('Get') and mentions optional filtering, but it does not disclose whether the response contains multiple projects, pagination behavior, or any other side effects. It is not misleading, but it lacks depth.

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, focused sentences. The main action is front-loaded, and each clause adds value: specifying the coordinates and their use case, followed by the optional filter capability. No waste.

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

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

Given the simple tool with one optional parameter and no output schema, the description adequately states the purpose and filter option. However, it does not explain the return format or behavior when no filter is provided (e.g., returns all projects). The schema covers search syntax, but the description leaves 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 schema description coverage is 100% for the only parameter 'search', providing comprehensive details on the DSL. The tool description adds minimal value by noting the filter is optional, which is already implied by zero required parameters. Baseline of 3 applies.

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

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

The description clearly states it gets lat/lng coordinates for projects, with a specific verb and resource. It distinguishes itself from siblings like qobrix_get_property_coordinates by explicitly targeting projects, and from qobrix_get_project by focusing on coordinates.

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 a use case ('useful for map display') and mentions optional filtering, but it does not explicitly state when to use this tool versus alternatives such as qobrix_get_property_coordinates or qobrix_search_projects. No exclusions or alternative tool names are given.

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

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

With no annotations, the description carries the full burden. It adds meaningful context: the demand-side scope, explicit linking, and that the parameter is the Opportunity UUID (not property UUID). While it doesn't describe return format or rate limits, it provides substantive behavioral context for a read operation, going beyond a bare statement.

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 sentences, front-loaded with the core purpose, followed by scope clarification, usage context, and alternatives. Every sentence earns its place with no redundancy or filler.

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

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

Given the tool's moderate complexity, no output schema, and no annotations, the description is thorough: it covers purpose, id semantics, usage timing, and alternatives. It doesn't detail return structure, but for a list-like read tool, the description provides sufficient context for an agent to select and invoke it correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds crucial meaning beyond the schema by clarifying that 'id' is the Opportunity UUID (not a property UUID) and framing its use in the buyer journey. This extra semantic value 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 it 'get properties explicitly linked to a lead' with a specific resource and scope. It further differentiates by labeling it the 'demand-side view' and clarifies that the id is an Opportunity UUID, not a property UUID, which distinguishes it from similarly named siblings.

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 when-to-use guidance ('after Qualification, use this to review Solution/Viewing candidates') and names concrete alternatives: qobrix_get_opportunity with include=['Properties'] and qobrix_get_leads_by_property for the reverse match. This meets the highest bar for usage guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by explaining the return shape, mapping RESO StandardStatus values, describing include[] expansion behavior, and listing FK field targets. The verb 'Get' implies a read-only operation, and the description adds substantive behavioral context beyond simply fetching an item.

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 long but dense and well-structured, starting with the primary purpose, then return format, status mapping, include options, workflow tips, and FK fields. Every section carries useful information, but it could be slightly trimmed without losing value. The use of sections and examples makes it navigable despite its length.

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 (multiple include[] options, FK fields, and no output schema), the description is remarkably complete. It covers return shape, status enum meanings, expansion capabilities, and practical workflow mappings. There is no output schema, so the description correctly takes on the responsibility of explaining the data structure and usage patterns.

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?

Although the schema already provides 100% coverage with descriptions for all three parameters, the description adds significant meaning beyond the schema. It enumerates verified include[] options, provides workflow tips for specific includes, and explains the relationship between expand and include (e.g., 'Prefer include[] for surgical expansion'). It also maps FK fields to their target resources, which is not present in the schema.

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

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

The description opens with 'Get a single property by UUID', a specific verb+resource combination that clearly states the tool's core function. It distinguishes itself from sibling tools like list/search by positioning it as 'the listing detail view in the Listing Lifecycle', making the use case unambiguous.

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

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

The description provides clear context for when to use this tool (when you have a UUID and need a single property detail view) and includes workflow tips for specific include[] expansions that guide usage for showing history, interested leads, etc. However, it does not explicitly name alternative tools (e.g., qobrix_list_properties) or state when not to use this tool, so it falls slightly short of the highest bar.

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. It explicitly discloses the return format (array of { id, coordinates } objects) and the optional filtering behavior. While it doesn't discuss edge cases like missing coordinates or errors, the core behavioral traits are transparent for a read-only getter.

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

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

The description is three short, purposeful sentences: states the main action, the optional filtering capability, and the return shape. No redundancy or filler—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?

The tool is simple with one optional parameter and no output schema. The description covers purpose, filtering, and return type. It does not mention what happens when no properties match or if coordinates are missing, but these are minor edge cases for such a focused tool. Overall, it is complete enough for effective use.

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 only parameter, 'search', has 100% schema description coverage with detailed DSL grammar and examples. The tool description adds minimal semantic value beyond stating that filtering is optional and returns a subset. With high schema coverage, the baseline score of 3 is appropriate.

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

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

The description clearly states the tool retrieves lat/lng coordinates for properties, which is a specific verb-resource combination. It distinguishes itself from sibling tools like qobrix_get_property (full property details) and qobrix_get_project_coordinates (coordinates for projects) by explicitly scoping to 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 clear context for when to use this tool: for map display, and optionally with a search expression for a subset. It does not explicitly name alternatives or state when not to use it, but the intended use case is evident. A clear context without exclusions aligns with a score of 4.

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. It discloses that the tool returns every field with name, type, label, and validation rules, and notes that resources are case-sensitive. It implicitly indicates a read-only schema operation without side effects, which is sufficient for this tool type, though it doesn't explicitly say 'read-only' or discuss auth/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 well-structured and front-loaded, opening with the main purpose and a strong 'CALL THIS FIRST' directive. It includes a useful resource list and related-tool pointers. A minor redundancy exists between 'CALL THIS FIRST' and 'Canonical use,' but overall every sentence adds value, and length is appropriate for the role.

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 explains the return format: 'Returns every field with name, type, label, and validation rules.' It also covers the full context of when and why to use the tool, lists all valid resource values, and references complementary tools. This is complete for a schema-discovery operation with only 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 input schema already provides 100% coverage, including valid values and usage context for the 'resource' parameter. The description repeats much of this but adds marginal context such as 'source of truth' and 'canonical use.' Per the rubric, when schema coverage is high, a baseline of 3 is appropriate, and the description doesn't add significant parameter-level 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?

The description clearly states the tool's purpose: 'Get the full field schema for any CRM resource' and lists the exact resource types. It also distinguishes itself from siblings by explicitly mentioning qobrix_get_field_options (enum values) and qobrix_search_dsl_help (search grammar), making its role unique.

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?

Guidance is explicit: 'CALL THIS FIRST when unsure about field names for search, fields[], or sort.' It defines the canonical use case and names when to prefer alternative tools ('Pair with qobrix_get_field_options...', 'For search grammar, prefer qobrix_search_dsl_help'). This is perfect when/when-not guidance.

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

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

With no annotations, the description carries the full burden. It discloses the return shape ('{ data: { id, ... } }') and explains the meaning of several include options, which is valuable behavioral context. The verb 'Get' implies a read operation, though it doesn't discuss error handling or auth requirements. This is strong for a simple get 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?

Two sentences, front-loaded with the core purpose, and efficiently lists include options with parenthetical clarifications. No redundant or vague 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's simplicity (2 params, no output schema), the description covers the essential details: purpose, return envelope, and include associations. It could mention potential absence behavior or typical use cases, but it is reasonably complete for a get-by-id tool.

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

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

The schema already provides 100% coverage for both parameters, so baseline is 3. The description adds beyond that by parenthetically explaining the semantics of include options (e.g., 'AssignedToUsers (who)'), which enriches understanding. It doesn't explain every option (e.g., CreatedByUsers) but adds meaningful value.

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 a single task by UUID', a specific verb+resource combination. It also provides context ('task detail for pipeline management and follow-up audit') and implicitly distinguishes from sibling list/search tools which return multiple tasks.

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 when a specific task UUID is known, and mentions pipeline management and follow-up audit as use cases. However, it does not explicitly name alternatives (e.g., qobrix_list_tasks) or state when-not-to-use, so it falls short of a 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the return shape ('Returns { data: { id, ... } }'), indicates a verified include option, and hints that the response contains property and contact FKs for tracing back to listing and lead. This is valuable, though it stops short of covering error handling or permissions.

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 compact and front-loaded with the main purpose. Each sentence adds distinct information: purpose (Get a single viewing), return format, verified include, and a follow-up workflow hint. There is no redundancy or filler, making it 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?

For a simple get-by-ID tool, the description is complete: it states what it does, the response envelope, the valid include option, and a concrete next step. The lack of an output schema is mitigated by the explicit mention of the return shape, and the parameter schema covers the input 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?

The schema already provides 100% coverage for both parameters (id as 'Property Viewing UUID' and include as 'Verified options: PropertyViewingViewing'). The description mostly repeats the include option and adds no deeper meaning beyond the schema, so it contributes minimal additional insight.

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 a single viewing by UUID' with a specific verb and resource, and the phrase 'the showing detail view in the Showing Lifecycle' adds context. It is distinct from the sibling tools like list_viewings and search_viewings because it targets a single view by identifier.

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 when you have a specific viewing UUID, and the reference to the Showing Lifecycle provides context. However, it does not explicitly mention alternatives or exclusion criteria (e.g., when to use list_viewings or search_viewings instead), so it falls short of an explicit 5.

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

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

With no annotations, the description carries the burden. It discloses the return shape ({ data, pagination }) and verified include associations, which is useful. However, it does not state if any default filters apply, nor any permissions or side effects. This is moderate transparency for a read-only list 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?

The description is front-loaded with 'List agents' and each sentence serves a purpose. It includes useful context about agents' roles, though the workflow sentence is somewhat tangential. It is not overly verbose.

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

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

The description provides the resource definition, return shape, include options, and a workflow tip. It lacks explicit usage guidance relative to qobrix_search_agents and does not describe default behavior, but given the detailed schema and no output schema, it is fairly complete for a 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%, so baseline is 3. The description adds value by listing the verified include options (PrimaryContactContacts, User, Brands, AgencyAgents) and mentioning agent FK references, which enriches the include and search parameter semantics.

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

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

The description clearly states it lists agents (RESO Member resource) with a specific verb and resource. It defines what agents are, but does not explicitly differentiate from the sibling qobrix_search_agents, which also deals with agents.

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 guidance on when to use this tool versus alternatives like qobrix_search_agents. The description provides domain context and a follow-up workflow, but no direct when-to-use or when-not-to-use recommendations.

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 disclosure. It describes the return shape ({ data, pagination }), the expandable associations, and the domain context. While it doesn't explicitly state read-only or discuss rate limits/auth, the list verb and return-pagination detail make the behavior reasonably transparent 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 information-dense and well-structured: it states purpose, return shape, includable associations, and workflow in a compact block. The phrase 'zero tolerance on missed follow-ups' is slightly rhetorical but reinforces the operational context. No significant redundancy with the schema.

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

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

With no output schema, the description appropriately includes the pagination return shape. It also explains the tool's role in the activity timeline and how to audit contacts. Given that all parameters are already documented thoroughly in the input schema, this description sufficiently completes the picture for an agent to invoke the tool 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 already documents all five parameters with detailed descriptions (100% coverage), so the description doesn't need to add parameter-level semantics. The tool description adds use-case context and mentions included associations, but those are also listed in the schema's include parameter. This meets the baseline but doesn't exceed it.

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 opens with 'List call records'—a specific verb and resource—and immediately frames it within the 'Activity Tracking / Follow-up workflow'. It clearly distinguishes itself from sibling tools like qobrix_list_meetings and qobrix_list_email_messages by focusing on calls, and from qobrix_get_call by being the list operation.

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 workflow guidance is provided: 'use with qobrix_list_meetings and qobrix_list_email_messages for a complete activity timeline' and 'To audit a contact's engagement: search calls, meetings, and emails by their contact UUID.' This tells the agent when to use this tool and names alternatives/associated 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?

Given no annotations, the description discloses the response shape ({ data, pagination }) and key fields, plus cross-references to other entities. It does not mention side effects, auth, or rate limits, but as a list operation these are less critical. The description adds context beyond the schema without contradicting anything.

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 longer than typical but each section adds value: purpose, lifecycle, response format, key fields, cross-references, and workflow suggestion. It is front-loaded with the core purpose and structured logically, though could be slightly trimmed.

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?

Considering there is no output schema, the description compensates by explaining the response format, the pagination object, key fields, and cross-references. It covers the tool's role in the broader CRM model. It doesn't mention all 42 fields or exactly which fields are returned by default, but the schema and description together provide sufficient context for a 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 description coverage is 100%, and the parameter descriptions are exceptionally detailed (especially search). The description itself does not add additional parameter semantics beyond what the schema already provides, so 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 contacts (RESO Contacts resource) from Qobrix CRM' with a specific verb and resource. It also provides meaningful context about the Contact-to-Lead lifecycle. However, it does not explicitly distinguish itself from sibling tools like qobrix_search_contacts, which is a minor gap.

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 about when this tool fits in the workflow ('Core to the Lead-Contact Lifecycle') and suggests searching other resources for a full journey. However, it does not explicitly state when to choose this over qobrix_search_contacts or list variants, so guidance is implied rather than explicit.

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

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

No annotations are present, but the description provides valuable behavioral context: it discloses the return shape ({ data, pagination }), lists verified includes, and explains the downstream effect on property status ('reserved' then 'sold'). It does not explicitly state read-only behavior, but the listing nature implies 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 moderately long but front-loaded with the core action. Every section (stage, return shape, includes, canonical chain, status change) contributes value, though it could be slightly more concise. 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?

With no output schema, the description compensates by providing the return shape and pagination keys. It also adds rich domain context (pipeline stage, relationships, property status flow) that helps the agent understand the tool's role among many sibling tools. Minor gap: no explicit alternative tool guidance.

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 all 5 parameters. The tool description adds no new parameter-specific semantics; it merely repeats the verified include options that are already in the schema's include description. 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 the tool 'List contracts' and specifies the business stage (RESO TransactionManagement close, Deal Signing/Payment/Close). It defines what a contract is and its relationships, distinguishing it from other list/get/search tools by contextualizing it within the sales pipeline.

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 when dealing with contracts in the sales pipeline and mentions the canonical chain (Offer → Contract → Payment → Close), but it does not explicitly state when to use this list tool versus qobrix_search_contracts or qobrix_get_contract. No alternatives or exclusions are provided.

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 transparency burden. It discloses the return format ('Returns { data: [...], pagination: ... }') and the expandable associations (Include: ...), which is genuinely useful. However, it doesn't mention read-only status, default ordering, pagination behavior beyond the structure, or any potential error conditions. For a list operation, this is 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?

Three sentences, each earning its place: the first states the action and workflow context, the second specifies the return shape, and the third explains the include options and companions. No filler, no repetition of schema information, and the most important information 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 the rich schema (all params documented) and the absence of an output schema, the description provides enough context for an agent to decide when to invoke it and what to expect in return. It explains the use case (activity tracking, campaigns, contact timeline) and the meaningful relationships in the include field. It could mention parent/child scoping (e.g., whether it's for a single contact or all contacts), but the description is sufficiently complete for a list tool in this sibling ecosystem.

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

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

Schema coverage is 100%, so the schema already documents all five parameters in detail. The description adds some semantic context by explaining what several include associations mean (e.g., ContactContacts = recipient/sender, Properties = listing references), but this is marginal value beyond the schema's already-thorough parameter descriptions. The baseline 3 applies because the schema does the heavy lifting.

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 opens with 'List email messages' — a specific verb and resource — and immediately distinguishes this tool from siblings like qobrix_list_calls and qobrix_list_meetings by framing it within the Activity Tracking / Follow-up workflow. It clearly positions email messages as touchpoints in the Lead-Contact Lifecycle, making the tool's purpose unambiguous and differentiating it from other list 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 clear situational context: 'part of the Activity Tracking / Follow-up workflow and marketing campaigns' and explicitly recommends pairing it with qobrix_list_calls and qobrix_list_meetings for a complete engagement timeline. It doesn't explicitly state when not to use it or mention alternatives like qobrix_get_email_message, but the companion guidance is a strong usage signal.

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 non-standard response shape without pagination metadata, the required parameter pairing, and the exact list of returned fields. This is rich behavioral context beyond the 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?

The description is dense but every sentence earns its place: from the resource definition to lifecycle context, pagination warning, parameter pairing, examples, alternative tool, and return fields. It is front-loaded with the primary purpose and well-organized.

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

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

With no output schema, the description fully documents return values and response shape, covers usage contexts for multiple entity types, and provides a cross-reference to a sibling tool. It is a complete, self-contained reference for the media listing 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 meaning by explaining the relationship between related_model and related_id, offering concrete example values for each entity type, and introducing the 'global media' mode when both are omitted. This goes far beyond the schema's field-level descriptions.

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

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

The description clearly states the verb+resource: 'List media items (RESO Media resource)' and enumerates content types (photos, documents, floor plans). It distinguishes itself from siblings like qobrix_get_media and qobrix_list_properties by explaining its role in the Media Lifecycle and cross-referencing alternatives.

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

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

It provides concrete usage scenarios (properties, contacts, projects) and explicitly names qobrix_list_properties as an alternative for embedding media. It also explains the critical constraint of pairing related_model and related_id, or omitting both.

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 of behavioral disclosure. It reveals the return structure ({ data, pagination }), the available include associations, and a specific workflow. However, it does not explicitly state read-only semantics, permissions, or rate limits. For a list operation, the 'List' verb and return details provide reasonable transparency, 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 four sentences long, front-loaded with the core purpose. Each sentence provides distinct information: purpose, return shape, include options, and workflow. It is slightly dense but well-organized, with no filler or redundancy. The structure flows logically from general to specific, making it easy for an agent to parse key details quickly.

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

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

Given the absence of an output schema, the description appropriately explains the paginated return shape. It also addresses the key ambiguity around meetings vs viewings, which is essential for correct tool selection. The description does not mention potential error conditions, sorting nuances, or edge cases, but for a list tool with a rich parameter schema, this level of context is largely 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?

The input schema covers all 5 parameters with 100% description coverage, establishing a baseline of 3. The tool description adds value by explaining the include parameter's role in distinguishing meetings from viewings and suggesting a concrete workflow. While the schema already lists the include options, the description provides the meaningful 'why' behind using them, and the emphasis on the first meeting/showing as a lead trigger adds context 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 'List meetings' with a specific verb and resource, and further distinguishes it from sibling tools like qobrix_list_viewings by explaining that meetings can wrap property viewings via RESO Showing ↔ Meeting. It also provides domain context (bridges Activity Tracking and Showing Lifecycle workflows), making its purpose unambiguous.

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

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

The description gives clear usage context: it explains the relationship between meetings and viewings and recommends the include=['ViewingPropertyViewings'] workflow to differentiate property showings from general meetings. It also mentions the canonical trigger role, but does not explicitly contrast with alternative tools (e.g., 'use this instead of list_viewings when...'), so some inference is left to the user.

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 must carry the behavioral disclosure burden. It provides the return shape ({ data, pagination }) and include options, which is useful, but it does not explicitly state that the operation is read-only, mention authentication or scoping, or disclose side effects, leaving some transparency gaps.

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

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

The description is compact and front-loaded, with each sentence adding business context, return shape, or pipeline positioning. It does repeat the include options already present in the schema, but the extra domain explanation justifies the length.

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 domain complexity and lack of output schema, the description covers the essential context: what an offer is, the transaction chain, return format, and the next step. It does not exhaustively cover behavior like pagination defaults or list-vs-search boundaries, but the schema fills many of those gaps, making it largely complete.

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

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

All five parameters are fully described in the input schema (100% coverage), so little extra parameter interpretation is necessary. The description's mention of include associations adds a small semantic layer, but the schema already documents each field thoroughly, matching the baseline.

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

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

The description starts with 'List offers (RESO TransactionManagement)' and explains the domain object as linking an Opportunity to a Property with a price. This clearly identifies the resource, the action, and the pipeline stage, distinguishing it from sibling tools like qobrix_get_offer or qobrix_search_offers.

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

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

It places the tool in the canonical chain 'Lead → Viewing → Offer → Contract → Close' and explicitly mentions qobrix_list_contracts as the next step after acceptance. However, it does not contrast with qobrix_search_offers or state conditions for list-vs-search, limiting the exclusion guidance.

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

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

With no annotations, the description fully carries behavioral disclosure. It reveals the return shape ({ data, pagination }), flags the problematic 'Locations' include, lists verified safe includes, maps status enums to standard funnel stages, and explains the boost behavior in the page parameter. This goes far beyond what annotations would provide.

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 dense but well-organized with clear segments (domain, funnel mapping, return format, includes warning, key fields, workflows). It front-loads the core purpose and uses labels like 'IMPORTANT' and 'Safe verified includes' to aid skimming. Slightly long but every section 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 no output schema and no annotations, the description is remarkably complete: it documents return structure, field semantics, common workflow patterns, search syntax references, and include restrictions. It equips an agent to invoke the tool correctly across multiple use cases without needing external documentation.

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 every parameter has a detailed description with examples (sort, search, fields, include). The top-level description adds contextual workflow examples but does not materially extend the schema's parameter-level semantics. 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 the tool's function: 'List opportunities/leads from Qobrix CRM' and adds crucial domain context ('leads ARE opportunities'). It distinguishes the entity from contacts, properties, etc., and the title itself aligns with the list sibling group. The RESO funnel mapping further clarifies the semantic scope.

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

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

Provides explicit workflow patterns (pipeline overview, overdue follow-ups, new leads this week) and names alternative tools: use qobrix_search_properties for demand→supply matching, qobrix_get_leads_by_property for supply→demand, and qobrix_search_dsl_help for search syntax. It also warns about unsafe include values, giving clear usage guidance beyond a generic 'when to use'.

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

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

With no annotations, the description carries the burden of disclosing behavior. It does disclose the return shape: 'Returns { data: [...], pagination: { count, current_page, has_next_page, ... } }' and a relational detail: 'Properties reference their project via the "project" FK.' However, it does not mention rate limits, permissions, or error behavior, though for a read-only list operation these may be less critical.

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 and front-loaded with purpose. Each sentence adds context, though the 'Verified include' line is somewhat redundant with the schema's include description. Overall appropriate length for the tool's complexity.

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?

Considering the tool has 6 parameters, no output schema, and no annotations, the description is reasonably complete. It provides the return shape, pagination, a key foreign-key relationship, and a workflow hint. Missing explicit read-only confirmation and edge-case behavior, but sufficient for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds little beyond the schema; the 'Verified include' list repeats the include parameter's documented options. No new parameter semantics are introduced in the description.

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

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

The description clearly states the verb and resource: 'List projects (property developments/complexes) — RESO Project equivalent for off-plan and new-build listings.' It distinguishes from singular get_project by being plural, but does not explicitly contrast with sibling qobrix_search_projects, which is a similar listing/search tool.

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?

Some usage context is provided: 'relevant in the Listing Lifecycle for new-builds' and a workflow hint 'to see units in a project, qobrix_search_properties with project == "<uuid>"'. However, there is no explicit guidance on when to use list_projects vs search_projects, nor any exclusions or prerequisites.

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 fully carries the burden. It discloses payload defaults (expand=false, media=false, default limit 10, max 100), explains that FKs come back as UUIDs and media is not inlined, and maps RESO statuses to internal values. This adds rich behavioral context beyond the schema and covers what an agent needs to know about the response 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 long but every section earns its place: purpose, return shape, status mapping, key fields, workflow recipes, payload defaults, and parameter hints are all organized and front-loaded. No fluff; only high-value information is present.

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 8 parameters, no output schema, and no annotations, the description is exceptionally complete. It covers return structure, field selection, status mapping, workflow recipes, and points to additional resources (qobrix_search_dsl_help, qobrix_get_schema) for deeper needs. It is a model of contextual 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 already covers 100% of parameters, but the description adds significant practical value: it provides search expression examples, sort syntax examples, include[] options, and guidance on when to set media/expand. It also explains the interaction between page and boost (though boost is not a parameter in this schema, the context is still useful). This goes far beyond the baseline 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 'List properties (RESO Property resource) from Qobrix CRM' and specifies its role as the 'Core tool for the Listing Lifecycle'. It distinguishes from siblings by explicitly suggesting qobrix_search_properties for buyer-property match and qobrix_list_media for media, so the verb+resource+scope is specific and well-differentiated.

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 when-to-use context: 'use to browse active inventory, track status changes, or audit listings'. Offers concrete workflow recipes (e.g., active inventory via search, recent listings via sort) and explicitly names alternatives (qobrix_search_properties for free-language demand, qobrix_list_media for media-only needs), giving clear exclusions 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?

With no annotations provided, the description carries the full burden. It discloses the return envelope ({ data, pagination }), the expandable associations, and the canonical search patterns. It does not explicitly state read-only operation, but as a list tool, that is clear from context; it also doesn't mention auth or rate limits, but these are likely shared across the API.

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 lengthy but well-structured: purpose first, then return shape, includes, and canonical patterns. It front-loads the main verb. Some promotional phrasing ('operational backbone of all canonical workflows') could be trimmed, but the content is relevant and organized.

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

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

There is no output schema, so the description compensates by spelling out the response shape and the list of includable associations. The canonical patterns cover the most likely agent scenarios. It is complete enough for a list tool with a rich 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?

The input schema already describes all five parameters with 100% coverage, including detailed grammar and defaults. The description adds canonical usage examples for the search parameter but does not explain any parameter semantics beyond what the schema provides. Per the guidelines, this is a 3 when schema coverage is high.

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 opens with 'List tasks' and immediately frames it as the operational backbone of canonical workflows, making the verb and resource clear. However, it never distinguishes this tool from sibling qobrix_search_tasks, even though the search parameter overlaps with a search tool's job. The canonical patterns do clarify core use cases.

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 four canonical patterns (My open tasks, Overdue, Tasks for a lead, Listing checklist) with concrete search expressions, showing exactly when to reach for this tool. It does not explicitly state when not to use it or name alternatives, so it stops short of a 5.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It discloses the return shape with pagination details, confirms only 'PropertyViewingViewing' include is verified, and describes the data linkage (property, contact, agent). However, it does not mention auth requirements or rate limits, which is a minor gap for a read-only listing 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?

The description is information-dense and well-structured, starting with purpose, then lifecycle context, return format, include verification, and workflow patterns. It is longer than minimal but every sentence earns its place. There is slight redundancy with the schema's include description, but it does not detract significantly.

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

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

For a complex tool with 5 parameters and no output schema, the description provides return format, pagination, workflow patterns, and cross-tool references. It is complete enough for an agent to select and use correctly, though it could explicitly contrast with qobrix_search_viewings and qobrix_get_viewing for even better sibling differentiation.

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?

Input schema coverage is 100% and all 5 parameters have detailed descriptions. The description adds no parameter-specific meaning beyond what the schema already provides; its search example (created >= THIS_WEEK) is already covered by the schema's THIS_WEEK shortcut. Thus, the 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 'List property viewings (RESO ShowingAppointment)' and positions it as the 'Showing/Viewing Lifecycle tool', giving a specific verb+resource and a clear role. This distinguishes it from siblings like qobrix_search_viewings and qobrix_get_viewing, as it emphasizes the listing and lifecycle aspect.

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 workflow patterns: 'This week's viewings: search with created >= THIS_WEEK', 'Property's showing history: qobrix_get_property...', 'Meetings linked to viewings: qobrix_list_meetings...'. These give concrete when-to-use guidance and name alternative tools, fulfilling the criteria for explicit usage guidelines.

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 discloses what the tool aggregates (counts per resource, sums from closed contracts), how it buckets data (by assigned_to across every resource), and that it returns a wide row or leaderboard. It does not mention potential performance implications or exact return field list, but it gives a solid behavioral overview beyond what the name alone conveys.

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 compact yet information-dense. It front-loads the purpose, then summarizes the return type and aggregation logic, and ends with three illustrative examples that clarify parameter usage. Every sentence adds value, and the structure makes the tool's behavior easy to grasp quickly.

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

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

Given the tool's complexity and the absence of an output schema, the description does a good job of explaining what is returned (wide row or leaderboard, counts and sums). It stops short of explaining field names in the output or edge cases like combining multiple time windows (year vs from/to), but it is sufficiently complete for most agent decision-making.

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 provides 100% parameter coverage, so the baseline is 3. The description adds valuable context: default leaderboard size, interaction between 'user' and 'top'/'sort_by', support for 'CURRENT_USER', and the meaning of 'since_days' as a rolling window. This goes beyond the schema and helps the agent construct correct call 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 this is a 'per-rep productivity roll-up' that returns either a single-user wide row or a top-N leaderboard. It specifies exactly which resources are counted (calls, meetings, emails, tasks, viewings, opportunities, deals closed) and which metrics are summed (volume, commission). This clearly distinguishes it from sibling list/search/get tools, which operate on individual resources.

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

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

The description explains the two modes (single-user via 'user' vs leaderboard by default) and provides concrete example parameter combinations for common use cases. It does not explicitly say when NOT to use this tool or name alternative tools, but the examples and mode explanations effectively imply the appropriate usage 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?

With no annotations, the description fully discloses behavior: two-tier filtering, ranked pagination mode, soft boosts never filtering, max_scan capped under expand/media, response caching, and the presence of _relevance/_matched fields in ranked results.

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

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

Three dense sentences plus a reference call and example. Every phrase adds value with no repetition or filler. Front-loaded with the core purpose and key mechanics.

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 is highly complete for a search tool, covering ranking behavior, pagination modes, limits, and the relationship between parameters. It could explicitly state when to choose this over qobrix_list_agents, but the 'relevance-ranked' positioning largely conveys it. Lacks output schema but mentions key returned 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 coverage is 100%, but the description adds the high-level two-tier concept linking search (hard filters) and boost (soft preferences), plus a concrete example. This goes beyond the schema's per-parameter descriptions.

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

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

The description clearly states the tool performs a relevance-ranked agent search, explicitly mentioning 'agent search' and 'TWO-TIER' model. It distinguishes from list_agents by emphasizing ranking and F1 optimization.

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 guidance on how to use search vs boost, controls like limit/max_scan, and references helper tools for DSL, fields, and enums. It does not explicitly contrast with list_agents or other search tools, but the usage context is clear.

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