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

No annotations exist, so description carries full burden. It discloses limitations like OFFSET not supported and that all non-aggregate fields must be in groupBy. However, it does not mention side effects (likely read-only) or what happens on query failure.

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

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

Description is lengthy but well-structured with clear sections, bullet points, and examples. Every part serves a purpose and is front-loaded with a summary. Could be slightly more concise but not overly verbose.

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

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

Despite detailed input rules, the description lacks explanation of the output format (e.g., array of grouped records). Without an output schema, this gap may hinder correct invocation. The examples imply the result, but not explicitly stated.

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

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

Schema covers all 7 parameters, and the description adds extensive extra semantics: examples show parameter combinations, important rules about groupByFields and selectFields correlation, and format for date grouping. This goes well beyond the schema.

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

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

The description clearly states the tool executes SOQL queries with GROUP BY and aggregate functions. It distinguishes from sibling salesforce_query_records by specifying that it summarizes and groups data rather than returning individual records.

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

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

Explicitly advises to use salesforce_query_records for queries without GROUP BY or aggregates. Provides clear context on when to use whereClause vs havingClause and lists important rules for query construction.

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 of behavioral disclosure. It reveals important behaviors such as automatic conversion of date range filters to timeFrameFilter and auto-prefixing custom fields with the object name. However, it does not mention permission requirements (beyond folder access) or what the API call returns, leaving minor gaps.

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

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

The description is long but well-structured with clear headings, bullet points, and examples. It is front-loaded with key information like the IMPORTANT sections. While every section adds value, some repetition (e.g., field naming rules appear in multiple places) could be trimmed slightly, but overall it remains highly readable and efficient.

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

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

Given the tool's complexity (10 parameters, nested objects) and no output schema, the description covers the input thoroughly with workflows, examples, and conventions. However, it does not describe what the tool returns (e.g., report ID or success confirmation), which would be helpful for an agent to confirm the result. 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?

Schema coverage is high (90%), and the description adds substantial value beyond the schema by providing field naming rules (UPPERCASE for standard, __c for custom), examples of valid values for reportType (object names vs custom report types), and detailed usage patterns for filters (date ranges). This makes the parameters much clearer and easier to use correctly.

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

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

The description clearly states the tool creates a Salesforce report using the Metadata API, specifying supported formats (tabular, summary, matrix) and features like groupings, filters, and charts. This distinguishes it from sibling tools such as salesforce_read_report (which reads reports) or salesforce_list_reports (which lists reports). The verb 'Create' and resource 'Salesforce report' are specific and actionable.

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

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

The description includes a dedicated 'WORKFLOW TO CREATE A REPORT' section with step-by-step instructions, prerequisites (using salesforce_describe_report_type to discover fields), and explicit guidance on folder requirements and field naming conventions. It clearly tells the agent when and how to use this tool, including what to do before invoking it, making it easy to select this tool over alternatives.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It accurately describes the tool as returning schema metadata (a read operation) without side effects. However, it omits potential considerations like resource intensity for objects with many fields, API usage limits, or permission requirements beyond standard Salesforce describe access.

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

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

The description is two sentences long with zero wasted words. It front-loads the core purpose in the first sentence and provides clarifying examples in the second. Every part serves a purpose.

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

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

Given the single parameter, no output schema, and no annotations, the description is fairly complete. It explains what the tool returns and provides actionable examples. However, it could elaborate on the output structure (e.g., field types, relationships properties) to fully compensate for the missing output schema, though standard Salesforce metadata is well-known to agents.

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 provides 100% coverage for the single parameter 'objectName', describing it as the API name. The description adds significant value by giving concrete examples ('Account', 'Contact', 'Custom_Object__c') and clarifying that custom fields are included ('including custom fields'). This helps the agent understand the parameter format and scope.

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

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

The description clearly states the verb 'Get' and the resource 'detailed schema metadata including all fields, relationships, and field properties of any Salesforce object'. It provides concrete examples ('Account', 'Case') that distinguish this tool from siblings like salesforce_query_records or salesforce_search_objects, which operate on data rather than metadata.

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 through examples but does not explicitly state when to use this tool versus alternatives (e.g., 'Use this to understand object structure before querying') or when not to use it. It provides no guidance on prerequisites or conditions, leaving the agent to infer context from the purpose alone.

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

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

No annotations are provided, and the description only states it returns details and fields, without disclosing read-only nature, rate limits, or other behavioral traits.

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

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

A single sentence that is concise and directly states the purpose without any extraneous information.

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

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

Given the simple nature of the tool (one parameter, no output schema needed), the description adequately explains what to expect.

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

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

Schema coverage is 100% and the description repeats the schema description without adding extra meaning beyond what's already in the parameter description.

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

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

The description clearly states the verb 'Get', resource 'specific report type', and includes 'available fields that can be used in reports', making it distinct from siblings like list_report_types.

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

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

The description implies usage for retrieving field information for report building, but does not explicitly exclude cases or mention alternatives like list_report_types.

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

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

No annotations are provided, so the description carries full burden. It discloses that these are modify operations, requires Id for update/delete, and upsert uses external ID field. However, it lacks details on permissions, rate limits, error handling, or idempotency, which are important for behavioral 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 fairly concise and well-structured using bullet points and examples. Each sentence adds value, though some redundancy exists (e.g., operation list repeated). It could be slightly shorter without losing clarity.

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

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

Given the absence of output schema and annotations, the description adequately covers the tool's purpose and parameters. However, it could mention return value behavior (e.g., IDs created) and error handling (e.g., partial success), which are lacking. Overall, it is sufficient but not thorough.

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

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

Schema coverage is 100% (all parameters described), so baseline is 3. The description adds contextual value (e.g., 'requires Id' for update/delete) but does not significantly enhance understanding beyond the schema definitions. It could better explain the format of records (e.g., required fields per operation).

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

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

The description clearly states it performs DML operations (insert, update, delete, upsert) on Salesforce records, with explicit examples (e.g., 'Insert new Accounts, Update Case status'). This distinguishes it from siblings like salesforce_query_records (read-only) and salesforce_describe_object (metadata).

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 context for each operation (e.g., 'requires Id' for update/delete, 'based on external ID field' for upsert) and includes examples. However, it does not explicitly state when not to use the tool or suggest alternatives, leaving room for ambiguity.

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

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

No annotations are provided, so the description carries full burden. It discloses that code runs anonymously, does not persist, includes debug logs, and may be restricted by permissions. However, it stops short of explicitly warning about potential data mutation or destructive actions.

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, three concise examples, and a bulleted notes section. It is front-loaded with purpose. The three examples could be trimmed to two without loss of clarity, but overall it is efficient.

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

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

Given the complexity of executing arbitrary code and the absence of an output schema, the description adequately covers execution results, debug logs, and security. It also positions the tool as a fallback, which adds important 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?

Schema coverage is 100%, setting a baseline of 3. The description adds value by providing examples, noting that 'apexCode' must be valid Apex, and clarifying the 'logLevel' defaults. This goes beyond the schema, justifying a higher score.

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 'Execute anonymous Apex code in Salesforce' with a specific verb and resource. Examples demonstrate common use cases, and it distinguishes itself from sibling tools by noting it can be used as a fallback when other tools are unavailable.

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

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

Explicit guidance: 'This tool can be used for data operations or updates when there are no other specific tools available.' It provides a clear condition for use and implies prefer specific tools, which helps in decision-making.

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

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

No annotations are provided, so the description carries full burden. It usefully discloses that only folders created by the user and the 'unfiled$public' folder are visible, and that standard folders may not appear depending on permissions. This adds valuable behavioral context beyond the schema.

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

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

The description is concise with two clear sentences plus a note. Every sentence adds value: the first states the action, the second gives usage guidance, the note provides transparency. No wasted words.

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

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

Given the simple nature of a list tool with no parameters, the description is fairly complete. It explains the purpose and important visibility constraints. However, it lacks information about the output format (e.g., list of folder names/IDs), which would be helpful for a complete understanding.

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

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

The tool has zero parameters, so the baseline is 4. The description does not need to add parameter information, and it doesn't. No schema description coverage is relevant here.

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 report folders in Salesforce. It uses a specific verb ('List') and resource ('report folders'), and distinguishes from sibling tools like salesforce_list_reports which lists reports.

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

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

The description explicitly advises to use this tool to discover available folders before listing reports, providing a clear usage context. It also includes a note about permissions and visibility, which implies when it may not be fully reliable, though it does not explicitly state when not to use it.

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

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

With no annotations, description fully discloses key behaviors: default folder checking ('unfiled$public' and 'Private Reports'), inability to list all reports across all folders, and the organizational structure (reports in folders). Could add more about potential rate limits or response format, but overall strong.

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 provides value, organized with clear headers and bullet points. Properly front-loaded with the core purpose. No redundant or unnecessary text.

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

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

Given the tool's simplicity (2 params, no output schema, no annotations), the description comprehensively covers purpose, behavior with examples, limitations, and complementary tools. Leaves no significant gaps for an agent to misuse.

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

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

Schema coverage is 100% with descriptions for both parameters. Description adds value by explaining the default behavior of the folder parameter (checks common folders if not specified) and reiterating the optional nature of searchPattern. This goes beyond the schema's 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?

Clearly states it lists reports in Salesforce folders and distinguishes from siblings by suggesting using salesforce_list_report_folders first. The verb 'list' and resource 'reports in folders' are specific 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?

Provides explicit when-to-use: suggests listing folders first, explains behavior with and without folder parameter, and mentions the Salesforce API limitation that prevents listing all reports across folders in one call.

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 implies a read-only listing operation, which is appropriate. No annotations are provided, so the description carries the burden; it is minimal but accurate.

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

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

The description is concise with two sentences, front-loading the action and providing brief context. No unnecessary words.

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

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

For a simple list tool with one optional parameter and no output schema, the description adequately covers the purpose and basic context. It could mention output format but is not 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?

The schema has 100% coverage for the single parameter 'searchPattern', which is described as optional and for filtering by name. The description adds no extra semantic value beyond the schema.

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

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

The description clearly states the tool lists available report types and explains what report types are. However, it does not explicitly differentiate from sibling tools like 'salesforce_describe_report_type' or 'salesforce_list_reports'.

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, nor any prerequisites or context for decision-making.

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

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

No annotations are provided, so the description carries full burden. It discloses that the tool validates user existence and mentions that if logLevel is not specified for 'enable', the tool will ask for clarification. However, it does not mention rate limits, authorization requirements, or side effects of operations.

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 brief intro, four examples, and a notes section. It is clear but slightly lengthy; the examples are helpful though they consume space. Could be slightly more concise.

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 7 parameters, 3 operations, and no output schema, the description covers operations and parameters well. However, it does not describe the return values for any operation (e.g., what 'retrieve' returns) nor error handling. This leaves the agent without full context on expected 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?

Schema coverage is 100%, so the schema already documents all 7 parameters. The description adds value through examples, notes on defaults, and operational context (e.g., logLevel optionality, expirationTime default). This enhances understanding beyond the schema.

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

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

The description clearly states 'Manage debug logs for Salesforce users - enable, disable, or retrieve logs,' which is a specific verb+resource combination. It distinguishes this tool from sibling tools like salesforce_query_records or salesforce_dml_records by focusing solely on debug log management.

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 examples and notes on required parameters and defaults, but does not explicitly state when to use this tool versus alternatives. It implies usage through the three operations, but lacks explicit 'when not to use' or comparisons to siblings.

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

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

No annotations are provided, so the description carries full burden. It mentions automatic FLS granting but does not disclose side effects of updates (e.g., type changes may be restricted) or error scenarios. Behavioral details are moderately covered.

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, uses bullet points and examples effectively, and front-loads the key action. Every sentence adds value without redundancy.

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

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

No output schema is provided, yet the description does not mention what the tool returns (e.g., success message or field ID). Given 18 parameters and no output details, the description is incomplete.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by grouping parameters (field types, properties, relationships) and explaining the grantAccessTo default, which enriches meaning beyond the schema.

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

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

The description clearly states the tool creates or modifies custom fields on any Salesforce object, lists supported field types and properties, and provides examples. It distinguishes from sibling tools like salesforce_manage_object by focusing on fields.

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

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

While the description explains what the tool does, it does not explicitly state when to use it versus alternatives like salesforce_manage_field_permissions or salesforce_describe_object. No exclusions or contextual guidance is provided.

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

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

No annotations are provided, so the description carries full burden. It discloses that the tool can grant/revoke/view field permissions, implying mutation for grant/revoke operations. However, it does not detail required permissions, reversibility, or side effects (e.g., profile changes may affect multiple users).

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: 4 sentences plus a bullet list and examples. It avoids unnecessary detail, is well-structured, and front-loads the core purpose. 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 moderate complexity (6 params, 3 required, no output schema), the description covers operations and examples. It lacks context on error conditions, prerequisites (e.g., Salesforce permissions to modify FLS), or limitations (e.g., profile name case sensitivity). However, the provided examples and schema make it fairly usable.

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

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

The input schema has 100% coverage, with descriptions for all 6 parameters. The description adds minimal semantics beyond the schema—only listing example scenarios. Since the schema already documents parameter meaning, the description adds value mainly through examples but not essential additional context.

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

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

The description clearly states the tool manages Field Level Security (Field Permissions) for custom/standard fields, listing specific operations (grant, revoke, view, bulk update). It distinguishes from sibling tools like salesforce_manage_field, which handles field creation/deletion, by focusing on permissions.

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 through examples (e.g., granting access, viewing permissions) but does not explicitly state when to use this tool versus alternatives like salesforce_manage_field for field metadata changes. No 'when-not' guidance or alternative tool names are provided.

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

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

Without annotations, the description carries full burden. It states that changes affect metadata and require permissions, but does not disclose side effects, consequences of updates (overwrite vs additive), error behavior, or rate limits. Minimal behavioral insight beyond the obvious.

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 brief, using bullet points and an example, and front-loads the main action. It is efficient, though could be slightly more structured (e.g., separating create and update clearly).

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

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

The tool has 9 parameters and no output schema. The description does not explain what the tool returns (e.g., success message, error handling) or provide deeper context about metadata operations beyond permissions. Lacks completeness for a complex metadata tool.

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

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

The input schema has 100% description coverage, so baseline is 3. The description groups parameters under create/update lists but adds little new meaning beyond the schema, e.g., mentioning 'fields, relationships, and settings' without elaboration.

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

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

The description clearly states the tool creates or modifies custom objects in Salesforce, listing specific operations (create, update) and providing examples. This distinguishes it from sibling tools like salesforce_manage_field.

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

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

The description includes a note about metadata changes and permissions, but no explicit guidance on when to use this tool versus alternatives like salesforce_manage_field or when not to use it. No exclusions or context for 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?

No annotations are provided, so the description must fully cover behavioral traits. It implies a read operation but does not explicitly state that it only queries and does not modify data, nor does it mention permissions or side effects. This is adequate but leaves ambiguity for the agent.

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 purpose and a key note, then provides practical examples without unnecessary fluff. It is slightly long due to examples, but each example earns its place by clarifying complex relationship queries.

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

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

Given no output schema, the description adequately explains query construction, including relationship patterns. It covers essential aspects like WHERE on related objects and ORDER BY. However, it could mention default limits or error handling for completeness.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by providing detailed examples and notes on relationship field syntax (dot notation, subqueries, custom relationship fields ending in '__r'), which clarify parameter usage beyond the schema definitions.

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 'Query records from any Salesforce object using SOQL, including relationship queries,' specifying the verb, resource, and capability. It distinguishes itself from a sibling tool (salesforce_aggregate_query) by noting when to use the alternative for aggregate queries.

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

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

The description explicitly tells when to use salesforce_aggregate_query instead (for GROUP BY, aggregates, HAVING). However, it lacks guidance on when to prefer other sibling tools like salesforce_search_objects or salesforce_describe_object, which could lead to confusion in broader context.

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

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

No annotations are provided, so the description carries the full burden. It discloses that providing className returns the full body, while namePattern returns only names, and includeMetadata adds extra info. No contradictions.

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 examples and a notes section. It is detailed but slightly long; could be more concise without losing key 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?

Despite no output schema, the description fully explains what is returned in each scenario. It covers all three parameters and their combinations, providing complete context for a read 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%, so baseline is 3. The description adds value with examples and notes, e.g., wildcard support and the effect of combining parameters.

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

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

The description explicitly states 'Read Apex classes from Salesforce.' and provides examples that differentiate it from siblings like salesforce_read_apex_trigger and salesforce_write_apex.

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 notes clearly explain when to use className verses namePattern, and the effect of includeMetadata. However, it does not explicitly mention when not to use the tool or provide direct comparisons to siblings.

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

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

The description explains that reading a specific trigger returns the full body, while pattern matching returns only names. It mentions metadata inclusion. No annotations are provided, but the description covers the tool's read-only nature and key behaviors. It could mention error handling 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 well-organized with a main statement, numbered examples, and bullet-point notes. Every sentence serves a purpose, and the structure aids readability. No unnecessary 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 read tool with 3 optional parameters and no output schema, the description fully explains the different return behaviors based on input combinations. It covers all parameters and their interactions, making the tool self-explanatory for selection.

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

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

With 100% schema coverage, the description adds significant value by explaining the interplay between parameters: e.g., when triggerName is provided, full body is returned; when namePattern is provided, only names are returned. It also clarifies the effect of includeMetadata and wildcard support.

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

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

The description clearly states it reads Apex triggers from Salesforce, with specific options for reading by name, pattern, or listing all. It distinguishes from siblings like salesforce_read_apex (general Apex) and salesforce_write_apex_trigger (write operation).

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

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

The description provides clear usage patterns with examples showing when to use triggerName vs namePattern vs includeMetadata. However, it does not compare to alternative tools like salesforce_query_records or indicate when not to use this tool.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It describes a read-only operation but lacks details on authentication, rate limits, error handling, or what happens if the report does not exist. This is minimal 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?

Two sentences, front-loaded with the main action and purpose. Every sentence adds value with no redundant or wasted words.

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

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

Given the tool has one parameter, no output schema, and no annotations, the description covers the purpose and what metadata it retrieves. It is reasonably complete for a simple read tool, though it could briefly mention the return format.

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 'reportName' has full schema description coverage (100%), providing an example format. The description does not add additional meaning beyond what the schema already provides, so baseline 3 is appropriate.

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

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

The description clearly states the verb 'Read' and the resource 'detailed metadata for a Salesforce report', listing specific details like columns, filters, groupings, and chart configuration. This distinguishes it from sibling tools like salesforce_list_reports (which lists report names) and salesforce_create_report (which creates reports).

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 'Use this to inspect existing reports and understand their structure', implying when to use it, but does not explicitly state when not to use it or provide alternatives among sibling tools. Guidance is implied but not explicit.

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

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

No annotations provided, but the description details SOSL features (wildcards, WITH clauses, updateable/viewable). It doesn't mention pagination or error handling, but the information is substantial.

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

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

Well-structured with sections, but the two large examples could be condensed. The main purpose is front-loaded.

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

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

Missing output schema and no explanation of return values. The tool's complex parameter structure is well-documented, but agents may need to infer the response format from examples.

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

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

Schema coverage is 100%, and the description adds value through examples illustrating parameter usage (e.g., where, orderBy, withClauses). The notes on wildcards and WITH clause types provide additional context beyond the schema.

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

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

The description clearly states 'Search across multiple Salesforce objects using SOSL', with examples showing multi-object search. This distinguishes it from sibling tools like salesforce_query_records (SOQL) and salesforce_search_objects (likely single-object SOSL).

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?

Examples show usage but no explicit guidance on when to use this tool vs alternatives like salesforce_search_objects. No criteria for when not to use it.

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

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

No annotations are provided, so the description should disclose all behavioral traits. It mentions the search behavior (name pattern matching) and examples, but lacks information on read-only nature, authentication requirements, or any side effects. The tool likely only reads object metadata, but this is not stated.

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

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

Two concise sentences: the first defines the purpose, the second provides examples. No superfluous words, and the key information is front-loaded.

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

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

The tool is simple with one parameter and no output schema. The description sufficiently explains its functionality for an AI agent to decide when to use it. However, it could mention the output format (e.g., list of object names) for completeness.

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

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

The schema covers the single parameter fully (100% coverage). The description enhances it with illustrative examples showing partial matching and wildcard-like behavior, adding value beyond the schema's description.

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

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

The description clearly states the tool searches for Salesforce objects by name pattern, providing concrete examples ('Account' finds Account and AccountHistory). It distinguishes itself from sibling tools that deal with records or data queries.

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

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

The description implies usage for finding object names, but does not explicitly state when to use this tool over siblings like salesforce_search_all or salesforce_describe_object. The examples give context, but no direct 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 full burden. It mentions that className in body must match the parameter and status is returned, but it omits critical behavioral traits such as permissions required, potential overwriting, rate limits, or API version implications. This leaves gaps for an agent.

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 examples and bullet-point notes, making it easy to parse. However, the examples are verbose; a more concise summary could suffice, but the structure aids understanding.

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

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

There is no output schema, so the description should detail return values. It only says 'Status information is returned', which is vague. Given the tool's complexity (4 parameters, write operation), more context on response format, error handling, or limits 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 baseline is 3. The description adds value by showing usage examples, clarifying that apiVersion is optional for create, and noting that className in body must match. This extends beyond the schema.

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

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

The description explicitly states 'Create or update Apex classes in Salesforce', using a specific verb and resource. This clearly distinguishes it from sibling tools like salesforce_write_apex_trigger (writes triggers) and salesforce_read_apex (reads).

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 examples and notes on required fields (operation, className, body) and optional apiVersion. However, it does not explicitly guide when to use this tool versus alternatives like salesforce_write_apex_trigger or salesforce_read_apex, which would improve clarity.

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

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

No annotations are provided, so the description carries full burden. It discloses that operations are 'create' or 'update' and notes required parameter matches, but does not detail potential side effects (e.g., overwriting existing triggers), permission needs, or error conditions. The mention of 'status information' is vague.

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

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

The description is concise and well-structured, starting with a clear purpose statement, followed by two detailed examples, and a bulleted list of important notes. No extraneous information is included, and every sentence contributes 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 has 5 parameters, no output schema, and no annotations, the description covers essential aspects: operation types, required/optional fields, and validation rules. However, it lacks details about the response format or error handling, which would be helpful for an action that modifies system state.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value through examples and notes clarifying operational constraints (e.g., 'For 'create' operations, triggerName, objectName, and body are required') and defaults (e.g., 'apiVersion is optional for 'create' (defaults to the latest version)'), which go beyond the schema's field 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 explicitly states 'Create or update Apex triggers in Salesforce,' clearly identifying the verb (create/update) and resource (Apex triggers). Among sibling tools like 'salesforce_write_apex' (for classes) and 'salesforce_read_apex_trigger' (for reading), this tool's purpose is distinct 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 does not provide explicit guidance on when to use this tool vs alternatives. While examples illustrate usage, there is no comparison with siblings like 'salesforce_write_apex' or 'salesforce_read_apex_trigger.' The context is clear only through the tool name and purpose.

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