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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes what the tool does (get metadata) but lacks details on behavioral traits such as whether it requires authentication, has rate limits, returns paginated results, or handles errors. For a tool with no annotation coverage, this is a significant gap in transparency.

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

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

The description is appropriately sized and front-loaded, with the first sentence stating the core purpose and the second providing illustrative examples. Every sentence earns its place by clarifying usage without unnecessary details, making it efficient and easy to understand.

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

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

Given the tool's complexity (metadata retrieval) and the absence of annotations and output schema, the description is adequate but incomplete. It covers the purpose and usage with examples, but lacks details on behavioral aspects and return values, which are important for a tool that likely returns structured metadata. A minimum viable description is provided, but gaps remain.

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, with the single parameter 'objectName' well-documented in the schema. The description adds minimal value beyond the schema by providing examples ('Account', 'Case', 'Custom_Object__c'), but does not elaborate on parameter semantics like format constraints or usage nuances. Baseline 3 is appropriate as the schema does the heavy lifting.

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

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

The description clearly states the specific verb ('Get detailed schema metadata') and resource ('any Salesforce object'), with concrete examples ('Account', 'Case') that illustrate what the tool retrieves. It distinguishes itself from sibling tools like salesforce_query_records or salesforce_search_objects by focusing on schema metadata rather than data records or object searches.

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

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

The description provides clear context for when to use this tool: to obtain schema metadata including fields, relationships, and properties. It implies usage through examples like 'Account' and 'Case', but does not explicitly state when not to use it or name specific alternatives among the sibling tools, such as salesforce_search_objects for finding objects rather than describing them.

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

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

With no annotations provided, the description carries full burden. It discloses that operations are destructive (insert, update, delete, upsert) and mentions prerequisites like requiring Id for update/delete and external ID field for upsert. However, it doesn't cover authentication needs, rate limits, error handling, or what happens on partial failures.

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 efficiently structured with a clear opening statement followed by bullet points for each operation and examples. Every sentence earns its place by providing essential information without redundancy. It's appropriately sized and front-loaded with the core purpose.

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

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

For a mutation tool with 4 parameters, no annotations, and no output schema, the description is adequate but has gaps. It covers the basic operations and parameters but doesn't address return values, error conditions, or system-level constraints. Given the complexity of DML operations, more behavioral context would be beneficial.

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 what each operation does (e.g., 'upsert: Insert or update based on external ID field') and providing concrete examples that clarify parameter usage ('Insert new Accounts, Update Case status'). This enhances understanding beyond the schema's technical descriptions.

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

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

The description clearly states the tool performs data manipulation operations on Salesforce records with specific verbs (insert, update, delete, upsert) and distinguishes it from sibling tools like salesforce_query_records (read-only) and salesforce_describe_object (metadata). It explicitly names the resource (Salesforce records) and the action scope (data manipulation).

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 each operation type (e.g., 'update: Modify existing records (requires Id)'), but doesn't explicitly state when to choose this tool over alternatives like salesforce_manage_object or salesforce_upload_report_xml. It gives operational guidance but lacks sibling differentiation.

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 effectively communicates that this is a metadata mutation tool ('Changes affect metadata'), specifies permission requirements ('require proper permissions'), and provides examples of operations. It doesn't mention rate limits, error handling, or the impact on existing data, but covers the essential safety and scope aspects well for an unannotated 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 efficiently structured with a clear opening statement followed by bullet-pointed categories and specific examples, then a critical note about permissions. Every sentence earns its place by providing distinct value: the purpose, parameter categories, concrete examples, and important constraints.

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

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

For a complex metadata mutation tool with 17 parameters and no annotations or output schema, the description does well by explaining the tool's purpose, scope, permission requirements, and providing examples. However, it doesn't describe what the tool returns (success/failure indicators, field IDs, etc.), which would be helpful given the absence of an output schema. The parameter coverage is handled by the schema, but behavioral context is adequately addressed.

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

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

The schema description coverage is 100%, so the schema already documents all 17 parameters thoroughly. The description adds some context by listing categories of parameters ('Field Types', 'Properties', 'Relationships') and providing examples, but doesn't add significant semantic meaning beyond what's already in the parameter descriptions. This meets the baseline for high 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 clearly states the specific verb ('Create new custom fields or modify existing fields') and resource ('on any Salesforce object'), distinguishing it from siblings like salesforce_describe_object (metadata inspection), salesforce_dml_records (data manipulation), and salesforce_manage_object (object-level operations). It precisely defines the scope of field management operations.

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 (creating/modifying fields with specific types and properties) and mentions prerequisites ('require proper permissions'). However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools, such as when to use salesforce_manage_object instead for object-level changes.

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 full burden. It discloses important behavioral traits: 'Changes affect metadata' (not data), 'require proper permissions', and the dual create/update capability. However, it doesn't mention potential side effects, error conditions, or what happens during updates to existing objects (e.g., whether changes are reversible).

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

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

The description is well-structured with a clear opening statement, bullet points for operations, examples, and a note about permissions. It's appropriately sized for a complex tool, though the bullet formatting could be more concise. Every sentence adds value, with no redundant information.

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

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

For a complex metadata mutation tool with 9 parameters and no annotations or output schema, the description provides adequate but incomplete coverage. It explains the core operations and permission requirements but lacks details about return values, error handling, and the full scope of what can be modified. The examples help but don't substitute for comprehensive behavioral documentation.

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

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

Schema description coverage is 100%, so the schema already documents all 9 parameters thoroughly. The description adds minimal value beyond what's in the schema - it mentions 'fields, relationships, and settings' for create operations and 'settings, labels, sharing model' for updates, but doesn't provide additional semantic context beyond the parameter descriptions.

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

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

The description clearly states the tool's purpose with specific verbs ('Create new custom objects or modify existing ones') and resources ('in Salesforce'), distinguishing it from siblings like salesforce_describe_object (read-only) and salesforce_manage_field (field-level operations). It explicitly covers both create and update operations.

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 ('Create new custom objects or modify existing ones') and mentions permission requirements, but doesn't explicitly contrast with alternatives like salesforce_manage_field for field-level changes or salesforce_dml_records for data operations. The examples help but don't establish explicit boundaries.

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 adds useful context about relationship query syntax (dot notation, subqueries, custom fields ending in '__r'), which helps the agent understand how to structure queries. However, it doesn't mention important behavioral traits like pagination, rate limits, authentication needs, or error handling, leaving gaps for a tool with 5 parameters and no output schema.

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

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

The description is appropriately sized and front-loaded with the core purpose in the first sentence, followed by helpful examples. The examples are well-structured but slightly lengthy; every sentence earns its place by clarifying relationship query usage, though it could be more concise by integrating some explanatory notes into the examples themselves.

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 complexity of a Salesforce query tool with 5 parameters, no annotations, and no output schema, the description is moderately complete. It covers the core functionality and relationship syntax well but lacks details on behavioral aspects (e.g., result format, error cases, limits) and doesn't fully compensate for the absence of an output schema, leaving the agent uncertain about what to expect from the tool's response.

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

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

Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description adds value by providing concrete examples that illustrate how to use parameters like fields and whereClause with relationship queries, but it doesn't add semantic meaning beyond what the schema descriptions already state. This meets the baseline of 3 for high 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 clearly states the tool's purpose: 'Query records from any Salesforce object using SOQL, including relationship queries.' This specifies the verb ('query'), resource ('records from any Salesforce object'), and method ('using SOQL'), distinguishing it from siblings like salesforce_dml_records (for data manipulation) and salesforce_search_all/search_objects (for search operations).

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 by emphasizing SOQL queries with relationship support, which implicitly differentiates it from search tools that might use different query languages or scopes. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the siblings, such as when to prefer salesforce_search_all over 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 provided, the description carries full burden for behavioral disclosure. It mentions access control options ('updateable' and 'viewable' options control record access filtering') and search capabilities, but doesn't cover important behavioral aspects like rate limits, authentication requirements, error handling, or what the output looks like. It provides some operational context but misses key behavioral traits.

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

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

The description is front-loaded with the core purpose, but includes extensive examples and notes that could be streamlined. While informative, some details (like the second advanced example) might be excessive. The structure is logical but could be more concise while maintaining clarity.

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

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

For a complex search tool with 6 parameters, no annotations, and no output schema, the description provides good operational guidance but lacks critical context. It doesn't describe the return format, error conditions, performance characteristics, or how results are structured across multiple objects. The examples help but don't fully compensate for missing behavioral and output information.

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

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

With 100% schema description coverage, the baseline is 3. The description adds significant value through detailed examples showing how parameters work together, explanations of wildcard support, WITH clause types, and object-specific clauses. It provides practical context beyond the schema's technical definitions, though it doesn't fully explain all parameter interactions.

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 specific action ('Search across multiple Salesforce objects') and technology used ('using SOSL'), distinguishing it from sibling tools like salesforce_query_records (which likely uses SOQL) and salesforce_search_objects (which might be more limited). It provides a verb+resource+method combination that is precise and differentiated.

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

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

The description implies usage context through examples and notes (e.g., 'Search across multiple Salesforce objects'), but doesn't explicitly state when to use this tool versus alternatives like salesforce_query_records or salesforce_search_objects. It provides operational guidance but lacks comparative context with sibling 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?

No annotations are provided, so the description carries the full burden. It mentions searching for standard and custom objects with examples, but doesn't disclose behavioral traits such as whether this is a read-only operation, if there are rate limits, authentication needs, or what the return format looks like. For a search tool with zero annotation coverage, this is a significant gap in transparency.

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

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

The description is highly concise and front-loaded, consisting of two sentences that directly explain the tool's purpose and provide illustrative examples. Every sentence earns its place without unnecessary elaboration, making it efficient and easy to understand.

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 complexity of a search operation with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects (e.g., read-only status, rate limits), output format, and doesn't fully compensate for the absence of structured data. This makes it inadequate for an AI agent to fully understand the tool's behavior and usage context.

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

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

The schema description coverage is 100%, with the parameter 'searchPattern' fully documented in the input schema. The description adds examples like 'Account' and 'Order' to illustrate usage, but doesn't provide additional semantic details beyond what the schema already states (e.g., pattern matching rules or case sensitivity). Baseline 3 is appropriate as the schema handles the heavy lifting.

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

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

The description clearly states the tool's purpose as searching for Salesforce objects by name pattern, with specific examples like 'Account' and 'Order'. It distinguishes from siblings by focusing on object search rather than describing objects (salesforce_describe_object), managing objects (salesforce_manage_object), or searching all data (salesforce_search_all). However, it doesn't explicitly contrast with salesforce_search_all, which might handle broader searches.

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

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

The description implies usage when searching for objects by name pattern, as shown in the examples. However, it doesn't explicitly state when to use this tool versus alternatives like salesforce_search_all or salesforce_describe_object, nor does it provide exclusions or prerequisites. The context is clear but lacks explicit guidance on tool selection.

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 effectively describes the tool's dual functionality (create/update), default behavior (uploads to user's private reports by default), and important constraints (XML format requirements, report type prerequisites). However, it doesn't mention potential side effects like overwriting existing reports during updates or authentication 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 efficiently structured with a clear purpose statement followed by numbered examples and important notes. Every sentence adds value: the opening defines the tool, examples demonstrate usage, and notes provide critical constraints. No wasted words or redundant information.

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

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

For a 5-parameter mutation tool with no annotations and no output schema, the description does an excellent job covering usage patterns, constraints, and prerequisites. The main gap is the lack of information about return values or error conditions, which would be helpful given the absence of an output schema. However, the description provides substantial context for proper tool invocation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds significant value by clarifying parameter usage patterns through concrete examples, showing how parameters combine for different scenarios (new report requires reportName, update requires reportId), and explaining the optional folderId default behavior. This goes well beyond what the schema provides.

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

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

The description clearly states the tool's purpose with specific verbs ('upload XML to generate or update reports') and identifies the resource ('reports in Salesforce'). It distinguishes this from sibling tools like salesforce_query_records or salesforce_dml_records by focusing specifically on report XML upload functionality.

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

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

The description provides explicit usage guidance through numbered examples showing when to use different parameter combinations (create new report vs. update existing report). It also includes important contextual notes about XML format requirements and prerequisites for custom report types, which helps the agent understand when this tool is appropriate.

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