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

No annotations are present, so the description carries the behavioral disclosure burden. It does disclose that this operates on 'live data' and is a 'write', which is meaningful. However, it does not mention irreversibility, permissions, error conditions, or what happens on success, leaving the write side effects partly undisclosed.

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

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

The description is two sentences with no filler. The core action and live-data warning are front-loaded, and the prerequisite and optional linkage are stated in a compact, readable way. Every clause 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 has 8 parameters and no output schema, yet the description does not explain what the tool returns (e.g., created bill ID or confirmation). It covers prerequisites and optional linkage well, but for a write operation with no output schema, the missing return-value information leaves an agent uncertain about how to confirm success.

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

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

The input schema has 100% description coverage, so the baseline is 3. The description repeats schema information about required fields and the payee contact source, but adds no new meaning beyond the schema's own descriptions. It does not compensate for any schema gaps because there are none.

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 'Create' and the resource 'a bill in Rentvine', and adds a distinct scope marker with '(live data, write)'. It references sibling tools 'list_vendors or list_owners' for input, which helps differentiate from read-only listing tools. An agent can confidently identify this as the write operation for bills.

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 states the required inputs and where to obtain them ('from list_vendors or list_owners'), and notes the optional work-order linkage. It gives clear context for when to invoke the tool but does not explicitly exclude alternatives or state 'use list_bills instead for reading'. The prerequisite guidance is strong enough for an agent to proceed correctly.

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?

There are no annotations, so the description carries the transparency burden. The description indicates this is a live, write operation, explains Rentvine's auto-fill of unitID for single-unit properties, states that status defaults to 'open', and discloses the return values work_order_id and work_order_number. This is strong behavioral disclosure for a creation tool.

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

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

Three efficient sentences deliver purpose, required inputs, important runtime behavior, and output identifiers. There is no filler or redundant commentary.

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 10-parameter tool with no output schema, the description covers the essential operational context: write side effects, required fields, auto-fill rules, default status, and return values. Remaining details like scheduled_start or vendor_contact_id are fully documented in the schema, so the description is sufficiently complete.

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

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

Schema description coverage is 100%, and the description adds minimal parameter-level meaning beyond the schema. It highlights required fields and auto-fill behavior, but most of that is already present in the schema, so the description mostly reinforces rather than extends 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 begins with 'Create a new maintenance work order in Rentvine (live data, write),' stating a specific verb, resource, and side-effect. It naturally stands apart from sibling tools like update_work_order and list_work_orders by making the creation action 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?

The description gives clear context for invoking the tool and lists the three required fields. However, it does not explicitly point to alternatives such as update_work_order for existing work orders or list_work_orders for viewing, so the usage guidance is implied rather than directly comparative.

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 load and it does so: it states the operation is a read of live data, enumerates the four returned fields, and warns that large downloads can fill the context window. This goes beyond a bare 'download' and accurately sets expectations about payload size and side effects.

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

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

Three compact sentences front-load the core action and return shape, then end with a practical caveat and routing hint. There is no filler or repetition of schema fields beyond what is useful.

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 enumerates the return fields (mime_type, size_bytes, is_image, content_base64), states the supported file types and ~1MB limit, and warns about context-window risk. For a single-parameter read tool, this gives an agent enough behavioral and return information 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?

The schema already fully documents file_id as 'Rentvine fileID', so the description doesn't need to add parameter-level semantics. The description adds minimal context by tying file_id to the file being downloaded, but it adds no format, constraints, or allowed values beyond the schema. Schema coverage is 100%, 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 names the exact operation ('Download a Rentvine file as base64') and clarifies it is a live read, making the action unambiguous. It also contrasts with list_attachments by describing what this tool returns versus what that workflow step is for. However, it does not explicitly differentiate itself from the similarly named sibling get_file, so the distinction is clear but not fully spelled out.

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 concrete guidance on when to pause before using it: if the file may be large, the agent should call list_attachments first to check file_size. This is an explicit condition and an explicit alternative, which helps an agent decide between tools. The ~1MB mention reinforces the boundary.

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 clearly states that this is a 'live data, read' operation, explicitly mentioning 'read' and that it returns metadata but not contents. This effectively discloses the behavioral trait of being a non-destructive read operation, which is sufficient given the simplicity of the 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 concise (three sentences) and front-loaded with the core purpose. It mentions the key detail about not returning contents and points to the sibling tool, with no wasted words. 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?

Given the tool's simplicity (single parameter, no output schema, no annotations), the description is complete. It covers what the tool does, what it returns (metadata fields), what it doesn't return (contents), and how it differs from download_file. An agent has everything needed 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?

Schema description coverage is 100%, so the schema already documents the parameter (file_id) with a description. The description also mentions 'by file_id', which is redundant with the schema. It doesn't add extra semantics like format or constraints beyond what the schema provides, so a 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 'Get metadata for a single Rentvine file by file_id', specifying the action (get), the resource (file), and the identifier (file_id). It also explicitly says it returns metadata (name, size, mime type, attachment info) but not contents, distinguishing it from download_file.

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 (to get metadata) and explicitly mentions the alternative (download_file) for fetching content. It doesn't explicitly state when not to use it, but the exclusion is implied by naming the alternative and noting 'but not file contents'. This is clear enough for an agent to select correctly.

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 usefully states that the data is live and that the response contains balance and ledger data. It does not mention permissions, error behavior, or what exactly 'ledger data' includes, which prevents a higher score.

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

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

The description is a single front-loaded sentence with no filler. Every phrase adds value: the operation, the resource, the live-data nature, and the expected return 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?

For a simple one-parameter read tool, this is nearly complete: the required input is clear and the return payload is summarized. It would be fully complete if it specified the format or scope of 'ledger data,' especially since no output schema is provided.

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

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

The single parameter tenant_name is already fully described in the schema, so schema description coverage is 100%. The tool description adds no further parameter-level meaning, making the baseline 3 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 names the verb and resource: it gets a tenant's current ledger balance from Rentvine. It is unambiguous next to siblings like list_tenants and search_transactions, but it never explicitly differentiates itself from those alternatives, so it stops short of full sibling differentiation.

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 wording implies this is the correct tool when a tenant's current live balance is needed, and no sibling appears to offer the same balance-specific operation. However, it gives no explicit when-to-use or when-not-to-use guidance, nor does it name alternatives such as list_tenants or search_transactions.

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 behavioral disclosure burden. It discloses that data is live, identifies the underlying endpoint, enumerates key returned fields, and explains the special `code` parsing behavior. It doesn't cover errors or auth, but for a single-resource GET this is substantive.

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, with the core action front-loaded and the detail sentence providing only behavior-relevant information. The field enumeration is somewhat long but earns its place by helping the agent predict what the tool returns.

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 one required parameter, no output schema, and no annotations; the description covers the input source, the live-data nature, and the important return fields including the unusual code_metadata parsing. An agent has enough 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 description coverage is 100% for vendor_id, so the schema already documents the parameter. The description adds context about where vendor_id comes from and what kind of ID it is, but doesn't need to do more given the schema coverage.

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

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

The description uses a specific verb ('Get'), names the resource ('a single vendor's full details'), and clarifies it returns ~20 fields not available via list_vendors. This clearly distinguishes it from sibling list tools without needing to open schemas.

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 contrasts this tool with list_vendors by noting the extra fields, and tells the agent that vendor_id comes from list_vendors or vendors_near. It implies the correct use case but doesn't explicitly state when not to use it or why list_vendors would be preferred.

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 present, the description carries the full burden. It adds useful behavioral context by specifying 'live data' and by listing the exact fields returned (account ID, number, name, category, active status), which goes beyond a bare 'list accounts' statement. It could mention pagination or limits, but for a simple list tool this is solid coverage.

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, no filler, with the primary action and scope in the first sentence and return-value plus use-case context in the second. 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 list tool, the description is nearly complete: it names the data source, the returned fields, and a concrete downstream use-case. Without an output schema, the explicit field list compensates well, though a note about ordering or data volume would make it fully complete.

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

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

The tool has zero parameters and the schema coverage is 100%, so there is nothing for the description to document. Per the rubric, a zero-parameter tool starts at baselinescore 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 states a specific verb and resource ('List the chart of accounts from Rentvine (live data)'), enumerates the returned fields, and distinguishes it from sibling list tools that target other entities. This is immediately actionable and 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 clearly identifies a contextual use case: 'Useful for identifying accountIDs when creating bill charges.' It does not explicitly name alternatives or exclusions, but for a zero-parameter listing tool the intended usage is clear enough.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does add useful context by stating 'live data' and listing returned fields. However, it does not mention pagination, sorting, filtering, rate limits, or whether all applications are returned regardless of status.

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

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

The description is a single concise sentence that front-loads the key action and source. Every part earns its place: the verb, the resource, the data source, and the relevant return fields. No unnecessary wording.

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

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

For a simple zero-parameter list tool, the description is complete. It states what the tool does, where the data comes from, and what fields will be returned. No output schema exists, but the description adequately covers the return contract.

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

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

The input schema has no properties, so there are no parameters to document. Per the calibration rule, a zero-parameter tool earns a baseline of 4. The description adds value by listing output fields, which is more than necessary for 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 uses a specific verb and resource: 'List rental applications from Rentvine'. It clearly states the resource and distinguishes it from sibling tools like list_properties or list_tenants. Mentioning the returned fields further clarifies 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 implies the tool is for retrieving rental application data from Rentvine, which gives broad usage context. However, it does not explicitly state when to prefer this over alternatives or provide exclusion criteria. The usage 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states this is a read operation on 'live data,' which is valuable safety context. It also lists the returned metadata fields, though it does not mention pagination or permission requirements.

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

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

The description is two sentences with no wasted words. The main purpose and read-only nature are front-loaded, and the prerequisite guidance is placed at the end, making it easy to parse.

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

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

Despite no output schema or annotations, the description provides return metadata, read semantics, and a pointer to the prerequisite lookup tool. The main missing detail is pagination or result-size behavior, which would be useful for a list operation, but the description is otherwise sufficient for a moderately simple 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 schema already explains both parameters with examples. The description adds no parameter-specific detail beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb and resource: 'List files attached to any Rentvine object,' which clearly states what the tool does. The phrase 'any Rentvine object' distinguishes it from sibling tools like list_work_order_attachments, making the scope easy to grasp.

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 context by stating the tool works with any Rentvine object and provides an explicit prerequisite: 'Use list_object_types to find the correct object_type_id.' It does not explicitly discuss alternatives or exclusion cases, but the scope and prerequisite are clear enough for an agent to know when 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does add useful context by noting this is 'live data' and specifying the returned fields, but it does not state whether the operation is read-only, whether there is pagination, or how errors/latency may behave.

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 with no filler. The primary action and scope are front-loaded, and the follow-up sentence adds value by listing return fields and a use case.

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, parameterless list tool, the description provides all essential context: what it lists, where the data comes from, what fields are returned, and when to use it. No output schema exists, but the description compensates by summarizing the output.

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 parameter semantics are inherently trivial. The baseline for no-parameter tools is 4, and the description adds no misleading or unnecessary parameter information.

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

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

The description uses a specific verb ('List all bills') and clearly identifies the resource (bills from Rentvine) and scope. It also enumerates the returned fields, making the tool's purpose unmistakable even among many sibling 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 phrase 'Use this to review outstanding vendor invoices' provides a clear context for when to invoke the tool. It does not explicitly exclude alternatives or mention when not to use it, but for a zero-parameter list tool this context is sufficient.

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

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

No annotations are present, so the description itself must carry behavioral disclosure. It does state 'live data,' which communicates freshness and implies a network call rather than a cache. However, it doesn't disclose pagination, result limits, ordering, or any read-only guarantees. For a simple list tool this is a partial but acceptable 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?

Two sentences with the action and source up front, then the return fields. No fluff, no repetition of the tool name beyond what is needed. Every word adds information.

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

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

For a zero-parameter list tool with no output schema, the description covers the main context: what is listed, sourced, and what fields are returned. Pagination or result limits are not mentioned, but for this simple read-only list tool the description is nearly complete.

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

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

The tool has zero parameters)SkipThe input schema is empty and there are no parameters to documentikuha. Baseline for 0 params is 4, and the description does not need to compensate. No parameter semantics are missing.

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

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

The description uses a specific verb (list) plus a specific resource (maintenance inspections) and clearly names the source (Rentvine). It distinguishes itself from sibling tools by specifying the object type (inspections vs. work orders, properties, etc.) and enumerating the exact fields returned, which disambiguates it from generic list_* 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?

The description states what the tool does but gives no guidance on when to choose it versus the many sibling listing tools. It doesn't mention conditions, prerequisites, or exclusions. The 'maintenance inspections' wording implies the use case, but there is no explicit routing to alternatives or contextual hints about when it is preferred.

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

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

No annotations exist, so the description owns the burden of behavioral disclosure. It does state the tool retrieves 'live data' and returns 'all leases', which clarifies its scope and data freshness. However, it does not mention pagination, rate limits, or whether the query can be filtered. For a single-purpose list tool this is acceptable 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 two sentences: the first is a clear statement of the action and data source, the second lists the return fields and typical use cases. No filler or repetition; it is appropriately compact.

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

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

Despite lacking an output schema and annotations, the description supplies the key elements an agent needs: what data is returned, the data origin, and the use cases. For a zero-parameter list tool, this is nearly complete. It omits pagination or ordering behavior, but those are secondary for a simple list 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?

The tool has zero parameters, and the schema shows no properties, so the description is not expected to add parameter details. With an empty parameter space, the provided description adds meaningful context (what fields come back) that supports interpretation of the result, but it does not need to explain 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 uses a specific verb-resource pair ('List all leases'), names the data source ('Rentvine live data'), and enumerates the returned fields. It is immediately distinct from sibling tools such as list_tenants or list_properties by the object type, so an agent can tell what the tool does.

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

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

The description gives explicit conditions for using the tool: 'questions about lease expirations, rent amounts, or active tenants.' It does not name alternatives to exclude, but the use cases are clear and actionable, leaving little ambiguity about when to invoke this tool.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does state that it returns a full table of IDs and names, which covers its output behavior. However, it does not explicitly state that it is a read-only operation or whether there are any side effects, pagination, or permission requirements. For a simple list tool 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 two sentences, with the purpose stated first and the utility example second. Every sentence contributes: the first defines what the tool does, the second explains the purpose and provides examples. There is no fluff or redundancy with the name.

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

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

For a parameterless listing tool with no output schema, the description provides everything an agent needs: the target entity, the output shape (ID + name pairs), and the practical use case. The examples '7 = Unit, 16 = Work Order, 4 = Lease' give concrete grounding. There are no gaps that would risk incorrect 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?

The tool has zero parameters, and the schema confirms this with an empty properties object. The description adds no parameter information because none is needed. Per the rubric, 0 parameters yields a baseline of 4, and there is no reason to penalize.

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

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

The description clearly states the action ('List') and the resource (Rentvine object types), and expands on the output: 'Returns the full table of object_type_id values and names'. It also distinguishes its utility from sibling tools by explicitly connecting it to upload/attach workflows, which no other sibling name suggests.

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

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

The description gives a direct when-to-use context: 'Use this to find the correct object_type_id when uploading files or attaching documents.' This is clear guidance, even though it does not explicitly mention alternatives or negative cases. Since no sibling tool serves this distinct purpose, the absence of exclusions is acceptable.

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?

There are no annotations, so the description carries the full burden. It discloses that this is live data and specifies the returned fields, which conveys a read-only listing behavior. However, it does not mention pagination, result limits, or any other operational caveats that could matter for a tool returning 'all' owners.

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 lean sentences with no filler. The primary action and data source are front-loaded, followed by the return fields and concrete usage hints. 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, read-only list tool, the description covers purpose, source, fields returned, and use cases. It lacks pagination or scale caveats for 'all' owners, but the absence of an output schema and parameters makes the description 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 has zero parameters, so the description needs no parameter-level detail. Per the rubric, a zero-parameter tool receives a baseline of 4; the description does not undermine this and instead clarifies the output fields, adding slight 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 opens with a specific verb and resource: 'List all property owners from Rentvine (live data)'. It also explicitly names the returned fields (owner name, contact ID, email, phone, address), making it distinguishable from sibling tools like list_properties or list_tenants.

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 use cases: look up who owns a property or get a contact ID for bill creation. It does not explicitly state when not to use this tool or name alternatives, but the use-case framing gives the agent enough context to select 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does mention 'live data' and details the return fields, but it does not explicitly state that it is read-only, comment on authentication, rate limits, pagination, or error behavior. For a simple list operation, this is adequate but not rich; the lack of side-effect disclosure is probably fine, but the absence of any caveats about live data or potential limitations leaves a moderate gap.

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

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

The description is a single sentence that is front-loaded with the action and resource, followed by the return details. It contains no filler, is immediately understandable, and uses the available space optimally.

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

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

Given that there are no parameters, no output schema, and no annotations, the description does an adequate job of contextualizing the tool. It tells the agent what data to expect in the response (including specific fields) and where the data comes from. However, it could be slightly more explicit about the output shape (e.g., whether owners are an array or a flat list) and about any limits or pagination. For a simple list tool, it is reasonably complete, just missing those minor 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 tool has zero parameters, so all parameter semantics are trivially handled by the empty input schema. The description does not need to add parameter explanations. According to the rubric, a 0-parameter tool baseline is 4, and the description adds no clutter. This 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 a specific verb ('List'), a resource ('portfolios'), and the source ('Rentvine (live data)'). It also enumerates the returned fields (portfolio name, ID, active status, reserve amount, associated owners), making it distinct from sibling list tools like list_owners or list_properties. An agent immediately knows what this tool does.

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

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

The description clearly conveys that this tool is for retrieving all portfolios, which implicitly tells the agent when to use it (i.e., when a complete list of portfolios is needed). While it does not explicitly mention alternatives or exclusions, it is unambiguous about its purpose and distinguishes itself from sibling list tools by its resource focus. Thus, clear context with no exclusions.

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

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

No annotations are provided, so the description carries the full burden. It does add the behavioral trait 'live data' and discloses the returned fields, but omits any mention of pagination, ordering, errors, or authentication expectations, which a read tool of this scope might still need.

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 no filler. Both sentences earn their place: the first states the action and source, the second states the return fields.

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 tool, the description explains the operation and key return fields. It is mostly complete, though it omits ordering or pagination details; given the simplicity, 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?

There are zero parameters, so there is nothing to explain; the schema already covers the empty parameter set. The description's mention of returned fields adds useful context but is separate from parameter semantics, so the baseline of 4 for zero-parameter tools 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 ('list') and resource ('all properties'), with the source system ('Rentvine') and a 'live data' qualifier. This clearly distinguishes it from sibling list tools like list_units and list_leases by the resource type.

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

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

No guidance is provided on when to use this tool versus alternatives. With many list_* siblings, explicit routing or exclusions would help, but none is present; the description only states what it does, not when it should be selected.

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 behavioral burden. It discloses that data is live, that filtering is applied via search and active_only, and that sensitive fields are omitted by default unless include_sensitive=true. This is meaningful transparency, though it does not cover paging, ordering, or error 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 front-loaded with the core action, then lists return fields, use cases, filtering behavior, and the sensitive-field caveat. Every sentence contributes useful information, and the pointer to the parameter description avoids unnecessary duplication.

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 five optional parameters and no output schema, the description covers purpose, return fields, filters, and sensitive-field handling. Paging behavior is left to the schema descriptions, which is acceptable, though a brief mention of pagination/truncation risks would have made it more 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 the schema already documents every parameter. The description adds a little context by summarizing search and active_only and emphasizing the sensitive-data caveat, but it mostly repeats what the schema already says. 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 opens with a specific verb and resource: 'List all tenants from Rentvine (live data).' It enumerates the exact returned fields and explicitly names two use cases (look up contact details, get a contact_id for other calls), which clearly distinguishes it from sibling list tools like list_owners and list_vendors.

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 guidance on when to use the tool: 'Use this to look up a tenant's contact details or to get a contact_id for other calls.' It does not explicitly state when not to use it or name alternatives, but the intended context is clear enough for an agent.

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

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

With no annotations provided, the description carries the full burden. It adds one behavioral clue: 'live data', which indicates a real‑time fetch rather than cached data. However, it does not disclose error behavior (e.g., unknown property), permissions, pagination, or any side effects, though the word 'list' implies a read-only 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 two concise sentences. The first sentence names the action and resource; the second lists the returned fields. There is no redundant or vague wording, making it easy to parse quickly.

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

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

The tool is simple (1 required parameter, no output schema). The description compensates for the missing output schema by enumerating the returned fields. It falls short in not describing potential error or empty-list behavior, but that is not critical for a basic 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 input schema already has 100% parameter coverage with a clear description of 'property_name'. The tool description only restates that units are 'for a property' and does not add extra meaning or constraints 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 action ('List units'), the resource ('units'), and the context ('for a property'). It also names the specific returned fields (address, vacancy status, rent amount, deposit), making it distinct from sibling list tools like list_properties or list_leases.

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 phrase 'for a property' and the required 'property_name' parameter, but no explicit guidance or exclusions are provided. The description does not mention when to prefer this tool over list_properties or how to first obtain a property 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?

With no annotations present, the description carries the full behavioral disclosure burden. It discloses that data is live, that the response contains sensitive PII and financial fields (birth_date, identification_number, ACH details), and that trade categories/service areas are not exposed by the API. This is meaningful transparency beyond the schema, though it does not mention pagination or rate limits.

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

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

Every sentence earns its place: the lead sentence states the core action, the next summarizes the return fields, the third gives concrete use cases, and the final sentence warns about data sensitivity. The description is long but densely informative known, with the main purpose 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?

With zero parameters and no output schema, the description carries the full burden of informing the agent. It compensates by enumerating the major field categories, noting live data, listing realistic use cases, calling out a known API limitation (no trade categories/service areas), and warning about PII and financial sensitivity. There is no missing information needed to invoke or interpret the tool's 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 has zero parametersaren an empty schema, and schema description coverage is 100%, so there are no parameter semantics for the description to clarify. The baseline for 0-param tools is 4, and the description appropriately focuses on the return payload rather than inputs.

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

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

The description opens with a specific action and resource: 'List all vendors from Rentvine (live data).' It clearly distinguishes this list tool from a single-record getter by saying it returns every field the /vendors/search endpoint exposes, and it names recognizable vendor fields. The purpose is unambiguous even 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?

The description explicitly states when to use the tool: 'Use to find vendors for work-order assignment, bill creation, or compliance review.' It does not explicitly say when not to use it or compare it against the sibling get_vendor tool, but the use cases and 'all vendors' scope imply the distinction. A brief exclusion note would make it fully comprehensive.

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 notes 'live data, read', which conveys a read-only behavior, and explains the fixed object_type_id=16. However, with no annotations provided, it does not disclose details like whether the response includes metadata, pagination, or file types. The read-only hint is useful but minimal.

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 with no wasted words. The core purpose is front-loaded, and the wrapper detail is concise and 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 simple one-parameter read tool, the description is nearly complete. It lacks an explicit note about the return format or pagination, but the simplicity of the tool and the clear wrapper explanation make it adequate. The absence of an output schema is not a major gap here.

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

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

Schema description coverage is 100% for the single parameter, so the schema already documents work_order_id as the Rentvine workOrderID. The description adds no additional parameter semantics beyond the schema, 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 the tool lists images and files attached to a specific work order, using a specific verb and resource. It also distinguishes itself from the generic list_attachments sibling by noting it is a convenience wrapper with object_type_id fixed to 16.

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 attachments for a specific work order, versus list_attachments for other object types. It does not explicitly state when not to use it or name alternatives beyond the wrapper relationship, but the context is clear enough.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It does state that data is live and lists the returned fields, which is useful. However, it does not mention pagination, authentication requirements, rate limits, or whether the list is filtered or sorted.

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

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

The description is a single sentence that front-loads the action and resource, then follows with a compact list of return fields. There is no filler, redundancy, or unnecessary detail.

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

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

For a parameterless, read-only list tool with no output schema, the description covers source, scope, and the main returned fields. It could have mentioned pagination or the absence of filtering, but given the low complexity, this is nearly complete.

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

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

The tool has zero parameters and the schema coverage is 100%, so there is no parameter meaning for the description to add. With 0 params, the baseline is 4, and the description adds useful context about the output fields instead.

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

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

The description uses a specific verb ('List'), a clear object ('all maintenance work orders'), and a source system ('Rentvine'), then names the returned fields. This clearly distinguishes it from sibling tools like list_owners or list_inspections, though it does not explicitly contrast it with list_work_order_attachments.

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 usage context is implied: use this when you need all maintenance work orders and their key details. However, the description does not explicitly state when not to use it or how it differs from alternatives such as update_work_order or list_work_order_attachments.

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 behavioral burden. It usefully discloses that this queries live data, supports pagination via page/page_size, and returns specific fields. It does not mention rate limits or sort behavior, but for a read-oriented search tool this is solid coverage.

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, purposeful sentences: scope and live-data warning first, then filters, then return shape and pagination. Every sentence earns its place and there is 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?

Even without an output schema, the description states the main returned fields. It covers the core search scenarios, filter categories, and pagination behavior, while the schema handles parameter formats. The tool is fully selectable and invokable from this description 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 100%, so each of the 8 parameters is already documented. The description adds value by grouping parameters into keyword, date-range, and amount-range categories and by calling out pagination, but it adds no format or constraint details beyond the schema. Baseline 3 is appropriate.

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

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

The description opens with a specific verb + resource: 'Search accounting transactions in Rentvine (live data).' It names the exact filters (keyword, date range, amount range) and the returned fields, making it immediately distinct from the flat list_* sibling tools. No tautology or 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 gives clear context for when to use the tool: searching live accounting transactions with flexible filters, and using pagination for large result sets. It does not explicitly name alternative tools or state when not to use it, so it stops just short of a 5.

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

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

No annotations are provided, so the description rightly carries the burden. It discloses that this is a live write operation and reveals a meaningful side effect: setting status to completed/cancelled auto-stamps date_closed to today unless explicitly provided. It doesn't cover reversibility or permissions, but the critical behavior is surfaced.

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 dense, purposeful sentences: the first states purpose and enumerates editable fields; the second discloses a subtle auto-behavior. Zero filler, info-rich 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?

Given the absence of annotations and output schema, the description covers the key agent-relevant points: side effects, ID source, editable fields. It doesn't mention permissions or whether partial updates preserve untouched fields, but it is strong enough to support 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?

The schema itself already documents the parameters well-hat. The description adds a valuable warning about work_order_id being the Rentvine system ID, not the human-facing number, but otherwise mostly restates what the schema conveys.

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?

Opens with a specific verb and resource — 'Update a maintenance work order in Rentvine (live data, write)' — and clearly enumerates the mutable fields. It distinguishes itself from list_work_orders by explicitly positioning itself as the mutate counterpart.

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 says exactly when to use the tool ('use this to change status, priority, scheduling dates...') and references list_work_orders as the source for the correct work_order_id. It doesn't state exclusions for when not to use it, but the guidance is concrete and actionable.

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 performance characteristics (base64 is extremely slow and fills the context window), the server-side read behavior for file_path, and the existence of a fallback for remote deployments. It doesn't explicitly state whether the upload is a write/destructive operation, but the verb 'upload' and the context make that clear enough.

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 primary use case, then the key decision rule, then the fallback. Every sentence earns its place. Slight redundancy between the description and the schema's file_content_base64 description, but the emphasis is intentional and useful.

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 5-parameter tool with no output schema and no annotations, the description covers the main decision (file_path vs base64), the attachment semantics, and how to find valid object_type_id values. It doesn't describe the response format, but with no output schema that is a minor gap. It also doesn't mention whether object_id is required when attaching, but the schema marks no parameters as required.

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 explaining the trade-off between file_path and file_content_base64, and by giving an example object_type_id (7 = Unit). It also clarifies that file_name is an override and inferred from file_path if omitted, which is 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 states a specific verb ('Upload a file to Rentvine') and resource, and clarifies optional attachment to a work order, property, lease, or unit. It distinguishes itself from sibling tools like get_file and download_file by focusing on upload, and from list_attachments by focusing on creation.

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

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

The description gives explicit when-to-use guidance: use file_path for local files, use file_content_base64 only for remote/HTTP deployments with no shared filesystem, and use list_object_types to get valid object_type_id values. It also explicitly says NEVER use file_content_base64 for local files, which is strong exclusionary 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 valuable behavioral traits: the property's geocoded center, vendor ZIP-centroid approximation, 'coarse filter' limitation, and distance sorting. Yet it does not state whether it is strictly read-only, any permissions needed, or what happens when a property lacks geocoding – a noticeable gap given zero annotations.

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

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

The description is moderately lengthy but each sentence serves a purpose: purpose, algorithm, output ordering, defaults, and caveat. It would be slightly better if defaults were not already in schema descriptions, but it's 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?

For a search tool with no output schema, the description covers the core mechanics: geocoding source, approximation, distance annotation, randomness, defaults, and precision. It omits edge-case behavior (missing geocoding), pagination, and error responses, but given its relative simplicity, it's 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 description coverage is 100% and parameter descriptions already define radius_mi (default 25) and active_only (default true). The tool description repeats some defaults but adds no new parametric insight, so it does not go beyond the schema. The 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?

Description states a specific verb-resource pair: 'Find vendors within a radius of a property' and includes unique details like radius and distance sorting that distinguish it from siblings such as list_vendors/get_vendor. The tool's purpose is immediately clear and 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 clearly conveys when to use this tool – when you need vendors near a property – and even details the approximation method, implying it's a specialized alternative to general list_vendors. However, it does not explicitly mention when NOT to use it or alternative tools, but the context is strong enough to infer.

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