Open To Close MCP by usefulapi

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the bar is lower, yet the description adds real content: duplicate creation on every call (with a retry recipe) and the null-default behavior for omitted visibility fields. Auth requirements and rate limits are still unmentioned, so not a 5.

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 short front-loaded sentences: action, safety gate, retry semantics, defaulting note, then the endpoint. Nothing is padded or repeated.

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 an 8-param mutation with no output schema, the description covers the write intent, confirmation gate, duplicate risk, and default handling well. The remaining gap is the meaning of the priority-related parameters, which an agent must infer from the enum alone.

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

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

Schema description coverage is 0% across 8 parameters, so the description has to carry the load. It only hints at 'visibility' fields and their omission default; priority, priority_date, and property_id semantics are left entirely to the raw schema types and enum.

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 'WRITE:' prefix plus 'add a note to a property' gives a specific verb and resource, and it clearly separates itself from the read-side siblings (opentoclose_get_property_note, opentoclose_list_property_notes) without opening any schema.

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

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

'Confirm the property and note content/visibility with the user first' sets a concrete prerequisite, and 'inspect current notes before retrying' effectively routes the agent to the list sibling before re-invoking. It lacks an explicit when-not-to-use statement, so 4 rather than 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?

Annotations already declare readOnly=false, idempotent=false, destructive=false, and openWorld=true. The description adds useful context beyond those fields: it is marked WRITE, creates an unassociated contact record, returns a created record ID, and uses POST /v1/contacts.

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 purpose is front-loaded with 'WRITE: create a contact,' and the remaining sentences are short, scannable, and free of repetition. Every sentence contributes workflow, scope, return, or endpoint information.

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

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

The description covers the return value and property non-association, but for a 14-parameter creation tool with no required parameters and no output schema, it should clarify minimum required details or validation. That omission is material for correct invocation.

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

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

There are 14 parameters with 0% schema description coverage and zero required fields, yet the description provides no field-level guidance at all. It does not say which fields are necessary, what formats are expected, or how contact_role_id relates to list_contact_roles.

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

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

The description states a specific verb and resource ('create a contact') and distinguishes its scope from property-related siblings by noting it creates a contact 'without associating it with a property.' It also states the return value, giving an agent enough to identify the tool without opening the schema.

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

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

It gives an explicit precondition and workflow: search existing contacts first to avoid duplicates, then confirm details before creating. It does not name the search sibling or state when not to use this tool, but the guidance 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?

Annotations declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, covering the safety profile. The description adds only the endpoint path and 'read one note', offering no extra behavioral context such as error handling, permissions, or rate limits. It does not contradict the annotations.

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

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

Two short sentences, front-loaded with the action and resource, then the endpoint. No filler, appropriate for the tool's simplicity.

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

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

For a simple read tool with annotations covering safety, the description is minimal but misses explaining the parameters and doesn't clarify return value or edge cases. Given 0% schema coverage and no output schema, more detail would help an agent call it correctly.

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

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

Schema coverage is 0%, so the description must compensate. It only maps parameter names into the URL path ({property_id}, {record_id}), providing minimal semantic meaning beyond the schema's integer types; it doesn't explain what a record_id represents (a note ID) or any constraints.

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

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

States a specific verb 'Read' and resource 'one note associated with a property', and gives the exact endpoint path. This distinguishes it from list_property_notes by implying a single-record fetch, though it doesn't explicitly name the sibling.

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?

Implies usage when retrieving a single note by ID, but doesn't state when to prefer it over list_property_notes or what happens if the note doesn't exist. No explicit exclusions or alternatives 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the endpoint path, which confirms a scoped single-resource read, but says nothing about error behavior, permissions, or what a missing id returns.

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

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

Two compact sentences with the purpose front-loaded and the endpoint as supporting detail. Nothing extraneous.

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 read-only getter with annotations covering safety, the definition is near-adequate. However, with no output schema, the description gives no hint of what a task record contains, and it leaves both required ids unexplained.

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

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

Schema description coverage is 0%, so neither parameter is documented anywhere. The endpoint template implies property_id is the parent property and record_id is the task identifier, which is modest added meaning, but the integer type, positivity constraint, and any id-source guidance are left to the schema alone.

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

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

States a specific verb and resource ('Read one task associated with a property') and pins it down with the exact REST endpoint. The singular 'one task' implicitly distinguishes it from opentoclose_list_property_tasks, though no sibling is named explicitly.

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

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

Usage context is only implied: 'read one task' suggests a single-record fetch when the record id is known. There is no explicit when-to-use guidance, no mention of the list_property_tasks alternative, and no stated 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?

Annotations already cover read-only, non-destructive, open-world behavior, so the description only needs incremental value. 'One offset/limit page' is a genuinely useful disclosure about pagination shape, but it says nothing about result ordering defaults, page-full behavior, or auth requirements.

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

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

Three short front-loaded fragments with no filler; the core purpose and pagination constraint come first. The telegraphic style is efficient, though 'documented sorting' is vague enough to cost a point.

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 list tool with no output schema, the description covers the essentials of what to call and roughly what it returns. It leaves gaps on return shape and pagination termination that an agent must discover by trial.

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 only 29%, so the description should compensate more. It gestures at all seven parameters by category (name/email search, sorting, offset/limit page) but adds no detail beyond the schema — it doesn't name the sortable fields or explain that offset/limit wrap into a single page window.

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

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

States a specific verb+resource ('List agents') plus the searchable fields and endpoint. It is clearly distinguishable from siblings like list_contacts and list_teams by resource, though it never explicitly contrasts with them.

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

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

Usage is implied by the resource and filters, but there is no guidance on when to prefer this over another listing tool or when it is not appropriate. The agent must infer the use case.

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

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

The annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered. The description adds only the REST path 'GET /v1/contactRoles/' and discloses nothing about pagination, result size limits, or what a contact role record contains — no value beyond structured fields.

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

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

Two short fragments, front-loaded with the action and resource, with no padding. The endpoint path is arguably redundant for an agent but costs little space.

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 no-param, annotated, read-only list tool the essentials are covered, but with no output schema the description should say something about the returned shape (what fields a contact role has) and whether the result is paginated. That gap is the main incompleteness.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify; the baseline of 4 applies. No misleading parameter hints are given.

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

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

States a specific verb and resource ('List contact roles'), which is unambiguous on its own. It does not distinguish itself from similar siblings such as opentoclose_list_file_roles, opentoclose_list_tags, or opentoclose_list_teams, leaving the agent to infer which role-type listing it needs.

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 listing verb implies 'call this to enumerate all contact roles', but there is no statement of when this is preferable to other list tools or of any prerequisites. For a zero-parameter enumeration tool the implied usage is reasonably obvious, so it lands at minimum viable rather than poor.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the meaningful behavioral detail that results are delivered as a single offset/limit page, but says nothing about match semantics, ordering defaults, or error behavior beyond that.

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

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

Three tight sentences with the core action front-loaded; no filler. The phrase 'documented sorting' is slightly vague and the endpoint reference is marginally redundant, keeping it just short of a 5.

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 list tool with no output schema and no required parameters, the essentials (a paged list of contacts, filterable by name/email, sortable) are present. The remaining gap is search-matching semantics and what a contact record contains, which is minor for a read-only listing.

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 only 29%, so the description carries extra burden, and it does partly compensate by grouping first_name/last_name/email under 'name/email search' and sort_by/sort_dir under 'sorting'. However, it never explains matching rules (exact vs partial, case sensitivity) or how the filters combine, leaving most of the seven parameters underspecified.

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

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

States a specific verb and resource (list contacts) plus the capabilities of name/email search and sorting, and even names the underlying endpoint GET /v1/contacts. It separates the tool from create_contact clearly, though it never explicitly distinguishes it from the near-identical sibling list_property_contacts.

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?

'One offset/limit page' implies a paged-listing usage pattern, but there is no explicit when-to-use guidance or comparison against sibling list tools such as list_property_contacts or list_contact_roles. The caller must infer the context entirely.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only the GET path and does not disclose auth needs, pagination, rate limits, or response shape.

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

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

The description is two short sentences, front-loaded with the purpose and followed by a compact endpoint reference. There is no filler or redundant explanation.

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 list tool, the annotations and schema cover invocation safety and shape. However, the description does not explain what file roles represent or whether results paginate, and with no output schema some return-context could still help.

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 the baseline is 4 under the rubric. The description does not need to explain parameter semantics and does not misrepresent the empty input schema.

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

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

States a specific verb and resource, 'List file roles', and adds the endpoint 'GET /v1/fileRoles/'. This clearly identifies the operation, though it does not explicitly contrast it with sibling list tools such as list_contact_roles or list_tags.

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

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

The description gives no when-to-use guidance, prerequisites, or alternatives; it only restates the operation and endpoint. An agent must infer that this is for retrieving the file-role catalog rather than another role type.

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

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

Annotations already declare a read-only, non-destructive, open-world operation. The description usefully adds the v1.1 endpoint, the 50-item cap, and the important limitation that full field values are not returned here.

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, front-loaded sentences with no filler. The key scope limitation is stated before the endpoint, which is easy to scan.

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 read-only listing tool, the description covers purpose, scope, pagination cap, and the summary-vs-full-record distinction. No output schema exists, but the description doesn't need to explain return format here; the main missing piece is explicit routing to full-detail alternatives.

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 both limit and offset are fully documented in the schema. The description adds only the maximum-50 note, which is already in the schema, so it does not extend parameter meaning beyond structured fields.

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

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

The description names a specific verb and resource ('List properties') and adds scope detail ('with team/agent summaries') plus a versioned endpoint. It distinguishes itself from full property retrieval by stating it does not return full field values, though it doesn't name the sibling tool that would.

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 pagination via 'Maximum 50 per call' and the schema explains offset usage, but there is no explicit when-to-use guidance versus alternatives. It is adequate but leaves the agent to infer that this is a summary listing rather than a full-detail fetch.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds only the underlying GET endpoint and the scoping constraint — no pagination, ordering, or result-shape context that would help an agent reason about large result sets.

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

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

Two short sentences with the core purpose front-loaded and zero filler. The trailing endpoint path is slightly redundant with the purpose sentence but does no harm.

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 read-only list tool with full annotation coverage and no output schema, the description is largely sufficient. The main residual gap is result-set behavior (pagination, ordering, volume), which an agent calling a property-scoped list would want.

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

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

Schema description coverage is 0%, so the description carries the burden; it does name the filterable fields (name/email, matching first_name/last_name/email) which the bare schema does not explain. However, it does not clarify that property_id is a required path identifier, nor distinguish first_name from last_name or give any format/syntax guidance.

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

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

States a specific verb and resource ('List contacts associated with a property') and adds the optional filter scope plus the REST path, which makes the resource unambiguous. It implicitly differs from the sibling list_contacts by property scoping, but never names that sibling to make the distinction explicit.

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

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

'Optionally filtered by name/email' implies when the filters apply, but there is no explicit when-to-use guidance, no mention of when to prefer list_contacts instead, and no prerequisites or paging caveats.

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

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

Annotations already declare readOnlyHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds genuine value beyond that by disclosing what the call returns (folders plus document metadata/links) and explicitly that no file binary is downloaded, plus the underlying endpoint. It omits pagination/result-size behavior, keeping it short of a 5.

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

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

Three short, front-loaded sentences with no filler: purpose first, then the download exclusion, then the endpoint. Every sentence carries information an agent can act on.

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

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

With only one required parameter, no output schema, and rich annotations, the description covers enough: it says what is returned and what is not. The remaining gap is pagination or ordering behavior for a list endpoint, which is minor for this complexity level.

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

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

Schema description coverage is 0%, so the single integer property_id is undocumented in the schema itself. The description partially compensates by embedding the path template GET /v1/properties/{property_id}/documents, which implies property_id identifies the property, but it adds no format, range, or source hints.

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

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

States a specific verb and resource pair ('Read a property's document folders and document metadata/links') and scopes the result explicitly to folders/metadata rather than file contents. It clarifies a boundary no sibling tool covers, though it does not name an alternative sibling for other document-related needs.

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 exclusion 'Does not download files' effectively serves as a when-not cue, and the usage context (reading documents attached to a property) is implied by the resource name. There is no explicit guidance on when to prefer this over e.g. list_property_notes or list_properties, so routing is left to inference.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond the endpoint path — no mention of return shape, ordering, pagination, or whether groups are global vs property-scoped.

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

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

Two short sentences, purpose front-loaded, no filler. The endpoint sentence is somewhat redundant but harmless as a structural cue.

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

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

For a zero-parameter read-only list tool with annotations covering safety and no output schema, this is minimally adequate. However, nothing explains what a field group contains or how results are shaped, which would matter for an agent deciding between it and adjacent list tools.

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

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

The tool takes zero parameters, so there is nothing for the description to document; the baseline for 0 params applies. No parameter semantics gap exists.

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?

It states a verb and resource ('List property field groups'), but that is essentially a restatement of the tool name and title, adding only the REST endpoint path. It gives no clue how a 'field group' differs from sibling resources like property fields or property field sections, so an agent cannot easily disambiguate among the many 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?

There is no guidance on when to use this versus the closely-named siblings (list_property_fields, list_property_field_sections), nor any prerequisite or pagination context. The agent must infer selection purely from the name.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so safety is covered. The description adds nothing beyond the title, which is identical, and says nothing about pagination, ordering, or response shape for what is presumably a large field listing.

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

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

Two short, front-loaded sentences with no filler. The trailing 'GET /v1/propertyFields' is raw endpoint metadata that adds little for an agent but costs almost nothing.

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

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

For a zero-param read-only list with no output schema, brevity is acceptable, but the description leaves the reader unsure whether this returns fields, groups, sections, or all three, and how it differs from the two adjacent field-group/section tools.

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

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

Zero parameters, so the baseline is 4. The description correctly signals no input is required by not mentioning any, though it could not add much even if it tried.

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

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

States a verb and resource ('List property fields') and adds the grouping behavior, but 'grouped into sections' overlaps conceptually with siblings opentoclose_list_property_field_groups and opentoclose_list_property_field_sections, leaving the boundary between them ambiguous.

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

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

No guidance on when to use this instead of list_property_field_groups or list_property_field_sections, no prerequisites, no exclusions. The agent must infer the choice from names alone.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds only the endpoint path and says nothing about pagination, result ordering, authentication/workspace scoping, or what a section contains — little value beyond the structured fields.

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

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

Two short fragments, front-loaded with the action and resource, no filler. The endpoint reference is the only slightly low-value element, but it is not padding.

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

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

For a zero-parameter read-only list, minimal text is defensible, but with no output schema the description should indicate what comes back (e.g., sections with ids/names) so an agent knows whether this call answers its question. As written, an agent can invoke it but cannot predict the result.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No parameter-level claims are made or needed.

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

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

"List property field sections" names a verb and resource, but it is essentially a restatement of the tool name with no differentiation from closely related siblings such as opentoclose_list_property_field_groups and opentoclose_list_property_fields. An agent cannot tell from this text what a 'section' is relative to a 'group' or a 'field'.

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

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

There is no guidance on when to use this versus the other list_* siblings in the property-fielding family. The description only supplies the HTTP endpoint (GET /v1/propertyFieldSections), which is not usage guidance for an agent choosing between tools.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds genuinely non-obvious behavior: results are a single page, so full enumeration requires repeated offset calls — context the annotations cannot supply.

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

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

Three short, front-loaded sentences: purpose, pagination contract, endpoint. Nothing is redundant or padded.

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

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

For a simple read-only list tool with no output schema, the essentials are present — including the pagination caveat and the "no total count documented" note in the limit parameter. It stops short of describing note fields or sort order, which would help an agent interpret results.

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 67%: limit and offset are well documented in-schema, while property_id is only implicitly explained by the path template in the description. The description adds the path framing but no format or ordering semantics, so this lands at the baseline.

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

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

States a specific verb and resource ("List notes associated with a property") and pins it to an endpoint path, so the agent can separate it from opentoclose_get_property_note (single note) and opentoclose_add_property_note (write) without opening any schema.

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

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

"One offset/limit page" implies the caller must loop manually rather than expecting a full result set, which is useful usage context. However, no sibling is named and there is no explicit when-to-use/when-not-to-use statement, so guidance remains implicit.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds only the raw REST path, which is redundant with the tool name and conveys no behavior beyond structured fields — no pagination, ordering, or return-shape 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?

Two short sentences, front-loaded with the purpose. The trailing HTTP endpoint restates what the name already says and is the one sentence that doesn't fully earn 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?

A simple single-parameter read tool whose annotations cover the safety profile, so little prose is needed. However, an agent still doesn't know whether results are paginated or how tasks are ordered, which matters for a list endpoint.

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

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

The single property_id parameter has 0% schema description coverage, so the description must carry the burden. 'associated with a property' implies the param identifies the parent property, and the path template reinforces this, but nothing states that it must be a positive integer or where to obtain 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?

States a specific verb (List) and resource (tasks) scoped to a property, which is clear enough to distinguish from the singular opentoclose_get_property_task. It doesn't explicitly name that sibling or any other alternative, so differentiation relies on the agent noticing the plural/list naming.

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

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

There is no guidance on when to use this versus opentoclose_get_property_task or the other list_* property tools, and no mention of expected result volume or filtering. The agent must infer that this returns all tasks for a property with no filter options.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered structurally. The description adds only the REST path 'GET /v1/propertyTemplates/', which implies a standard GET collection with no side effects but reveals nothing about pagination, filtering, or response size.

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

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

Two short sentences with the core action front-loaded; the endpoint path is a slight restatement of the first sentence but still cheap and bounded. No filler.

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

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

For a trivial zero-param read tool with annotations covering safety, this is close to sufficient, but with no output schema the description never indicates what a 'property template' contains or what the list returns, leaving the agent to discover the shape at call time.

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

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

The tool takes zero parameters, so per the baseline there is nothing for the description to disambiguate. Schema coverage is 100% and the empty object schema is self-explanatory.

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

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

The description names a specific verb and resource ('List property templates'), which is clearly separable from siblings like list_property_fields or list_properties. It doesn't explicitly state what distinguishes a template from those other resources, but the name/description pair is unambiguous.

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

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

No guidance on when to use this versus other list endpoints, no prerequisites (e.g., auth/scopes), and no exclusions. The agent must infer usage purely from the tool name and sibling naming patterns.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds only the REST endpoint path (GET /v1/tags), with no disclosure of pagination, result ordering, or response shape; with annotations carrying most of the burden this is adequate but thin.

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

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

Two short fragments with zero waste and the key verb front-loaded. The endpoint path is marginally redundant with the annotations' title but useful for agents mapping to the REST API.

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 does not say what fields a tag record contains or whether results are paginated, which an agent calling a list endpoint would want. For a simple zero-parameter read tool this is minimally viable rather than complete.

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

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

The tool takes zero parameters, so the schema-side baseline is 4. No parameter semantics need explaining, and the description correctly implies a parameterless resource listing.

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

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

States a specific verb and resource ("List tags"), which is unambiguous and distinguishable from the many sibling list_* tools by resource noun. It gives no further detail about what a tag contains or its scope, but the core purpose is clear.

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

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

There is no guidance on when to use this tool versus siblings or what a tag is used for in this API. The agent must infer usage entirely from the tool name and resource noun.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is carried elsewhere. The description adds real value by disclosing that member data is included in the response ('their members') and the underlying endpoint. It omits pagination behavior and result-set size expectations for an open-world 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?

Two short sentences with the resource and scope front-loaded; nothing is buried. The 'GET /v1/teams/' fragment is mild redundancy but does confirm the target endpoint.

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 no-parameter read tool with annotations covering safety, little is needed, and the description does say teams come back with members. However, with no output schema, the agent gets no sense of the response shape (field names, nesting of members) or whether results are paginated, which is a meaningful gap for a list endpoint.

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

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

The tool takes zero parameters, so there is nothing to disambiguate and the baseline is 4. The description correctly implies no filtering inputs are accepted.

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

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

States a specific verb and resource ('List teams and their members'), which is unambiguous and distinct from the sibling list_* tools that target contacts, properties, tags, etc. It does not explicitly name or contrast a sibling, so it stops short of a 5.

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

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

No guidance on when to call this versus other list tools or when not to call it. There is no mention of pagination, rate limits, or whether a single team can be fetched another way.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered. The description adds only the REST endpoint path, with no information about pagination, result size, or ordering that annotations don't already imply.

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

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

Two short, front-loaded fragments with no padding. The endpoint path adds marginal value for an agent but is plausibly useful for mapping to the underlying API.

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 no-argument enumeration tool with a covered safety profile and no output schema, the definition supplies everything needed to invoke it correctly. Only the shape of the returned time zone objects is left implicit, which is acceptable for an unfiltered list.

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

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

The tool takes zero parameters and the schema is an empty object at 100% coverage, so there is nothing for the description to disambiguate. Baseline 4 applies.

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

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

States a specific verb+resource ('List time zones') that an agent can distinguish from all sibling list_* tools, since none of them touch time zones. It stops short of differentiating by scope or content, but the resource is unambiguous.

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

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

Usage is only implied: this is clearly a reference-data lookup with no filter parameters, so an agent can infer it's for resolving valid time zone values before setting one. There is no explicit when-to-use, prerequisite, or alternative named.

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